Shibboleth Developers

["Scott Cantor" <>]

> 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.

I think it could. I also think transient should be used much more than it
is, as long as there is a tight connection between the parties issuing
credentials and answering queries, which I believe is not only acceptable
but in fact preferable.

> 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.

That's really orthogonal to the use case of that mapping plugin, which is
about the way the user identity gets passed to the resolver, and not about
the Format, which can be anything you tell it to use.

In fact, I would say that what's needed is to *extend* the principal mapper
with the ability to create and consume the username based on a pattern, and
specify the Format attribute you want. Then you can cover things like
internal use, emailAddress, DN, etc. with one plugin.

> I don't understand why you want to deprecate attribute
> eduPersonTargetedID?

I don't, but I don't see a reason to use it much either (apart from non SSO
use cases).

>  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?

We do this now. You can map based on the Format string to any header you
want, or filter based on site, as with an attribute. The flexibility in the
SP that's missing is the handling of the serialization to a string. Once
that's added/unified, they should be roughly the same. It's a matter of
code, not any special magic attributes have.

> 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...

See above. They're basically the same thing to the relying party, so they
should be treated the same as much as possible.

> 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.

There's nothing preventing anybody from using email addresses now (and
people are, usually to their detriment). But I don't think we're free to
"tweak" the syntax of ePPN.

I have wondered whether it's necessary to define a Format for EPPN. Probably
we should. But it can't be emailAddress, and it shouldn't be anyway.

> This is slightly off topic, but transient and persistent aren't really
> name identifier formats at all.

We don't really have the freedom to define what Format means in SAML. The
name is imperfect, but all names are.

> They are the only name identifiers
> having any semantic value, and as such, are actually profiles, not
> formats.

Calling them profiles too probably isn't inaccurate. One could argue that in
fact because they are the only ones with semantic value, they are the only
ones with much value, period. I mostly subscribe to that view.

> - 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.

It can't "key" off of something that isn't in the message. That leaves
Format. Supporting multiple is fine, but it's still more flexibly handled
with a super-imposed plugin that wraps others, which keeps the configuration
simpler, IMHO.

> - 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.

I think it would behoove us to confront head-on the issue of presence.
Transient identifiers just give you a way to sidestep it, but if the goal is
to support a policy that requires a user be physically present in some way,
we need a way to express that.

As a matter of policy, I can prevent phishing except by authenticated
parties, and that's about the best I can do. This has certainly been
discussed in the TC because of the X.509 attribute sharing profile thing
that Booz-Allen did.

Long term, I want the requesters to use credentials that explicitly give
them the right to make those queries on *my* behalf. This is the Liberty
model. I should be able to set policy based on myself and the service, and
the service should be able to request a SAML assertion from my IdP that
gives it the authority to query for data for the period of time that I'm
present.

In other words, the query use case is just a 3-tier app. We used transients
as a kind of "dummy" security token to sidestep the problem.

-- Scott