[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] comments on WSS-SAML-02
First, a comment on WSS-SAML-02: Do we need to state someplace that the recipient SHOULD authenticate the assertion issuer and ensure that the assertion has not been modified? I guess this might fit into Section 3.1 (Processing Model). Issuer authenticity and assertion integrity may be provided in many different ways (e.g., via transport), but also by having the issuer sign the assertion. Should use of digital signature for this purpose be described as mandatory-to-implement for recipients? Response to Ron's comments: http://lists.oasis-open.org/archives/wss/200210/msg00008.html >> >>Comments on the SAML Binding/Profile: >> >>5. section 3.3 neglected to include the use of the URI >>attribute (on SecurityTokenReference) from the SS TC submission. >>This attribute is necessary to identify the responder at which >>to dereference the assertionID/reference. [Prateek] <SecurityTokenReference>s do not have URI attributes (do they?). I believe there is a <Reference> element that carries a URI attribute (Section 7.2). >>7. A use case where an encrypted shared secret session key, >>is conveyed in a subject confirmation element within a SAML >>authentication assertion should be added to the SAML binding. >>The subject would demonstrate knowledge of the key by signing >>something with it. This form of SAML assertion would be used >>in a manner analogous to a kerberos service ticket. >> [Prateek] I see this as a sub-case of HolderOfKey which hasn't been explicitly worked out in the current draft. In other words, I think it is an additional use-scenario rather than a new use-case. Nothing in the current draft precludes it. Of course, that doesn't mean we know how to implement it with inter-operability.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC