[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] HolderOfKey and SenderVouches are slippin gthru the cracks(!)
I agree with Prateek. I think a confirmation method should be defined in the Profile that uses it.
BTW, I made this comment some time ago, but I will repeat it. The description of Holder-of-Key is wrong. If you look up ds:KeyInfo you will see thaat it is not "Any cryptographic key", it is specifically a Public Key. I think the description should read something like:
"The subject of the assertion is the party that can demonstrate that it knows the value of the private key that corresponds to the Public Key specified in <ds:KeyInfo> of the enclosing <SubjectConfirmation> element, by means of the procedures implied by the particular KeyInfo format chosen."
The reason is that an X.509 cert implies X.509 processing, a PGP key ring implies PGP processing and so forth.
Hal
> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Thursday, April 04, 2002 4:59 PM
> To: 'Jeff.Hodges@sun.com'
> Cc: security-services@lists.oasis-open.org
> Subject: RE: [security-services] HolderOfKey and SenderVouches are
> slippin g thru the cracks(!)
>
>
> Jeff,
>
> one reason I had not included these identifiers was that the
> SOAP Profile
> document is now available. My own preference (given that
> these identifiers
> only make sense in the context of a particular
> profile construction) would be to include them in the next
> rev of the the
> SOAP
> profile document.
>
> - prateek
>
> >>-----Original Message-----
> >>From: Jeff Hodges [mailto:Jeff.Hodges@sun.com]
> >>Sent: Thursday, April 04, 2002 4:54 PM
> >>To: security-services@lists.oasis-open.org
> >>Subject: [security-services] HolderOfKey and SenderVouches
> >>are slipping
> >>thru the cracks(!)
> >>
> >>
> >>An apparent side-effect of our placing the responsibility
> for defining
> >>ConfirmationMethod identifiers with SAML profiles and
> >>bindings is having the
> >>HolderOfKey and SenderVouches ConfirmationMethods sort of
> disappear.
> >>
> >>The are not mentioned in Prateek's proposed changes to
> >>bindings-model-13...
> >>
> >>Proposed changes to bindings-13 to includedefinition of SAML
> >>Confirmation
> >>Method identifiers
> >>http://lists.oasis-open.org/archives/security-services/200204/
> >>msg00013.html
> >>
> >>Note that we explicitly listed them among the four
> >>ConfirmationMethods we felt
> >>we wanted to retain..
> >>
> >>Minutes for Focus Group Telecon Tue 2-Apr -2002
> >>http://lists.oasis-open.org/archives/security-services/200204/
> >>msg00007.html
> >>
> >>
> >>> Presently defined & employed ConfirmationMethods (and attendant
> >>> SubjectConfirmationData values) will be defined in
> >>appropriate places in the
> >>> subsequent version of bindings-model-xx, and it'll also
> >>have a (sub)section
> >>> summarizing the presently defined & employed
> ConfirmationMethods...
> >>> holderOfKey
> >>> bearer
> >>> sender vouches
> >>> artifact
> >>
> >>
> >>This situation is likely due to there not being an obvious place in
> >>bindings-model-13 to define holderOfKey and SenderVouches.
> >>
> >>Additionally, we'd agreed that there ought to be a summary
> >>section (appendix?)
> >>that lists all the ConfirmationMethods defined in the spec.
> >>
> >>A proposal to solve this is to concot a short, specific
> >>subsection of section 3
> >>"Bindings" (3.2, say) along the lines of..
> >>
> >>
> >>3.2 ConfirmationMethod Identifiers
> >>
> >>Assertions returned by SAML responders in response to any
> >>SAML requests MAY
> >>contain ConfirmationMethod identifiers defined in this
> >>subsection, or MAY
> >>contain ConfirmationMethod identifiers defined elsewhere in
> >>this specification
> >>(e.g. in profiles), or MAY contain ConfirmationMethod
> >>identifiers defined in
> >>other specification or by private agreement. Use and
> interpretation of
> >>ConfirmationMethod identifiers is profile- or
> >>application-specific. See
> >>
> >>
> >>3.2.1 Holder of Key:
> >>
> >> URI: urn:oasis:names:tc:SAML:1.0:cm:Holder-Of-Key
> >>
> >> <ds:KeyInfo>: Any cryptographic key
> >>
> >> The subject of the assertion is the party that can
> >>demonstrate that it
> >> is the holder of the private component of the key specified
> >>in <ds:KeyInfo>
> >> of the enclosing <SubjectConfirmation> element.
> >>
> >>
> >>3.2.2 Sender Vouches:
> >>
> >> URI: urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
> >>
> >> Indicates that no other information is available about the
> >>context of
> >> use of the assertion. The Relying party SHOULD utilize
> >>other means to
> >> determine if it should process the assertion further.
> >>
> >>
> >>
> >>...and add this appendix near the end of the spec....
> >>
> >>
> >>
> >>X Appendix: ConfirmationMethods summary
> >>
> >>These confirmation methods are defined in this specificaiton:
> >>
> >> Identifier See section
> >> ---------- -----------
> >>
> >> urn:oasis:names:tc:SAML:1.0:cm:Holder-Of-Key 3.2.1
> >>
> >> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 3.2.2
> >>
> >> urn:oasis:names:tc:SAML:1.0:cm:Artifact-01 4.1.1.1
> >>
> >> urn:oasis:names:tc:SAML:1.0:cm:Bearer 4.1.2.1
> >>
> >>
> >>
> >>
> >>-----
> >>JeffH
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC