Bearer tokens are practically identical to OAuth 1.0 PLAINTEXT. Get your facts right.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Sunday, December 04, 2011 1:37 AM > To: Mike Jones; Barry Leiba; Stephen Farrell > Cc: oauth WG > Subject: Re: [OAUTH-WG] Mandatory-to-implement token type > > I agree we have no plans to implement MAC if we wanted that we would > have been happy with OAUTH 1.0a but that was not deployable > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Mike Jones > Sent: Saturday, December 03, 2011 6:26 PM > To: Barry Leiba; Stephen Farrell > Cc: oauth WG > Subject: Re: [OAUTH-WG] Mandatory-to-implement token type > > I strongly object to a mandatory-to-implement clause for the MAC scheme. > They are unnecessary and market forces have shown that implementers do > not want or need this kind of an authentication scheme. > > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Barry Leiba > Sent: Saturday, December 03, 2011 1:38 PM > To: Stephen Farrell > Cc: oauth WG > Subject: Re: [OAUTH-WG] Mandatory-to-implement token type > > Stephen says: > > On 12/02/2011 03:20 AM, Barry Leiba wrote: > >> Maybe what would work best is some text that suggests what I say > >> above: that toolkits intended for use in implementing OAuth services > >> in general... implement [X and/or Y], and that code written for a > >> specific environment implement what makes sense for that environment. > >> It seems to me that to require any particular implementation in the > >> latter case is arbitrary and counter-productive, and doesn't help > >> anything interoperate. Whereas general-purpose toolkits that > >> implement everything DO help interop. > > > > That'd work just fine for me. > > OK, so here's what I suggest... I propose adding a new section 7.2, thus: > > ----------------------------------- > 7.2 Access Token Implementation Considerations > > Access token types have to be mutually understood among the authorization > server, the resource server, and the client -- the access token issues the > token, the resource server validates it, and the client is required to > understand the type, as noted in section 7.1, above. Because of that, > interoperability of program code developed separately depends upon the > token types that are supported in the code. > > Toolkits that are intended for general use (for building other clients and/or > servers), therefore, SHOULD implement as many token types as practical, to > ensure that programs developed with those toolkits are able to use the > token types they need. In particular, all general-use toolkits MUST > implement bearer tokens [...ref...] and MAC tokens [...ref...]. > > Purpose-built code, built without such toolkits, has somewhat more > flexibility, as its developers know the specific environment they're > developing for. There's clearly little point to including code to support a > particular token type when it's known in advance that the type in question > will never be used in the intended deployment. > Developers of purpose-built code are encouraged to consider future > extensions and to plan ahead for changes in circumstances, and might still > want to include support for multiple token types. That said, the choice of > token-type support for such purpose-built code is left to the developers and > their specific requirements. > ----------------------------------- > > I think that expresses a reasonable compromise that might actually be > followed and might actually do some good. Comments? Can we go with this > and close this issue? (And, sorry, I've been a Bad Chair, and haven't put > this > in the tracker.) > > Barry > _______________________________________________ > 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 > > > > > > _______________________________________________ > 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
