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] Groups - WSS-SAML-09.pdf uploaded




Levinson, Richard wrote:

>Ron,
>
>I agree that the formulation I proposed for scenario 2b is
>a sender-vouches use case. If the subject of the assertion
>is not holder of the key used to sign the message then
>I don't see any way this can be avoided using the 
>current saml defintions. In addition, at this point I have
>not seen a compelling need to change the saml definitions,
>because it appears to me that all the use cases we have
>discussed seem to me to be implementable with the existing
>definitions.
>
>The way I view the 4 use cases is that we have one hk use
>case (2a) and 3 sender-vouches use cases: 1a, 1b, 2b.
>
There is no need for a 3rd sv use case. 1a and 1b cover the important
sv use cases. 2a is an important hok use case, as is 2b. In 2b (as in 2a),
it is important that the content of the assertion as conveyed by a
trusted 3rd party authorizes the use of a key to confirm an assertion.

I am working the SAML core spec issue. I think it will become
clear that SAML core should not be attaching confirmation
mechanism specific semantics to generic elements such as
SubjectConfirmation/KeyInfo.

I think that should get us past this.

Ron



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