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: RE: [security-services] FW: Question to be forwarded to your OASIS contacts


> The WSS SAML Token Profile <http://www.oasis-
> open.org/committees/download.php/16768/wss-v1.1-spec-os-
> SAMLTokenProfile.pdf> , 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.

I'm not sure I understand how the "solution" addresses this, but all you
need for HoK is a server PKI, and it's all rooted in the SAML issuer's key,
and you already have to trust that (somehow).
 
> 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.

I don't think I understand the meaning of Requester and Responder here. For
one thing, there's a key (pun intended) piece missing, the client using the
assertion. If all you have is an IdP and SP, there's no point I can see to
HoK.

If I understood the scenario better, I might be able to suggest something,
having thought quite a lot about HoK.

-- Scott




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