Re: [OAUTH-WG] Dynamic Client Registration

Phil Hunt <> Sun, 03 November 2013 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24B9A21F9DCA for <>; Sun, 3 Nov 2013 10:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rVBYgA9s9XhO for <>; Sun, 3 Nov 2013 10:43:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0B5E711E82E0 for <>; Sun, 3 Nov 2013 10:43:11 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA3Ih6VE025392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Nov 2013 18:43:07 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id rA3Ih6tO019310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:43:06 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id rA3Ih6Qq007942; Sun, 3 Nov 2013 18:43:06 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Nov 2013 10:43:06 -0800
References: <> <> <>
Mime-Version: 1.0 (1.0)
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
X-Mailer: iPhone Mail (11B511)
From: Phil Hunt <>
Date: Sun, 03 Nov 2013 10:43:01 -0800
To: Hannes Tschofenig <>
X-Source-IP: []
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Dynamic Client Registration
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: Sun, 03 Nov 2013 18:43:28 -0000

+1 agreed. There is lots to negotiate still. 


> On Nov 3, 2013, at 1:27, Hannes Tschofenig <> wrote:
> Hi Phil,
> you are right that I should have used different terminology, such as the classification that Justin uses in his document (such as 'open registration', 'protected registration') since the term 'enterprise' and 'web' carries a lot of other emotions and baggage that is not relevant to this discussion.
> What would be good to ensure is that we capture the different classes.
> We have at least the following cases:
> * Out-of-band registration of the developer and the client (as we have it with many deployments of OAuth 2.0 today).
> * Open Registration (where there is no prior interaction between the RP and the IdP).
> * Then, there is a mixed case (where I would include your softare statements) where other information is used for authorizing the client (or client instance).
> [The difficulty I had writing these cases while at the same time looking at draft-richer-oauth-dyn-reg-core-00 tells me that the major differences between the different cases are not immediately visible from Appendix B of draft-richer-oauth-dyn-reg-core-00 even though there is a lot of text.]
> In some sense you have tried your own version of this classification in the software statement document, but as I had noted in my review, I believe you are also not quite there yet.
> Ciao
> Hannes
> Am 02.11.13 17:08, schrieb Phil Hunt:
>> Hannes,
>> Some really good, thought provoking comments! I had not really been
>> focused as much on financial relationships between SP and client. I
>> must confess I considered web clients that set up major relations
>> with service providers. In these cases I dismissed them as a use case
>> because they would most likely configure manually and actually end up
>> in the "static" class of clients. Still, I think we should give this
>> some more careful thought.
>> What were you thinking of as a "enterprise" that differentiates with
>> what we are currently talking about? Enterprise these days has so
>> much derogatory baggage that it is hard to tell what is being
>> referred to.
>> There is a quality of APIs that 6749 focuses on that registration can
>> fix.  6749 works well for "monopoly"/"singleton"  API providers like
>> Google, Facebook, etc.  Yet there are lots of "open" APIs established
>> through open source projects, open standards (e.g. Connect), and
>> commercial cases where customers will deploy their own copies of an
>> API.  I'm not sure this really is "enterprise".  Even in the
>> commercial cases, these APIs are most often made available as "open"
>> for use by third party developers.  For me, this isn't a case of
>> extending OAuth to support "enterprise", but rather extending OAuth
>> to support "open" or "multiple-deployment" APIs on the web no matter
>> where or how they are deployed.
>> Phil
>> @independentid
>> On 2013-11-02, at 3:21 AM, Hannes Tschofenig
>> <> wrote:
>>> Hi all,
>>> reading througth various dynamic client registration document I get
>>> the impression that there is one area of potential disconnect,
>>> namely in the end user / developer experience.
>>> When OpenID started this concept that a random IdP could talk to a
>>> random RP it seemed like a great idea. There was no need to
>>> exchange secrets and go through this complicated introduction
>>> process between the different parties, which sometimes even
>>> required business argeements. Those processes were known from
>>> Kerberos and also from the SAML identity federations.
>>> OpenID looked at the entire step from a technical point of view in
>>> an attempt to exchange the necessary information and then you were
>>> done with it.
>>> However, there was a bit more to this whole process, namely the
>>> entire notion of trust. In particular, there was the problem that
>>> the IdP would hand out information (personal data) to RPs only
>>> based on the user's consent. Of course, things could go wrong and
>>> some RPs misused the data given by the RP. The IdP couldn't really
>>> do anything about that since it knew nothing about the developer at
>>> the RP or the RP itself.
>>> So, how does the IdP ensure that it has some way to improve
>>> security and privacy of their users without handing out just
>>> everything. Of course, the IdP had it's own interest to know to
>>> know data is being passed to.
>>> Jumping to OAuth many deployments required developers to register
>>> and this registration procedure might require lots of information
>>> (such as credit card number, phone number, agreeing the terms of
>>> service, etc.). So, in many cases it wasn't purely about giving the
>>> developer a client-id and a shared secret for the client
>>> application.
>>> Now, here is the challenge: there are obviously different
>>> environments developers produce software for (such as the Web, the
>>> mobile app eco-system, and enterprise environments). They might all
>>> have different processes and expectations about the entire
>>> process.
>>> We have pretty much short-cut the entire story to the purely
>>> technical parts, namely to sending messages around and defining new
>>> attributes and have done very little in describing the process
>>> itself that we assume takes place.
>>> I know that you have these processes in your head when you write
>>> your documents and in discussions I have heard about these
>>> processes. Unfortunately, they aren't really documented anywhere. I
>>> guess it is needless to say that the expectations about how
>>> enterprises plan to deploy software vs. how the same is done for
>>> the Web is somewhat different.
>>> So, I believe it is useful to chat about these aspects even though
>>> they may just lead to a few paragraphs in our documents providing
>>> background information rather than actual normative specification
>>> text.
>>> Ciao Hannes _______________________________________________ OAuth
>>> mailing list