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: R: Token correlation (Nate's summary)

I'm preparing my considerations, please allow me a couple of days.

Thank you very much for your generous involvement and interest.

Telecom Italia
Federico Rossini
Information Technology
Innovation, Architecture & Quality
V.le Parco De' Medici, 61 - 00148 Roma
+39 06 368 70991, +39 3356335842

-----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,

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.

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