Responses to suggestions not adopted are inline below. Thanks for your input.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Wednesday, March 02, 2011 7:35 PM
To: OAuth Mailing List
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-v2-bearer-03
> 1. There is a whole lot of text about OAuth2 get-a-token parts that isn't
> necessary in the bearer token spec.
> A bit of context can be useful to a reader, but in this case it brings too
> much of the complexity of the get-a-token flows into what should be a quite
> simple spec. It is not as though it can replace reading OAuth2 core.
I believe that the text you mention is important to set the context for the use
of OAuth 2.0 bearer tokens so readers will understand the context and purpose
of this specification. I would, however, consider further clarifying this text
in a future draft, should you provide specific proposed edits that retain this
context.
> 1a. Change the title from "The OAuth 2.0 Protocol: Bearer Tokens" to
> "The BEARER HTTP authentication scheme", or
> "Using Bearer Tokens in HTTP requests".
Given that this specification is about using OAuth 2.0 with bearer tokens,
removing "OAuth 2.0" from the title would remove necessary context that frames
the purpose of the specification.
> 2. The abstract should say this is a mechanism for HTTP requests. My
> suggestion:
> "This specification describes how to include a bearer token conveying
> authorization information in an HTTP request. It also describes how to
> recognize a bearer token delivered by an OAuth 2.0 delegation flow."
As above, I believe that this proposed change over-generalizes the intended
purpose and scope of the specification, making it less clear to implementers
and adopters.
> 4. Drop most of the "Introduction" and all of the "Overview". These are all
> about OAuth2 core and aren't necessary for understanding how to use a bearer
> token in an HTTP request. Here is my suggestion:
> "Introduction
>
> "A bearer token is the simplest mechanism for a client to convey its
> authority when sending a request to a server. A server accepting a bearer
> token assumes the authority it represents applies to whom ever presented it.
> That is, there is no additional authentication of the client. Consequently,
> it is crucial that a bearer token is never exposed to any party that might
> misuse it. Using bearer tokens that only represents a limited amount of
> authority, in a specific context, for a short amount of time can reduce the
> risks of using bearer tokens.
>
> "This document specifies the "BEARER" HTTP authentication scheme for
> conveying a bearer token in an HTTP request header. It also specifies two
> alternatives for situations where it is infeasible for clients to modify HTTP
> headers: a URI query parameter; and a parameter in the body of a POST that
> uses the application/x-www-form-urlencoded media type.
>
> "For example:
> GET /resource HTTP/1.1
> Host: example.com
> Authorization: BEARER vF9dft4qmTG_fdf-qwAS
>
> "One possible source of dynamically issued bearer tokens is an OAuth 2.0 flow
> for user delegation or credential exchange as specified in [OAUTH2]. Section
> X of this document describes how a bearer token is represented in an OAuth
> 2.0 token response."
I believe that the text you mention is important to set the context for the use
of OAuth 2.0 bearer tokens so readers will understand the context and purpose
of this specification. I would, however, consider further clarifying this text
in a future draft, should you provide specific proposed edits that retain this
context.
> 8. The allowed characters in <access-token> is crazy. Using <quoted-char>,
> but not within quotes is not a good sign?!
> Token issuers don't need 93 allowed chars, just allow the 66 web-safe ones
> and make it simpler for everyone.
This is insufficient rationale to introduce a breaking change. I would want to
see a demonstration of working group consensus for this change before making it.
10. Instead of concentrating on when a "WWW-Authenticate: Bearer" response
header MUST be returned, we should focus what it means when it is present in a
response. Servers can return it when they need that meaning. This would makes
it clearer that it can be included with, say, a 200 OK response to indicate
that more would be available if a bearer token had been included.
I would want to see demonstration of a working group consensus to expend the
usage of this field in this manner before making this change.
> 11. The "WWW-Authenticate: Bearer" response header would be a good place for
> the server to indicate whether or not it supports the URI & POST-body
> optional methods for conveying a bearer token. Perhaps a supports="body
> query" parameter?
I would want to see a specific proposal and a demonstration of a working group
consensus to expend the usage of this field in this manner before making this
change.
> 12. A section explaining how a client can recognizes when a OAuth 2.0 token
> response contains a bearer token is needed. It would simply says that the
> token_type parameter SHALL have the value "bearer" when the token is intended
> to be used with the methods defined in this spec.
It's not clear to me that overloading the meaning of the token_type parameter
in this manner would increase interoperability. I would want to see
demonstration of a working group consensus to overload the meaning of the
token_type parameter in this fashion before making this change.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
