IETF Logo Mail Archive

Re: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol

Justin Richer <jricher@mit.edu> Wed, 11 March 2015 12:04 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281511A88B1 for <oauth@ietfa.amsl.com>; Wed, 11 Mar 2015 05:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEE5P4nOZcyp for <oauth@ietfa.amsl.com>; Wed, 11 Mar 2015 05:04:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5463A1A8843 for <oauth@ietf.org>; Wed, 11 Mar 2015 05:04:10 -0700 (PDT)
X-AuditID: 1209190e-f79bb6d0000030e8-7d-55002f385e96
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 17.F7.12520.83F20055; Wed, 11 Mar 2015 08:04:09 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t2BC47gl031080; Wed, 11 Mar 2015 08:04:08 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BC45s0021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 08:04:07 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_ED485F67-0F8D-49C1-B3FE-18D52D1DB62C"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b5
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CAOahYUx8zGRy7f7ZisRh8=tco1LYFKHxcy1iwKX8hfqt+3EfzQ@mail.gmail.com>
Date: Wed, 11 Mar 2015 08:04:04 -0400
Message-Id: <7CDF2772-18FA-46EE-9E65-8D2740460FD1@mit.edu>
References: <CAOahYUx8zGRy7f7ZisRh8=tco1LYFKHxcy1iwKX8hfqt+3EfzQ@mail.gmail.com>
To: Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6nrmupzxBq0PqJ0WLntp+sFiffvmJz YPJYsuQnk8eEiT9YApiiuGxSUnMyy1KL9O0SuDIOHj3EXNBgUXFh1R2WBsaNBl2MnBwSAiYS B5f8ZYKwxSQu3FvP1sXIxSEksJhJYubXiywgCSGBjYwSL067QyQeMkk0Lv3OCJIQFgiVWHHi PJjNK2AgMffUFyaQImaBSYwSN/bcY4EYKyXx4PYasCI2AVWJ6WtawNZxCgRKHHp1jhnEZgGK P5q1jL2LkQOoWV2i/aQLxEwriX1fdrFBHBEg0brqGNgYEQELia0vrzCBlEsIyEv0bEqfwCg4 C8kVs5BdMQtsapLErZ8yIDXMAtoSyxa+ZoawNSX2dy9nwRTXkOj8NpEVwpaX2P52DlTcUmLx zBtQ9bYSt/oWMEHYdhKPpi1iXcDIvYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0 EyMo/jgl+XYwfj2odIhRgINRiYd3xqz/IUKsiWXFlbmHGCU5mJREeS/qMIQK8SXlp1RmJBZn xBeV5qQWH2JUAdr1aMPqC4xSLHn5ealKIrynVYHqeFMSK6tSi/JhyqQ5WJTEeTf94AsREkhP LEnNTk0tSC2CycpwcChJ8FbqAjUKFqWmp1akZeaUIKSZODgPMUpw8AANTwOp4S0uSMwtzkyH yJ9iVJQS530Acp0ASCKjNA+uF5Y2XzGKA70lzOsBUsUDTLlw3a+ABjMBDWaxBnqYt7gkESEl 1cCos5GPaaKie1uR4pPKuJbiB0u37Zh4auvmDsY9Hn0+GxoXBW46vEfMXlxPmd/ph0DovfId B9Ruv9xhKLZfa6lqZtb8uzI8PFIf4jQP/8k+7NXJwr98zvl9fOzZB/YK5Lzl/7Lk9dSSb7FX nTrbxeYJGDGd3nn8qnndxRvztm2865y1ryA5e9UnJZbijERDLeai4kQA4mj4dHYDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/nuy5gPwG885gy6a8j1sG05WCLjA>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 11 Mar 2015 12:04:13 -0000

Hi Adam,

Yes, in fact that use case is the motivation behind allowing the initial access token mechanism, where the developer goes and gets a pre-registration token and passes that in through the application itself:

https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2 <https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2>

What we don’t specify is *how* the deployment organization finds out about the client developer, since that’s so far been something that’s pretty tightly tied in to deployments. In BlueButton+ we used a combination of a structured initial access tokens and a registry service (think of it like a trust root with discovery components) to get this kind of information across the wire. Within your deployment umbrella you could do something similar, or use the software statement mechanism to carry similar information. Nobody’s sought to have that specific part standardized yet, but you can absolutely deploy it within the Dynamic Client Registration spec.

 — Justin

> On Mar 11, 2015, at 1:26 AM, Adam Lewis <Adam.Lewis@motorolasolutions.com> wrote:
> 
> Hi,
> 
> I am curious about the use cases that inspired this draft, as the terminology that is defined within fits like a glove a use case that I have, though the draft doesn't solve it it completely.
> 
> Namely the use case as I have is for the "client developer" to be able to create a developer account with the "software API publisher" via  developer portal, and to then make their client available for download on an app store (e.g. Google Play), where it would be downloaded by a "deployment organization" and finally run the client registration protocol.  This fits our use case 90%, but we have a further use case that the "software API deployment" is able to identify the "client developer" of the application when executing in a "deployment organization."
> 
> I'm curious if that last part was ever identified as a use case for the draft?
> 
> 
> 
> tx
> adam
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email