[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] comments: sstc-saml-holder-of-key-browser-sso-draft-01
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]