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

Igor Faynberg <> Wed, 17 August 2011 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5BAE11E80C5 for <>; Wed, 17 Aug 2011 13:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QOQ8l6JKiFMN for <>; Wed, 17 Aug 2011 13:55:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA3DE11E80C3 for <>; Wed, 17 Aug 2011 13:55:47 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id p7HKuda4019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Wed, 17 Aug 2011 15:56:39 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id p7HKucED031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Wed, 17 Aug 2011 15:56:39 -0500
Received: from [] ( []) by (8.13.8/TPES) with ESMTP id p7HKucfr002612; Wed, 17 Aug 2011 15:56:38 -0500 (CDT)
Message-ID: <>
Date: Wed, 17 Aug 2011 16:56:37 -0400
From: Igor Faynberg <>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived!
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Aug 2011 20:55:51 -0000


I personally think that this is both a very thorough and very timely 

(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.)


On 8/17/2011 4:34 PM, Barry Leiba wrote:
> 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.
> -----------------------------------------------------------------
> _______________________________________________
> OAuth mailing list