[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - sstc-saml-holder-of-key-browser-sso-draft-03.odt (sstc-saml-holder-of-key-browser-sso-draft-03.odt) uploaded
> As far as I can tell, a profile for a stand-alone client (which > doesn't exist of course) would be a strict subset of the > holder-of-key-browser-sso profile. Moreover, the IdP-first subcase of > browser SSO is *very* close to the stand-alone client scenario. Thus > I don't see much point in having two separate profiles. There are two halves to the profile you're talking about, and the IdP-first case is *similar* (but not the same) as one of those halves for delivering an assertion to an HTTP server. That half leaves out the part where you figure out what the site actually wants and get the token in the first place. That end to end flow is what causes the problems, and this profile is end to end right now. Having written both types of profiles, I know that it's not a subset, and I also know that the first half of such a profile already exists and is perfectly usable, even if it's not in OASIS. Why is it better to mis-apply a set of flows designed for a browser than to just define (or reuse as the case may be) a pair of profiles for requesting assertions from a client and then delivering them? No misuse of messages, no faking who the issuer is, much more modularity with other specs. The part that's never been defined for SAML is how a client, decoupled from an IdP, would send an assertion to an ordinary web site ahead of some arbitrary HTTP traffic. That's essentially what ECP could have been if I'd understood better how to design the profile at the time. Because SOAP seems to be such a dead end to me right now, I have been toying with such a delivery profile, and it was proposed to me as long ago as early last year. Basically using POST to deliver a SAML assertion (possibly in a response, possibly not) to a web site in return for a cookie to set up a session. But that's not the original SSO profile, nor this one. When you have language in the profile that says explicitly "the IdP sends..." and "the Issuer MUST be the IdP", I don't see how that doesn't make it clear what you can and can't do. Just because the messages end up looking similar doesn't change that. The semantics are completely different, and the sensible content to include in the assertion changes along with it. Regardless, as it stands, this text isn't what you want yet. If you want to overload all of this into one document, I think you have to rewrite it to support that, and redo the diagram. I think what you'll end up with is two sets of flows and rules. Which is the same as having separate profiles. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]