OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]