RE: [security-services] Groups - sstc-saml-holder-of-key-browser-sso-draft-03.odt

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

> This is all of ID-WSF, right?  I'm looking for a standalone profile to
> retrieve a h-o-k assertion from a SAML IdP.  Does such a profile
> exist?

Yes. I can't reference it because the only thing posted is the ZIP.
 
> > The SAML Token Service profile and SOAP binding specs do exactly what
you
> > want for SOAP applications.
> 
> Well, I don't see a SAML Token Service profile in that mountain of
> files.

It's in the AS document.

> Given that 1) the vast majority of IdPs authenticate users via
> username/password (in my experience, at least), and 2) there appears
> to be at least a mild backlash against SOAP in the marketplace, I
> would say that an HTTP-based token service is not only viable, but
> necessary at this point.

I think it's needless duplication with fewer features. But if I honestly
thought that *anybody* could be won over just by pulling SOAP out of there,
I'd have done it a long time ago. The real problem is not getting tokens,
but using them. Without those profiles, it doesn't matter.

> Are you referring to WS-Addressing?  I haven't examined this aspect of
> ID-WSF in detail, but I wonder if the use of WS-A here interferes with
> the use of WS-A in applications based on WS-ResourceFramework (which
> is the totality of grid applications)?

No, I wasn't talking explicitly about WS-Addressing, but there's probably
some basic use of it in there. Liberty defines a couple of headers for
housekeeping, and then there's WS-Security, but even that's basically just
used for timestamping if you wanted to use, say, basic-auth for
authentication.

Since all I'm talking about is SOAP between the client and the IdP, I don't
see why a conflict with WSRF would matter.

-- Scott