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: FW: Question to be forwarded to your OASIS contacts


Title: FW: Question to be forwarded to your OASIS contacts

Hi folks sorry for the cross-post, but since the WSS TC is closed down, I thought Id ask on these TCs

I really havent been keeping up with WSS/SAML profiling/interop efforts.  I got this question from some folks in engineering and am hoping someone can provide some info or pointers that I can pass along.

Thanks,

Rob Philpott

RSA, the Security Division of EMC
Senior Technologist  |  e-Mail: robert.philpott@rsa.com  |  Office: +1 781-515-7115  |  Mobile: +1 617-510-0893

_____________________________________________

=-=-=-=-=-=-=-=-=-=-=-=

The WSS SAML Token Profile, section 3.5.1.1 defines the holder-of-key method of Subject Confirmation which may be based on public/private or secret keys. In discussion with customers, we have received negative feedback on the use of public/private key mechanism due to PKI deployment issues. As for the secret key method, we have looked into the available OASIS interop use cases in search of documented and interoperable scenarios. The only ‘secret key’ use case that we have found is based on HMAC, as described at the following reference:

Web Services Security: SAML 2.0 Interop Scenarios

http://www.oasis-open.org/committees/download.php/16556/wss-saml2-interop-draft-v4.doc

Line 1469:  Scenario #6 – Holder-of-Key : Signed : HMAC

This method also suffers from the need for provisioning a shared secret to Requestor and Responder which creates additional deployment issues for certain customers (in these cases the clients are outside the enterprise). We were looking for an interop scenario that perhaps prescribes the key for subject confirmation to be generated by the Issuer and stored in the assertion, encrypted with the public key of the Responder (and the same key to be returned to Requester to be used for signing the message). Customers are OK with provisioning the Responder with public/private key and certificate.

Are you aware of such a scenario having been tested and documented by OASIS or WS-I?

=-=-=-=-=-=-=-=-=-=-=-=



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