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

Well, I guess I better get going with the SASL thing and get a working implementation done based on -12 and the bearer token spec.

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Wednesday, January 26, 2011 7:27 PM
> To: William Mills; Marius Scurtescu
> Cc: oauth@ietf.org
> Subject: 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