OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Token correlation (Nate's summary)

>- Better (preferred) if both SAML-X and SAML-Y assertions
>  are valid when they reach the Service provider.

I'd make this mandatory, unless we want to get into the nuances of what it means if SAML-X is invalid, but SAML-Y is valid and contains a pointer to it.  I think that's a big mess.  We can discuss that mess if it is necessary in this use case, but it should be avoided if at all possible.

In that spirit, token expiration, audiences mismatches, etc. are better handled through proper mechanisms, such as long expiration periods, many or broad audiences, delegation, etc., or omitting those conditions completely.  If renewal of a token is necessary, then that should just take the form of a request for a new token.  None of this needs to be in normative language in the proposal, which I think can just cover a Condition that the validity of this token depends on the validity of that token.

The other thing that might need more thorough discussion at some point is the interpretation of the pointer.  The semantic meaning of the reference("I'm allowed to impersonate the subject of SAML-X and I'm doing that now", "I have to meet the subject confirmation requirements for both SAML-X and SAML-Y when I present them, even if these requirements are holder-of-key, and these are just identity data/privilege envelopes"(ndk's preference), or otherwise) needs to be tightly defined too.

Thanks to you & Paul for summarizing my thoughts, and thank you to Federico and others for their proposal,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]