R: Token correlation (Nate's summary)

[Rossini Federico <federico.rossini@telecomitalia.it>]

Ok, in principle I'm in agreement with making mandatory that SAML-X and SAML-Y assertions be both valid when they reach the Service provider.

In my opinion, though, without this constraint, the specification would be more useful and flexible, more suitable for use cases like those ones we discussed during the call.

My idea was that it would be sufficient for the service provider to verify that the SAML-X is issued by the IDP, without further checks of the "conditions" elements.

My question now is:
would it make sense to remove the validity constraint and, instead, add in the token-correlation clause other parameters (other than System Id)?

For example parameters like "not before" and "not after" that specify the range of the possible values for the SAML-X data creation (issue instant), to be acceptable when SAML-X is linked with SAML-Y.
This could make the security mechanism more robust, since the intermediary would not be allowed to use a generic SAML-X, but only the SAML-Xs which meet the new condition and, as a consequence, are related to business transactions that presumably are still to be processed.


*******************

As far as the pointer is concerned, I haven't had time to analyze it in details yet.
What I can say now is that the intermediary will not impersonate the requestor, the Intermediary makes a standard SAML invocation with a new condition, which identifies the context.

Moreover, the intermediary has to meet the subject confirmation requirement only for SAML-Y and not for SAML-X. In my opinion, this will not imply a substantial weakness in the security mechanism.

Federico

-----Messaggio originale-----
Da: Nate Klingenstein [mailto:ndk@internet2.edu]
Inviato: marted́ 13 luglio 2010 20.00
A: Thomas Hardjono
Cc: Rossini Federico; Thomas Hardjono; OASIS SSTC
Oggetto: 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,
Nate.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.