IETF Logo Mail Archive

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

John Bradley <ve7jtb@ve7jtb.com> Thu, 06 June 2013 08:53 UTC

Return-Path: <ve7jtb@ve7jtb.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 E58B921F9632 for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 01:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 qYsve2hfFczV for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 01:53:35 -0700 (PDT)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2E13921F95EF for <oauth@ietf.org>; Thu, 6 Jun 2013 01:53:34 -0700 (PDT)
Received: by mail-ee0-f49.google.com with SMTP id b57so1076767eek.36 for <oauth@ietf.org>; Thu, 06 Jun 2013 01:53:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=kvkY+B9woJcXZEsdNX1gXrA1gog41Adal0ykWjXsL4g=; b=Va5WjHO9rbvt7EqFrFW6U6NWQ0fb2pNg+an0An5pQm7bKW5GC1iRpNp3rjuk/Ga3+W bQFYQHyxRByWNaULZf+VT8a2bqIa77yrqZLYQn0Q+UKihRmBRHgxJV6/fYf9UIGRujlk vD7dvkAR8DV1q5QAymhdq6XK3g6KcC27uMe8+IPSN5WUBmTBFGWlRffrirkAf9Ykh8A0 ZG96+qzJ9qK6eBYMg1wkffcz4S+xaJH9iVjnWBfIk8dFJNPyyksUx5EXCMp9d1L2lMyT wufU5PgjpTi5isnQizQ3uhTR69q95KpqysR4UzIWdG90DjBiE5SBpUOBc4aOFMAKNyxw 3wtg==
X-Received: by 10.14.108.69 with SMTP id p45mr9462366eeg.126.1370508814152; Thu, 06 Jun 2013 01:53:34 -0700 (PDT)
Received: from ?IPv6:2001:610:131:7000:b5eb:4e7b:a7ac:8b44? ([2001:610:131:7000:b5eb:4e7b:a7ac:8b44]) by mx.google.com with ESMTPSA id a5sm104605238ees.6.2013.06.06.01.53.31 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 01:53:32 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_BE0BF91A-07AC-4E16-994A-3AC4FE25FDD6"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net>
Date: Thu, 06 Jun 2013 10:53:31 +0200
Message-Id: <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.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> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <CA+ZpN25_tguPtPDktm M8q=72EgnesignTuWE19wi61gCTLLL_g@mail.gmail.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQkky/umsZvgM3EMdJvmCZLmvaEOyTO8Unl7l2Y/wDiwE/+Q/B3OVKo7ezt5ppB1dGFuNRyD
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [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 08:53:37 -0000

There are a couple of reasons.    

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type.   The new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration.   
I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.
On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:

> Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work?  -T
>  
> That’s the answer for why there is support for bearer tokens but it is not the answer to why that’s the only supported mechanism.
> If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email