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

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

> 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