>     >> I have a preference for option 1. This is a AAA architecture, and
>     >> so we should use representations consistent with that, and map to
>     >> alternative representations as necessary.
> 
>     Stefan> Ditto.
> 
> I'm generally hap.happy with option 1.
> I'd like to discuss how the mapping to/from SAML is going to work because I
> think we're all agreed that we should use the existing SAML formats in SAML
> messages.

I think it is useful to look at best (or at least common) practice in a typical Web SSO scenario. One of two things normally happens:

1. The IdP issues an assertion that contains either a name identifier and/or an attribute whose values give a persistent identifier for the authenticated user. If this is a name identifier, it may be a scoped persistent name identifier of the kind that Scott describes. If it is an attribute, it might be something like email, ePPN or ePTID where the semantics of the identifier clearly differs from case to case.

2. The IdP issues an assertion that contains a transient name identifier that can be used for a limited period of time to reference the authentication event for a subsequent assertion query to obtain an attribute (such as one of those described above). This is intended to restrict an RP's ability to arbitrarily obtain attributes for a user if it has previously obtained an identifier for it.

So it's a rather complex picture and one that could potentially become more complex by introducing AAA identifiers. As such, I'm personally inclined to think that we approach it as follows:

1. All AAA packets must either contain a AAA identifier of the kind that we have converged on, or a RADIUS state attribute that allows the AAA identifier to be inferred.

2. SAML messages within AAA packets may also contain arbitrary SAML identifiers (name identifiers or attributes). We don't prescribe anything.

The AAA identifier is therefore a lowest common denominator identifier, with the option to use other syntactically and semantically richer SAML identifiers where the use case requires it. 

> I also want to think through the situation Scott brought up--a third-party AA.
> I want to consider both the case where the third-party AA is SAML and where
> it is  AAA.

I think in this case the Moonshot entity must have obtained a SAML identifier of some description, unless we're willing to modify the SAML AA such that it can interpret a AAA identifier.

Josh.



Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238