Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

This is a good example of why this is currently out of scope. We have little to no implementation experience with such a setup.

EHL

> -----Original Message-----
> From: William Mills [mailto:wmills@yahoo-inc.com]
> Sent: Wednesday, January 26, 2011 3:17 PM
> To: Eran Hammer-Lahav; Marius Scurtescu
> Cc: oauth@ietf.org
> Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> Actually I was envisioning a situation where you have multiple possibly
> disparate endpoints that rely on authenticator like Google or Yahoo.  One
> company decides they want to allow federated login and accept SAML
> assertions, another accepts bearer, yet a 3rd IMAP server accepts both some
> form of signed auth and bearer.  I think discovery for a service should allow
> the service to specify the type(s) of auth accepted and the client can choose
> one that it supports and pass that on to the token server.  The resource
> server has to know what auth types are supported by the token server.  I
> would rather have this explicit in the discovery information and support
> multiple types in the same SASL mechanism than have to offer N
> mechanisms (or 2N if channel binding is in play).
> 
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Wednesday, January 26, 2011 2:58 PM
> > To: Marius Scurtescu
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> >
> >
> >
> > > -----Original Message-----
> > > From: Marius Scurtescu [mailto:mscurtescu@google.com]
> > > Sent: Wednesday, January 26, 2011 1:43 PM
> > > To: Eran Hammer-Lahav
> > > Cc: oauth@ietf.org
> > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> >
> > > >> 1. The token_type parameter is required in responses from the
> > server.
> > > >> If the server supports multiple formats, which one will be used?
> > In
> > > >> this case, would it make sense to allow the client to request a
> > specific
> > > format?
> > > >>
> > > >> For example, if the authorization server supports both MAC and
> > > >> BEARER, which one will the server issue?
> > > >
> > > > It might in some cases, but I suspect most providers are going to
> > decide
> > > which scheme provides the right level of security for them and just
> > use that.
> > > If you are going to allow both MAC and BEARER, you are basically
> > letting
> > > clients decide which level to operate at. Do you have a need or plan
> > to
> > > support multiple token types?
> > >
> > > For now we are planning to support only bearer, but I am sure some
> > form of
> > > signed tokens will follow sooner than later. At which point we would
> > have to
> > > support both.
> > >
> > > In most cases I think it is up to the client to decide.
> >
> > Interesting. Given that you are not planning on supporting this in the
> > near future, I think we should wait until there is more deployment
> > experience in allowing the client to negotiate the token type. But of
> > course, you are welcome to submit a proposal for inclusion on the WG
> > new charter.
> >
> > EHL
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth