> Another thing I noticed, you don't say anything about the requirements
> of the user agent. It's almost like the user agent is invisible and
> doing only what it's told. That's not the way I think about it. What
> if I wanted to implement a user agent that conformed to this profile?
> What would it have to do?
Be a browser. I'm pretty sure the point is to support COTS browsers, just as
today. You *wouldn't* (necessarily) use this profile for a non-browser
client, because that kind of client can do a much better job of splitting
the IdP and SP apart and allowing independent profiles.
> Suppose a user is only interested in obtaining a holder-of-key
> authentication assertion from an IdP. (Forget about what happens to
> the resulting assertion.) So now I go about implementing an HTTP user
> agent that formulates an AuthnRequest and issues a request. What are
> the requirements associated with this request/response?
I think core addresses that perfectly well already. We know how to do that.
But only with a client that's SOAP capable.
> I didn't make up this scenario, since we want to do just that!
I'd suggest reading the Liberty SSOS, which is simply a refinement of the
core protocol that does exactly what you're asking to do.
-- Scott
