The STS always sends the RSTR to the selector. Someone is getting confused with WS-Fed passive federation.
The selector always defaults to asymmetric proof keys. The selector uses ephemeral key pairs because it doesn't have a certificate as such, also to protect privacy and prevent correlation. It is the selector that encrypts the token for the RP if auditing mode is not used. If auditing mode is used the STS encrypts the SAML token to the RP with the RP's cert. It however will likely include a display token for the user to inspect the values being returned. The selector posts the token to the RP through the browser if there is no RP/STS it sends it to the RP/STS via SOAP so HoK is no problem. The as I pointed out there is a limitation on doing HoK proofs through the browser. At the moment if the RP attempts mutual TLS to prove the browser has possession of the ephemeral key the browsers are not smart enough to get the Private key from the selector. That is a implementation issue. SAML has exactly the same issue, The current HoK SAML profile requires this missing browser functionality as well. It is on the IMI-TC's issue list to address. Without HoK the ICAM profile for IMI requires auditing mode cads so that the token is audience restricted and encrypted by the STS for the RP. John B. On 2009-12-16, at 1:26 AM, Travis Spencer wrote: > On Tue, Dec 15, 2009 at 4:34 PM, John Bradley <[email protected]> wrote: >> It is true that HoK doesn't work through a browser at the moment. > > What about when the selector is invoked because a user browses to a > Web page that has an info card HTML object tag in it? When the > selector sends that Web site relying party the security token, is that > token and the HTML message signed/encrypted with a proof key by the > selector? I've been told it can't be because the selector is out of > the picture by the time the STS sends the RSTR. The selector requests > the token, but the last mile is just HTML and JavaScript. The > selector (a fat client), which has the technological wherewithal to > sign and encrypt messages, is long gone by this point, so it can't do > a HoK proof and the browser can't either. Thus, all security tokens > presented to Web site relying parties are bearer tokens even when info > card is used. Is this correct? > > -- > > Regards, > > Travis Spencer > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
