IETF Logo Mail Archive

[OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 06 June 2013 04:06 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77211E80E4 for <oauth@ietfa.amsl.com>; Wed, 5 Jun 2013 21:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.004
X-Spam-Level: *
X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1qclBWbaHA0 for <oauth@ietfa.amsl.com>; Wed, 5 Jun 2013 21:06:22 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8AC21F84D4 for <oauth@ietf.org>; Wed, 5 Jun 2013 21:06:21 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.87,812,1363093200"; d="scan'208,217"; a="139421643"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 14:06:21 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7097"; a="136803557"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 14:06:21 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 6 Jun 2013 14:06:20 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 06 Jun 2013 14:06:19 +1000
Thread-Topic: draft-ietf-oauth-dyn-reg and bearer tokens
Thread-Index: Ac5iL79BM7YjzA27Rz+zRJyRJaehgwANR/oQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <B33BFB58CCC8BE4998958016839DE27E08F97708@IMCMBX01.MITRE.ORG> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <F293690C-1E82-4350-80D4-2E2C0EF86E55@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <F319CA95-B5A8-4BD5-A8BA-F57BCBA6806B@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA@mail.gmail.com>
In-Reply-To: <CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1151B105DA5WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 04:06:29 -0000

BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is deliberately extensible to support other sorts of credentials (eg MAC authentication).

Why is draft-ietf-oauth-dyn-reg hardwired to only support BEARER tokens?

1.3. “Registration Tokens and Credentials” says:

  “The Initial Access Token … is an OAuth 2.0 Bearer Token”

  “The Registration Access Token … is an OAuth 2.0 Bearer Token”

Google’s TLS ChannelIDs [draft-balfanz-tls-channelid], for instance, would be a fantastic fit for linking the first registration request with any subsequent registration modifications. The Registration Access Token would be annoying legacy baggage in that situation.


It seems that the Registration Access Token is only ever used at a single URI: registration_client_uri. That sounds like the perfect situation to use a “capability URI”, effectively putting the token in the URI. Anyone considered doing that? It should significantly simplify the spec.

--
James Manger

v2.23.0 | Report a Bug | By Email