Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Oct 2011 15:25:25 +0300

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Oct 2011 21:13:55 +0300

Hi Bob, 

the question is only how to provide extensibility then. You are then essentially forced to know, because of pre-arrangements, what the content of the blob is going to be. 

Is that also fine for you? 

On Oct 14, 2011, at 7:04 PM, Bob Van Zant wrote:

> I'm in favor of removing the auth param option. It seems that half the
> point of the Bearer token is to have a very simple way of passing
> around opaque tokens.
> 
> If there are reasons for building a more feature-ful token with cool
> parameters then let's bring about a new token type. For now I like the
> brain dead simple Bearer:
> 
>    credentials = "Bearer" 1*SP b64token
> 
> -Bob

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Oct 2011 18:18:17 +0000

I think that William Mills already gave the best answer to the extensibility question when he wrote:
"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."

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 11:14 AM
To: Bob Van Zant
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Bob, 

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 14 Oct 2011 17:44:54 -0300

I agree that is the cleanest.

John B.