Revised Revised DocuSign Identity Priorities

[Peter Schober]

Was that really meant for the global Shibboleth software community?
Anyway, comments below.

* David Bantz <dabantz at alaska.edu> [2014-07-31 02:56]:
> > [1] There are ... 2 values passed [in cn or commonName] – there
> > should only be 1 value and it should be the one that matches
> > exactly what’s set in DocuSign…

'cn' clearly is defined to be multi-valued, in RFC 4519, 2.3.
If the SP cannot handle multiple values it shouldn't require/request
cn. The software community is unlikely to be of help here, but
statements from (in this case) several InCommon participants /might/ be
able to effect change here.

For a Shib IDP to work around that you could create a copy of your cn
attribute definition and source it from displayName (which is defined
to be single-valued, RFC 2798, 2.3), if you already support that. Then
only release single-valued-cn to the broken SP.

> > [2] keep it simple, swap out the urn:oid and put the friendly name
> > in its place, that should help
> 
> Setting aside the perverseness and glibness, is [2] even possible?
> 
> Can I release a SAML attribute without a Name, only a friendlyName?

That's not how I interpret the statement in [2], but the literal
answer to your (second) question is no, it should not be possible, as
that would make the IDP violate the core SAML spec.

I read [2] as suggesting to send the value of FriendlyName (here "cn")
as value of Name. Don't bother with adjusting the NameFormat to basic
as I doubt they would even look at that, based on the above comments.
And no, the SAML spec says FriendlyName "MUST NOT be used as a basis
for formally identifying SAML attributes" (Core, 2.7.3.1).
-peter