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-boun...@ietf.org [mailto:oauth-boun...@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:mscurte...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
