Thanks, John, for the clarification. I really appreciate it. On Wed, Dec 16, 2009 at 6:21 AM, John Bradley <[email protected]> wrote: > 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 > > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev > >
-- Regards, Travis Spencer _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
