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

On Thu, Mar 13, 2008 at 10:21 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> > 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.

I misled you, sorry.  If you read this profile from the point of view
of a developer who wants to implement an HTTP user agent able to
retrieve a holder-of-key authentication assertion, or a deployer who
wants to configure an IdP-first flow, you'll find it has little (if
anything) to say about the request from the user agent to the IdP.  So
you have to read between the lines to implement an IdP-first profile,
for example.

>  > 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.

Yes, and in fact, I've already profiled a SOAP-based use case that
produces an equivalent assertion, but that's why this one is an
appealing alternative, since it doesn't require SOAP.

>  > 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.

I will (again) but I'd rather leverage the authentication request
handlers that are already present (or will be present) at the IdP.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]