Scope has to be defined in the core OAuth spec. I think it's a mistake to talk
about it in regard to the Bearer token spec specifically.
I think removing the auth-param usage is workable. Then if we need
extensibility defining a new scheme can do that. It's a bit more work that way
if needed, but it's clean.
-bill
________________________________
From: Mike Jones <michael.jo...@microsoft.com>
To: Hannes Tschofenig <hannes.tschofe...@gmx.net>; OAuth WG <oauth@ietf.org>
Sent: Friday, October 14, 2011 8:42 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed
Resolutions
Thanks for the useful discussion and the write-up, Hannes. For context, Hannes
and I discussed how to resolve the remaining Bearer spec issues in a manner
that meets the needs of implementations and will not generate objections during
the IESG or IETF Last Call reviews. A few additional comments…
1. Error Description – Nothing to add to Hannes’ write-up.
2. Scope – I was planning to allow a broader set of ASCII characters than the
“token” set, as these characters are inadequate for the use of URIs/URLs as
scope elements. In particular, scope elements need to permit the full sets of
“reserved” and “unreserved” characters in RFC 3986. The draft I am working on
will say that scope is a space separated set of elements, where the elements
consist of one or more characters from the union of the “reserved” and
“unreserved” sets.
3. Authorization Request Header Field – We agreed on the call that we’re not
doing implementers any favors by allowing both the b64token and #auth-param
syntaxes, and that it is better to specify one or the other. Since existing
practice corresponds to the b4token syntax, the choice is clear which to
specify. Thus, it was a mistake to introduce the #auth-param choice in draft
9. It will be removed in draft 10, which is shortly forthcoming.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed
Resolutions
Hi all,
I had a discussion with Mike and Julian to hear what to discuss the open issues
with the OAuth Bearer Token draft. Below is a short writeup of my impressions.
1. Error Description
The error description field provides information to the software developer and
is not meant to be shown to the end user. As such, there is no desire to
provide internationalization support for this field. Hence, it has a similar
characteristic as the HTTP 'Reason-Phrase.
http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#reason.phrase
says
"
The Reason Phrase exists for the sole purpose of providing a textual
description associated with the numeric status code, out of deference to
earlier Internet application protocols that were more frequently used with
interactive text clients. A client SHOULD ignore the content of the Reason
Phrase.
Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) "
We can use something similar for the error description field and even simplify
it further by omitting HTAB and obs-text:
error-desc = "error_description" "=" *( SP / VCHAR )
2. Scope
The scope field is yet another item that will not be shown to the user and it
serves the purpose of an identifier for authorization comparison. So, we don't
need to have any internationalization support here either.
The suggestion is to re-use the 'token ABNF syntax from the HTTP spec:
http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3
3. Authorization Request Header Field
Finally, there is the authorization request header field where we have to
decide how we want to deal with extensions.
The current specification says:
credentials = "Bearer" 1*SP ( b64token / #auth-param )
This means that we can have either a base64 opaque blob or a parameter like
syntax (but not both).
An example of the b64token is
Authorization: Bearer vF9dft4qmT
and an example of the auth-param usage is
Authorization: Bearer t=vF9dft4qmT
With an opaque blob extensibility is limited and for this reason, I guess, Mike
had provided the additional option of auth-parameter.
If we want to allow extensibility then we have to go for the auth-param
approach. If we only use the auth-param (without the b64token) then there may
be an issue with already existing implementations. We will have to
double-check.
Then, there is the possibility to provide two ways to encode the same
information, namely either as a base64 blob and in the auth-parameter style.
(In a single protocol run one would obviously only use one or the other.)
If we define the auth-param then we have to also provide information on what it
actually is. We cannot leave that out of scope.
Ciao
Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
