Re: [OAUTH-WG] Mandatory-to-implement token type

[Eran Hammer-Lahav <[e-mail]>]

Bearer tokens are practically identical to OAuth 1.0 PLAINTEXT. Get your facts right.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth