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


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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

Subject: Re: [wss] SAML Token Brainstorming

Hal Lockhart wrote:

>Are these semantics specific to the WSS SAML Toke Profile? They are not
>mandated by SAML as far as I am aware.
I tried to correct my previous msg, but you responded before I had a chance.

>>Holder-of-key requires that the assertion contain an authority
>>signature and
>>that the sender sign the msg. The sender need not sign the assertions.
>According to SAML any assertion may or may not be signed.
>The Holder of Key is intended to allow the Subject (who may or not be the
>sender) to prove that is in fact the Subject refered to by demonstrating
>that it has knowledge of the expressed or implied secret, typically by use
>os some cryptographic function such as a signature.
the SAML token profile does not require that a holder-of key assertion 
be signed
by the authority, but since the assertion is acting as a (key carrying or
identifying) certificate, the profile recommends that such assertions be 
signed. SAML does not specify how holder-of-key assertions should be 
used, as
it did not complete the specification of a profile that relies on them.

>>Except for the special case described below, Sender-vouches requires
>>that the sender sign both the assertion and the msg. The authority need
>>not sign the asertion (although doing so allows the relying party
>>to verify that the authority has established the binding of attributes
>>to the subject).
>In the case of the SAML POST profile (for which the sender vouches
>confirmation method was invented) the authority signs the assertion, not the
>sender. (It follows a V path from authority to Browser (sender) to relying
>party, via a web form.)
AFAIK, the SAML POST profile uses the bearer confirmation method. I don't
think SAML specified a profile that uses the sender-vouches confirmation 

>As I understand it, sender vouches is just like saying "this is my birth
>certificate, here in my hand." In other words there is no sure way of
>assocating the sender with the assertion.
I don't think your example is a good match for the language I remember
from SAML describing sender-vouches. That is, this profile is not uses
by a subject to vouch for itself. In your example, another party, perhaps
your lawyer, would be vouching for you by providing your birth certificate.

>This is my understanding of what SAML specifies. If we are adding new
>semantics, we should chose new subject confirmation methodds, not change
>their semantics.
see above. It looks to me like neither of the confirmation mechanisms
used by the SAML token profile, are being used by any other SAML profile.

>>To do request encryption, I thought we would more likely depend on
>>the X509 profile to pass an encrypted key, in which case, I
>>thought we would
>>likely reuse the encrypted key for the response. We could, for
>>response only
>>encryption, reuse the key from a SAML assertion (used to sign the request)
>>to define an encrypted key, if we think response only encryption
>>is an important use case.
>>Is there any reason why it would be bad to demonstrate a sign and encrypt
>>scenario that synergized both the x509 and Saml token profiles?
>Why not just exchange it in advance? In real life it would likely be
>obtained from something like WSDL.
what would this look like?

Would the msg have an encrypted key that references a saml
assertion (exchanged out of band) and that identifies the key
that was used to encrypt the encrypted key.

Would the reciever get the assertion, and then look somewhere
in it (perhaps the confirmation method) to find the name
of the private key it must use to decrypt the encrypyted key?

If this is what we are doing, would it be easier to directly
reference the key (as apposed to the assertion) in the encrypted

>>I don't think I saw Irving's comments,
>Irving just has said repeatedly that he doesn't see how an assertion with
>sender vouches differs semantically from an assertion with no subject
>confirmation method.
I can understand that point of view. Of course the SAML token
profile (as it is currently specified) places requirements on
the sender and reciever that would not apply if the confirmation
method was undefined.



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