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

[Stephen Farrell <[e-mail]>]

On 12/18/2011 07:00 PM, Barry Leiba wrote:
> 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.

Just to confirm that the above is the case.

IMO I'm still right and the WG are still wrong:-) But let's see if
we can make progress in any case.

S

>
> 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
>