Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived!

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Aug 2011 16:34:39 -0400

I'm sorry for the delay in getting this written.  Because of the
delay, the working group has just a short time to review my proposed
response, below.  Everyone, please have a look at the answers I
propose to send, and post any objections to this thread by the end of
the day on Monday, 22 August.  Hannes, please also check with the IAB
in parallel, and make sure we can send this via Murray as soon as
we've resolved any WG objections.

Barry, as chair

-----------------------------------------------------------------

The IETF OAuth working group thanks OMA ARC SEC for the liaison
statement titled "OAuth discovery and specification availability",
dated 18 July 2011.

The OMA liaison statement asks the OAuth working group to address five
issues, and our answers are as follows:

•	Availability of the IETF OAuth specifications: especially
[draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also
[draft-hammer-oauth-v2-mac-token],
[draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

Answer:
The IETF cannot guarantee publication dates, but we can give some
best-guess timeframes.  As this writing, draft-ietf-oauth-v2 and
draft-ietf-oauth-v2-bearer have completed Working Group last call and
are undergoing their final revisions before being sent to the IESG.
We expect the final versions of those documents to be in the RFC
Editor queue around the end of September, though it could be later if
issues come up in IETF-wide last call or during IESG evaluation.  The
draft-hammer-oauth-v2-mac-token document has been replaced by
draft-ietf-oauth-v2-http-mac, which is a working group document.  It
is likely to be in the RFC Editor queue by the end of the year.

The remaining two documents are not working group documents, and the
working group can say nothing about their status.  The OAuth working
group intends to revise its charter in the November timeframe, and
it's possible that one or both of those documents could be adopted by
the working group at that time, and we could have further information
about target publication dates then.

•	Availability of the OAuth Parameters Registry

Answer:
The draft-ietf-oauth-v2 document establishes the OAuth Parameters
Registry (in section 11.2, as of draft version 20).  The registry will
be available when the RFC is published, which will be some time after
the document goes into the RFC Editor queue, depending upon the RFC
Editor's load at the time.

•	IETF intent to specify an OAuth Discovery mechanism

Answer:
There is interest among OAuth working group participants for
specifying such a mechanism, but the work is not in the current
charter.  It will likely be considered during the aforementioned
charter update in (approximately) November.

•	Considerations that can help implementors decide about the type of
OAuth access token to deploy.

Answer:
There is no current work planned, but documents with such
implementation advice might also be considered during the rechartering
discussion.

•	For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.

Answer:
In the bearer token document (Section 2.4 of
draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header
Field"), the "scope-v" element is unambiguously defined to allow a
specific set of characters.  That set of characters does permit, but
does not mandate, support for percent-encoding of characters.

-----------------------------------------------------------------

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 17 Aug 2011 16:56:37 -0400

Barry,

I personally think that this is both a very thorough and very timely 
follow-up.

(You may consider a minor editorial: "As this writing" in the first 
answer, should be "As of this writing."  Could not catch anything else.  
The only other suggestion is that maybe the response could omit RFC 
Queue and other details of the IETF process as those are unfamiliar to 
OMA. They asked for dates, and the dates are there.)

Igor

On 8/17/2011 4:34 PM, Barry Leiba wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 18 Aug 2011 09:26:45 +0200

+1

-----Ursprüngliche Nachricht-----
Von: Barry Leiba [mailto:[email-masked]] 
Gesendet: Mittwoch, 17. August 2011 22:35
An: [email-masked]
Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived!

Barry, as chair

.	Availability of the IETF OAuth specifications: especially
[draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also
[draft-hammer-oauth-v2-mac-token],
[draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

Answer:

.	Availability of the OAuth Parameters Registry

Answer:

.	IETF intent to specify an OAuth Discovery mechanism

Answer:

.	Considerations that can help implementors decide about the type of
OAuth access token to deploy.

Answer:

.	For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.

Answer:

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 18 Aug 2011 21:15:18 +1000

>> *	For bearer tokens: clarification whether the non-support of percent

> does not mandate, support for percent-encoding of characters.

This is a poor answer.
A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect.

OAuth2 core (implicitly) allows a scope to use any Unicode char except space (as space is used as a delimiter).
Bearer restricts scopes to 93 ASCII chars.
OMA are asking if this is intentional.

If we really want to restrict scope values it would be better done in OAuth2 core.
If we don't want to restrict values then the bearer spec needs to be able to handle any possible scope value by defining an escaping mechanism for scope-v (or by not having a scope parameter).

--
James Manger

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Aug 2011 13:52:33 -0400

The text for the answer below came from Mike, as the chairs asked for
at the IETF 81 meeting.  Mike, do you have a response to James's
issue?  Can we give a better response here?  Should the bearer doc
specify %-encoding explicitly?

Barry

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 18 Aug 2011 11:09:41 -0700 (PDT)

+1 for Jame's feedback here.  We need to solve this.

________________________________
From: "Manger, James H" <[email-masked]>
To: Barry Leiba <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, August 18, 2011 4:15 AM
Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v

This is a poor answer.

--
James Manger

---

From: Barry Leiba <[email-masked]>
Date: Mon, 22 Aug 2011 13:53:28 -0400

> +1 for Jame's feedback here.  We need to solve this.

I have opened an issue in the tracker on this:
http://trac.tools.ietf.org/wg/oauth/trac/ticket/26

I intend to add the following to the response to this item:
"The working group understands that client code needs to know whether
to use and decode percent-encoding.  The issue is being discussed and
tracked, and will be resolved before the final version of the bearer
document is produced."

Barry, as chair

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Aug 2011 08:32:25 -0400

> tracked, and will be resolved before the final version of the bearer

For confirmation: Murray Kucherawy, our liaison to OMA, delivered our
response yesterday (Tuesday, 23 August), and OMA has acknowledged it.
They thank us for our prompt response.

Barry, as chair

> best-guess timeframes.  At this writing, draft-ietf-oauth-v2 and

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 24 Aug 2011 12:45:18 -0400

Bravo! This has been project-managed masterly.

Igor

On 8/24/2011 8:32 AM, Barry Leiba wrote:
> On Mon, Aug 22, 2011 at 1:53 PM, Barry Leiba<[email-masked]>  wrote: