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

Barry Leiba <> Wed, 17 August 2011 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D1DC1F0C58 for <>; Wed, 17 Aug 2011 13:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.038
X-Spam-Status: No, score=-103.038 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wj3ZstP0kGG3 for <>; Wed, 17 Aug 2011 13:33:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BE89F1F0C51 for <>; Wed, 17 Aug 2011 13:33:47 -0700 (PDT)
Received: by yie12 with SMTP id 12so1146927yie.31 for <>; Wed, 17 Aug 2011 13:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wbGqwxoVqq8hvy7FQ28LtKNpYm7buBbbpE/DRrH0b04=; b=Y9FSGlhBxbXb4G8+59aBiH7lJl6BXr7tFNN8nU+IPWKBMyyEpOoo2Kfxyd8lOgMznl hIHFwdOo61DoJexf/rvMwnpl4cDjUfzHzN20QG3P8nTBwYTdasAn2yFT29bZONv6pbM0 SpaoxsYjxEKhVH6AY/q6pWgrE0dzAF13LlZFA=
MIME-Version: 1.0
Received: by with SMTP id p18mr1556344yal.24.1313613279558; Wed, 17 Aug 2011 13:34:39 -0700 (PDT)
Received: by with HTTP; Wed, 17 Aug 2011 13:34:39 -0700 (PDT)
Date: Wed, 17 Aug 2011 16:34:39 -0400
X-Google-Sender-Auth: jjpNWb8bjg4STn0hWSvQ2ee3rTM
Message-ID: <>
From: Barry Leiba <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
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:33:48 -0000

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-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

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

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

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.

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

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

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.