Re: [OAUTH-WG] Dynamic Client Registration

Phil Hunt <phil.hunt@oracle.com> Sun, 03 November 2013 18:43 UTC

Return-Path: <phil.hunt@oracle.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 24B9A21F9DCA for <oauth@ietfa.amsl.com>; Sun, 3 Nov 2013 10:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVBYgA9s9XhO for <oauth@ietfa.amsl.com>; Sun, 3 Nov 2013 10:43:19 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E711E82E0 for <oauth@ietf.org>; Sun, 3 Nov 2013 10:43:11 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (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 aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (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 abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA3Ih6Qq007942; Sun, 3 Nov 2013 18:43:06 GMT
Received: from [25.71.163.119] (/24.114.40.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Nov 2013 10:43:06 -0800
References: <5274D238.8070803@gmx.net> <49AA7409-C574-43E4-8D44-827092B356B2@oracle.com> <52761718.2060808@gmx.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <52761718.2060808@gmx.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E3C063D-C3C0-4801-9C46-D0278C919067@oracle.com>
X-Mailer: iPhone Mail (11B511)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Sun, 3 Nov 2013 10:43:01 -0800
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration
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: Sun, 03 Nov 2013 18:43:28 -0000

+1 agreed. There is lots to negotiate still. 

Phil

> On Nov 3, 2013, at 1:27, Hannes Tschofenig <hannes.tschofenig@gmx.net> 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 www.independentid.com phil.hunt@oracle.com
>> 
>> On 2013-11-02, at 3:21 AM, Hannes Tschofenig
>> <hannes.tschofenig@gmx.net> 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 OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>