Shibboleth Developers

["RL 'Bob' Morgan" <>]

> My working model for how this would work has always been that the
> relying party should not be looking at the certificate at all. I think
> it should be possible to take the entire certificate and send it as the
> subject of a SAML query.
>
> The AA can then both validate the certificate and map it to an identity
> for attribute lookup.
>
> This doesn't obviate the privacy issues (the target can still see the
> cert), but it delegates the validation and mapping process to the
> origin, where it belongs, since validation of client certs by web
> servers is effectively nightmarish to implement today on a global scale.

Umm, hmm?  Why is validation of a client cert, as part of SSL processing,
any more difficult than validation of a signed SAML assertion, as part of
the web browser profile?  The win in the SAML case, it seems to me, is
simply that the user doesn't have to deal with certs and keys.

What you're suggesting sounds more or less like the "path validation
service" that has been the subject of much work in PKIX (and XKMS, I
think).  But having the origin AA play that role for the target seems
unlikely to me.  As far as I can see the target will have to do full
SSL/cert validation in this case.

The win in sending the whole cert as the Subject of the AQM is just that
the target wouldn't have to figure out which part of the cert the origin
thinks of as identifying the subject, which I agree is a win.

But having the Attr Authority be able to respond to any kind of permanent
identifier reveals a certain overloading we're doing with the current
handles.  The handle has a validity period, even if it's only known by the
origin, after which it won't be useful for queries.  This is a cheap way
of getting a session, and ensuring that a target is asking about a subject
that has recently come to it.  But if the AttrA handles permanent
identifiers, does it have to answer any legitimate requester regardless of
when it asks?  If there is to be a session context, where does it come
from?

> The remaining trick is to map the certificate to an origin site
> identifier, such that the metadata can then be used to locate an AA to
> query. This may actually be something the user could directly indicate
> somehow, but could also depend on the certificate, obviously.

The DLF cert work from a couple of years ago invented a cert attribute for
that purpose.  It's obviously appealing not to have to issue new certs in
order to make this work, though.  But use of existing certs would lead us
back to the target digging thru it to figure out which parts to use to
identify the origin site ...

> A related point is that Walter and I have both, somewhat independently,
> been looking at different models for handling the NameIdentifier
> processing in the AA, and will probably work on that at some point to
> generalize it more. It's a bit tricky today to deal with multiple kinds
> of identifiers because the format of the properties file is so limited.

Right, it's important that this be pluggable.

 - RL "Bob"