> 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
