Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt

John Bradley <ve7jtb@ve7jtb.com> Mon, 11 February 2013 17:40 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 97C9221F867B for <oauth@ietfa.amsl.com>; Mon, 11 Feb 2013 09:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level:
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-2.038, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNp7PlQCTrXT for <oauth@ietfa.amsl.com>; Mon, 11 Feb 2013 09:40:11 -0800 (PST)
Received: from mail-gg0-x22d.google.com (gg-in-x022d.1e100.net [IPv6:2607:f8b0:4002:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6D94121F865B for <oauth@ietf.org>; Mon, 11 Feb 2013 09:40:11 -0800 (PST)
Received: by mail-gg0-f173.google.com with SMTP id b6so731906ggm.18 for <oauth@ietf.org>; Mon, 11 Feb 2013 09:40:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LoEmFd/z28kLnZ/UtkAE9xa9J7QAE6moXUORpLskJsM=; b=B241svJ74w4ELKxLjX4DAGv7IRghDWaLtw0eoBdZqg6+XK4Eqh6LvjyDY2zAuy9dES OCDY/c8rpTJzMO6rbghzJ8uInOpTam4jec6pyQaQjjo5ezF9y4OD2zsJAiAVVzx8PA1A JmS+W2JWeIv+ReNX9l/teXU49kVEoXs/6FRc13Nd52xhLHXyUeUELeViOwu0toNHd74g jIaTXqTH2IpKqQTOw7tVY+y+XD/Owm7vUoLqyKKPAknPujrCsFDlfBN+ZIWIocgFOYbb EhhmXbcasDWafjj+DJZgOeRtv0KbLz0DLa9rqQ8hPK6gosE3y7kCq1iwA9pVVdM5sMi4 LZOw==
X-Received: by 10.236.131.232 with SMTP id m68mr18676967yhi.100.1360604410825; Mon, 11 Feb 2013 09:40:10 -0800 (PST)
Received: from [192.168.1.213] (190-20-50-112.baf.movistar.cl. [190.20.50.112]) by mx.google.com with ESMTPS id d19sm37032518anm.18.2013.02.11.09.40.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 09:40:08 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <5FDE6412-5892-4840-935A-20A8A3BC49A0@gmx.net>
Date: Mon, 11 Feb 2013 14:40:03 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <B910E696-7F42-4449-9F2D-5D40053B440A@ve7jtb.com>
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com> <5112BE73.2070003@mitre.org> <5FDE6412-5892-4840-935A-20A8A3BC49A0@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkkCCH9hQi6Ou0vD3rsLkCuTpZ2cHI59DGl1XdKYf8+lN6OwU4lJPHNnZIkTu2hWqdEc+fg
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
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: Mon, 11 Feb 2013 17:40:12 -0000

The client may have a developer key which is a bearer token.   How it gets it is out of scope,  however we do see in the real world developer portals where developers establish accounts and get keys/tokens for creating clients.

Depending on the IdP this master token could be issued to a native app and then used to create separate client IDs for each instance.

The spec allows a client to have a token for registering or arrive without it.    Like OAuth punted on how the client gets a ID and secret, we are punting on how the developer gets its initial token if it is required.

There are real use cases for this in API management.   It would be nice if those systems could leverage this spec rather than being forced to create something different.

John B.


On 2013-02-11, at 2:28 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Justin, 
> 
> just one comment on this specific issue: 
> 
> On Feb 6, 2013, at 10:34 PM, Justin Richer wrote:
> 
>> 1. client shows up at the Client Registration Endpoint, posts a JSON object with a few bits of metadata about itself (and potentially presents an Access Token that it got from some out of band process that acts as a "class registration" or "developer key", important to several known real-world use cases)
> 
> The starting point of the dynamic registry document was that the client does not yet have some secret with the authorization server and for that reason it does all this dance. 
> Now, you write that it may have some "developer key" (which is sort of similar to what the client id/client secret is). 
> 
> That cannot be right. 
> 
> Ciao
> Hannes
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth