Shibboleth Developers

["Tom Scavo" <>]

SAML name identifiers (a subject near and dear to my heart :) were
discussed on the Shib call last Monday so I thought I'd try to
summarize the discussion here for the benefit of my grid colleagues
(and anyone else who might be interested).

- Open question: What name identifiers should be supported in Shib 2.0?
- It is thought that the two most popular SAML 2.0 name identifiers
will be transient and persistent, so Shib 2.0 should support these at
least.
- With the emergence of persistent identifiers, is the attribute
eduPersonTargetedID still needed?  Will its use be deprecated?

Does this capture the essence of Monday's discussion?  If not, please weigh 
in.

In conjunction with the ordinary Browser SSO profiles, I agree that
transient and persistent identifiers are most useful.  For other
profiles, however, especially the grid integration profiles we've been
working on for the last year, the X509SubjectName identifier is more
important.  I don't believe the introduction of persistent identifiers
will alter this fact.

Assuming Shib 2.0 has an extension mechanism at least as sophisticated
as that in 1.3, it's not critical that Shib 2.0 support
X509SubjectName (or any other alternative format) out of the box since
it's fairly easy to add a name identifier mapping as an extension. 
That said, we would love to have you take our implementation of
X509SubjectName under your wing. :-)  It's only marginally more useful
than the existing implementation in Shib 1.3, but it serves our
purposes well.

As a side note, the principal format may be deprecated in Shib 2.0.  A
simple implementation of emailAddress wholly replaces the nonstandard
principal format.  As with the principal format, however, emailAddress
may be only useful for testing (we use it for that purpose in fact). 
In any event, we would be happy to contribute a simple implementation
of emailAddress.

I don't understand why you want to deprecate attribute
eduPersonTargetedID?  If the value of ePTID is identical to a
persistent identifier (for a given SP and principal), why not expose
both?  From the SP's point of view, attributes are (slightly) more
flexible than name identifiers, I think.  For instance, how do you
pass a name identifier in an HTTP header?

That reminds me, can you comment on the proposed unification of name
identifiers and attributes?  I can see how ePTID might be driving that
thought process...

Along those lines, what about the emailAddress name identifier?  It
could hold either ePPN (with some minor tweaks to ePPN syntax) or the
mail attribute, and so it too would benefit from a Grand Unification
of attributes and name identifiers.

This is slightly off topic, but transient and persistent aren't really
name identifier formats at all.  They are the only name identifiers
having any semantic value, and as such, are actually profiles, not
formats.  For example, the persistent identifier has characteristics
"persistent" and "opaque" while the transient identifier has
characteristics "transient" and "opaque".

A name identifier framework might define interfaces "transient",
"persistent", "opaque", and "transparent", which a mapping would
implement.  Note that such a name identifier interface might only be a
marker interface.

A few remaining thoughts with respect to name identifiers:

- Since the IdP keys off name identifier format, it would be useful if
the name identifier mapping framework supported multiple
implementations of the same format.  Alternatively, Shib might key off
mapping as opposed to format.

- Will non-SSO uses of persistent identifiers be flagged to prevent
phishing by SPs?  (This is another reason why ePTID is preferred to
persistent identifiers, btw.)  If so, we have problems since we
(GridShib) routinely make attribute queries apart from SSO.

Tom