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

[Barry Leiba <[e-mail]>]

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