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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
