Re: SAML and Shibboleth

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Hal:

On Wed, 15 Aug 2001, Hal Lockhart wrote:

> Once again I will not be able to attend your call. However I would
> like to again contribute my proposed approach. I am wondering if this
> sort of scheme would be acceptable to them.

Yes, I think you've got it exactly, and, now that SAML is more concrete,
this is (IMHO) the direction that Shibboleth is headed in.

I would say that "blinded" is one way of describing the nature of the
privacy-preserving identifier, but there's more to it:  only useful for a
short period, not linked to other identifiers, not reused.  I'm hoping to
send a more general note on features of such an identifier (before leaving
on vacation shortly ...).  But distinguishing these characteristics of a
privacy-preserving identifier might make us wonder what the expected
characteristics are of a "regular" subject identifier in an assertion, and
whether those characteristics need to be specified:  format, linkage to
other identifiers, validity period, consistency across multiple
assertions, etc.  If apps depend on these characteristics then they
shouldn't be implicit.

As has been noted, Shibboleth is also very interested in the "user
contacts target first" scenario.  This probably isn't a bindings issue; I
don't know whether it's on the agenda tomorrow.

 - RL "Bob"

> The Shibboleth scheme requires the ability to request the attributes
> of user, without revealing the identity of that user. Further, the
> attributes revealed are a function of the requestor.
>
> This can be accomodated by SAML in the following way. These
> capabilities are required.
>
> 1. The ability to issue an Authentication Assertion whose subject is an
> "blinded" identifier which can be mapped by an Authentication or Attribute
> Authority to a particualr subject, but which has a different value each time
> it is issued for the same subject.
>
> 2. The ability to construct an Attribute Assertion for a subject identified
> by an Authentication Assertion with a "blinded" subject identifier. The
> Attribute Assertion would be constructed on demand and only contain the
> attributes appropriate for the requestor, but the means of doing this would
> not be specified by SAML.
>
> The session would go like this.
>
> 1. The user would signon and receive a SAML Artifact.
>
> 2. The user would present the Artifact, allowing a target server to retrieve
> the associated "blinded" Authentication Assertion.
>
> 3. From this, the necessary Attribute Assertion could be obtained.
>
> Steps 2 & 3 could be combined in one request/response sequence.
>
> The assertions could also be passed via the user or pushed from the home
> site.