Closing out this issue: > 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.
We do NOT have consensus to use that text, nor any other. As I see it, the STRONG consensus of the working group is not to make any change with regard to text about which tokens to use or how to authenticate the client. This issue is closed, and Stephen reluctantly accepts that he's in the rough on this issue... but leaves us with the warning that he expects other ADs, on their own, to raise this issue during IESG evaluation. That might result in DISCUSS positions that we have to address at that time. Eran, I think this gets us done with the base-doc issues, and we should be ready for you to prepare a final version that can go into IETF last call (unless you're aware of anything I've missed). Barry _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
