RE: [security-services] comments: sstc-saml-holder-of-key-browser-sso-draft-01

["Scott Cantor" <cantor.2@osu.edu>]

> I misled you, sorry.  If you read this profile from the point of view
> of a developer who wants to implement an HTTP user agent able to
> retrieve a holder-of-key authentication assertion, or a deployer who
> wants to configure an IdP-first flow, you'll find it has little (if
> anything) to say about the request from the user agent to the IdP.  So
> you have to read between the lines to implement an IdP-first profile,
> for example.

And how would you do it for standard SSO? I think it's the same answer.
Initiating IdP-first was never included, so the presumption is that you
"spoof" an SP.

> Yes, and in fact, I've already profiled a SOAP-based use case that
> produces an equivalent assertion, but that's why this one is an
> appealing alternative, since it doesn't require SOAP.

Then I would suggest that what you're after is an HTTP binding where the
user agent is the SAML requester. Which was debated ad nauseum and rejected
on the basis that HTTP authentication blows and SOAP already covers the use
case well enough.

But that is not this profile, IMHO. It's the same distinction between ECP
and a SOAP-based SSOS. The requester is the SP in the former and the client
in the latter.

> I will (again) but I'd rather leverage the authentication request
> handlers that are already present (or will be present) at the IdP.

But you're not...you're asking for the profile to turn into a different
profile so that the profile you want will get implemented instead. ;-)

I think there are different profiles required for this use case and the one
you're after isn't suited for a browser.

-- Scott