Shibboleth Developers

["RL 'Bob' Morgan" <>]

> (v05 from May 2002, latest I can find).

Yep, that's still the current version.  We recognize it needs an update
...

> I noticed that scattered in a couple places in the document, e.g. in
> 3.2.3 and 5.6.1.2, there is talk about using certificates (I assume
> X.509) instead of a handle in the attribute request (or AQM). But 3.2.3
> leads me to believe this has never been standardized on and hence may
> not be supported.

There's nothing in the architecture to preclude this, but as you note some
details need to be defined to make it work in practice, and this has not
been done.  I would say that we only thought about profiling it in the
context of a web browser accessing a webapp using SSL with client cert
authn, where this would happen instead of the SAML web browser profile.
So the main issue is what part of the cert gets pulled out for use in the
AQM.

Obviously this has implications about privacy protections that are
unlikely to be possible in the case of a traditional cert with a
well-known long-term identifier in it.

> Architecturally, how opaque is the Subject field to the SAML AA? Should
> the AA match it to the user's principal name (as opposed to a handle) if
> both were identical? (I think the answer to this from reading 5.6.1.2 is
> "Yes".)

Architecturally, the Subject of an AQM can take many forms ...

> And then of course, how close is the actual 1.0 implementation to that
> architectural model?

Shib 1.1 only supports handles in various guises.  Adding specific other
subject identifiers would have to be done as part of a profile of the
whole scenario, it seems to me; ie, not just "use a DN" but also say where
it comes from in the cert, how it relates to cert issuer, etc.

> A follow-on question, assuming it was worked out such that one could
> query with an X.509 identity in the AQM, is it possible to set up an ARP
> such that a user can always get their own attributes? i.e. a SHAR ==
> "Self" type of policy.
>
> Hmmm, a more general version of that question is, can the SHAR
> identifier in an ARP be something other that a hostname (or wildcard
> version there of)? (Both architecturally and 1.0 implemenation.)

I think you're suggesting a scenario where the user gets attribute
statements from an Attribute Authority and then passes them along to
someone else.  The current Shib model is that the receiver of the
statement is the relying party that's providing access to the resource, so
any further passing-along is not in scope.  So treating "the user" as the
attr-statement requester is not something we currently do.  Developing
this scenario would, I think, mean explicitly considering the security
issues of passing attribute statements among multiple parties.  Worth
doing, but not done yet, either in Shib or in SAML.  I'm working on
something like this, but just in the classic 3-tier case.

 - RL "Bob"