Re: [OAUTH-WG] Dynamic Client Registration

John Bradley <ve7jtb@ve7jtb.com> Wed, 14 January 2015 00:05 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 8FA7F1B2BC5 for <oauth@ietfa.amsl.com>; Tue, 13 Jan 2015 16:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 2O1t9B1ry5Xj for <oauth@ietfa.amsl.com>; Tue, 13 Jan 2015 16:05:40 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDF21ACE09 for <oauth@ietf.org>; Tue, 13 Jan 2015 16:05:39 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id l6so975524qcy.13 for <oauth@ietf.org>; Tue, 13 Jan 2015 16:05:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Zer9WaI+I1HTcwNZYB4UAhWfSlhUxF8nxNU18xrGMzw=; b=NTBlpKF8mFvIdQJNzaECHaUXJtZ8QJG45/qkIKaJYUYe2bIQLQpgMMPYU/Qjlu+iQL 4JzLHcQ9drUhoWHpzb+72GTbEHcjy0BQt1a5F5fuwpxuitEhg+xbACdakuSFzXRYhlrF f/R/FutLM+AHHr2JTCieIGo1F0/sssUwR5S4NFOfui7saztB6ideoO9U9TNQbZf6oJ2r yppnO6vFu52Lw6zc+r9PCHDAsIlzdN+TsSifZ+aH8SGlH/bHMuiU4E+TYWCBGTsLWtHe s3QZQTxPjMYZnQwAoqLFxUEO3CatzU5FODm/GEUOQTfZGQwm03ta5vqu3U90+F9gybB0 ++VA==
X-Gm-Message-State: ALoCoQk+6OgwTdGHp0ds6M1fWCa7yEAEmPgSVLqj8m5HbGbnpbDBrJ74s+hRltAtI68FxT7YQHhY
X-Received: by 10.140.88.48 with SMTP id s45mr2118353qgd.28.1421193939102; Tue, 13 Jan 2015 16:05:39 -0800 (PST)
Received: from [192.168.8.100] ([181.201.11.224]) by mx.google.com with ESMTPSA id 4sm19048558qgh.22.2015.01.13.16.05.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 16:05:38 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B00AFB09-9EE8-460F-85C2-C4B288D7D6DD"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <C4B77F5C-25F9-4CE2-A784-CD526714BE2F@oracle.com>
Date: Tue, 13 Jan 2015 21:05:33 -0300
Message-Id: <37FEC9CC-64CD-4AC7-A3C4-08A4F957B114@ve7jtb.com>
References: <54B3ABF8.8050007@gmx.net> <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> <C4B77F5C-25F9-4CE2-A784-CD526714BE2F@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Y3TMBurx69akAbtMSKj-bM_Xark>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration
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, 14 Jan 2015 00:05:43 -0000

We have used the dynamic client registration API for building portals for developers to register clients.   
I am seeing that across several telco operators at the moment.

Yes everyone could have custom web pages but this is at-least a common way to build that sort of thing.
This is not just about registering instances of native apps.

The GSMA mobile connect profile is going to use dynamic client registration based on a software statement from a trusted party to allow web sites to register as clients to 800+ AS.

Those sites may well be developers of there own client or have a central admin for several clients.

I don't think that we want to say that it is only the client that interacts with the registration or management endpoint.  
That is too limiting on the applications for this API.

John B.


> On Jan 13, 2015, at 8:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> in line
> Phil
> 
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> 
>> On Jan 13, 2015, at 3:08 PM, Richer, Justin P. <jricher@mitre.org> wrote:
>> 
>> Hi Hannes, thanks for the review. Comments inline.
>> 
>> On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>> 
>>> Hi Justin, Hi all,
>>> 
>>> as noted in my status update I am trying to finalize the pending items.
>>> 
>>> Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my
>>> review of draft-ietf-oauth-dyn-reg-management raised some questions
>>> about the terminology.
>>> 
>>> If you look at the structure of the ToC then you will notice the following:
>>> 
>>> 3.  Client Registration Endpoint  . . . . . . . . . . . . . . . .  13
>>>   3.1.  Client Registration Request . . . . . . . . . . . . . . .  14
>>>     3.1.1.  Client Registration Request Using a Software
>>>             Statement . . . . . . . . . . . . . . . . . . . . . .  15
>>>   3.2.  Client Registration Response  . . . . . . . . . . . . . .  16
>>> 4.  Responses . . . . . . . . . . . . . . . . . . . . . . . . . .  16
>>>   4.1.  Client Information Response . . . . . . . . . . . . . . .  17
>>>   4.2.  Client Registration Error Response  . . . . . . . . . . .  18
>>> 
>>> There is no 'Client Registration Response' in the protocol (only the
>>> Client Information Response) and section 3.2 is pretty much empty and
>>> only points to the later sections. So, I would suggest to do the following.
>>> 
>>> 3.  Client Registration Endpoint
>>>   3.1.  Client Registration Request
>>>     3.1.1.  Client Registration Request Using a Software Statement
>>>   3.2.  Client Registration Response
>>>     3.2.1.  Client Information Response
>>>     3.2.2.  Client Registration Error Response
>>> 
>>> (A section with only a single sub-section is also a sign of a bad
>>> structure.)
>>> 
>> 
>> I'm actually OK with this re-organization, as long as there's no objection from the WG at this stage. I think what we have might be slightly vestigial of the existing document. There *is* a client registration response, but it's one of two things: the information or error response. Collapsing them as above will likely make that section easier to read. Thoughts?
>> 
>>> I re-read the terminology and looked at Figure 1 to see whether it makes
>>> sense and it still does not. I know that there may be many different
>>> deployment options but it should at least be clear to the reader where
>>> information comes from and where does it go.
>>> 
>>> For example, when I try to follow the flow of the software statement
>>> then I read the following:
>>> "
>>> Software Statement: In some cases, a software statement will be issued
>>> directly by the organization or developer that creates the client software.
>>> "
>>> 
>>> What does the figure tell us? It shows us that the client or developer
>>> gets the software assertion.
>>> 
>>>      +--------(A)- Initial Access Token (OPTIONAL)
>>>      |
>>>      |   +----(B)- Software Statement (OPTIONAL)
>>>      |   |
>>>      v   v
>>>  +-----------+                                      +---------------+
>>>  |           |--(C)- Client Registration Request -->|    Client     |
>>>  | Client or |                                      | Registration  |
>>>  | Developer |<-(D)- Client Information Response ---|   Endpoint    |
>>>  |           |                                      +---------------+
>>>  +-----------+
>>> 
>>> Maybe we should illustrate one example that makes sense and then say
>>> that there are others that could be used.
>> 
>> The examples are included in Appendix A. 
>> 
>>> It also does not make sense to
>>> show the developer in the box together with the client since the
>>> developer does not execute a protocol exchange with the client
>>> registration endpoint.
>> 
>> That's not true, a developer (person or organization) could very easily be using the dynamic registration protocol on behalf of the software that they're developing. This is actually used in practice in a number of places, and if you'd like a concrete example just go to the MIT integration test site: https://mitreid.org/manage/dev/dynreg (log in with user/password).
> 
> IMO. This defeats the purpose of dynamic registration. A developer that wants to hand register would go through the SP’s developer support pages as they do now.
> 
> It also won’t work in cases where an individual client will negotiate a client key (where the actual key is not shared and thus the developer (or any other MITM) can’t get in between.
> 
>> 
>>> 
>>> Here is a proposal for improving this:
>>> 
>>> 
>>> FROM:
>>> 
>>>      +--------(A)- Initial Access Token (OPTIONAL)
>>>      |
>>>      |   +----(B)- Software Statement (OPTIONAL)
>>>      |   |
>>>      v   v
>>>  +-----------+                                      +---------------+
>>>  |           |--(C)- Client Registration Request -->|    Client     |
>>>  | Client or |                                      | Registration  |
>>>  | Developer |<-(D)- Client Information Response ---|   Endpoint    |
>>>  |           |                                      +---------------+
>>>  +-----------+
>>> 
>>>  Figure 1: Abstract Dynamic Client Registration Flow
>>> 
>>> TO:
>>> 
>>>  +--------  O  -- (A)- Initial Access Token (OPTIONAL)
>>>  |         /|\
>>>  |   +---- / \ -- (B)- Software Statement (OPTIONAL)
>>>  |   |   Client
>>>  |   |   Developer
>>>  |   |
>>>  v   v
>>> +--------------+                                      +---------------+
>>> |              |--(C)- Client Registration Request -->|    Client     |
>>> |   Client     |                                      | Registration  |
>>> |              |<-(D)- Client Information Response ---|   Endpoint    |
>>> +--------------+                                      +---------------+
>>> 
>>> Figure 1: Abstract Dynamic Client Registration Flow
>>> 
>>> 
>>> Alternatively, one could also separate the distribution of software
>>> statements and the actual protocol exchange. Here is the proposal:
>>> 
>>>  +--------(A)- Initial Access Token (OPTIONAL)
>>>  |
>>>  |   +----(B)- Software Statement (OPTIONAL)
>>>  |   |
>>>  v   v
>>> +-----------+                                      +---------------+
>>> |           |--(C)- Client Registration Request -->|    Client     |
>>> |   Client  |                                      | Registration  |
>>> |           |<-(D)- Client Information Response ---|   Endpoint    |
>>> +-----------+                                      +---------------+
>>> 
>>> Figure 1: Abstract Dynamic Client Registration Flow
>>> 
>>> 
>>>         +---------------+
>>>         | Authorization |
>>>         | Server        |
>>>         +---------------+
>>>               |    Initial
>>>               |(A) Access
>>>               |    Token
>>>               v
>>>                O  Client
>>>       +------ /|\ Developer
>>>       |+----- / \
>>>       ||
>>>    (A)||(B) Software
>>>       ||    Statement
>>>       vv
>>> +-----------+
>>> |           |
>>> |   Client  |
>>> |           |
>>> +-----------+
>>> 
>>> Figure 2: Software Statement / Initial Access Token Distribution Example.
>>> 
>> 
>> This is inaccurate, as described above. I believe we should leave this as is.
>> 
>>> Then, there is also this statement in the Software Statement definition:
>>> 
>>> "
>>>    In other cases, a
>>>    software statement will be issued by a third party organization
>>>    for use by the organization or developer that creates the client
>>>    software.
>>> "
>>> 
>>> In the terminology section we are defining all the parties that are
>>> involved and now this mysterious "third party organization" is
>>> introduced. Is this one of the already defined parties or is this yet
>>> another organization?
>> 
>> This is just exemplary text, saying one way that it could happen. The "mysterious" third party organization is someone who is not the authorization server or software API publisher who issued the statement (those cases are covered by the preceding sentence). They're not a named party, it's just "whoever made the software statement". We are not specifying which software statements the AS decides to trust, since that's a policy decision outside of our control as spec authors. Many authorization servers will only trust software statements that they issue, but others will have a configured set of third parties that they will accept software statements from, probably as part of a trust framework. I think this text should be left as it is unless there's a way to word this so that it doesn't sound like we're adding another explicitly named party to the mix.
>> 
>>> 
>>> Finally, the client developer is defined as a single individual or an
>>> entire organization (i.e., a group of people). However, in the text you
>>> write 'client developer or organization'. For example, look at the
>>> software statement:
>>> 
>>> "In some cases, a software statement will be issued directly by the
>>> organization or developer that creates the client software.
>>> "
>>> 
>>> Wouldn't it be more consistent to use the client developer definition as
>>> is and just turn this sentence into
>>> 
>>> "
>>> In some cases, a software statement will be issued directly by the
>>> client developer.
>>> "
>>> 
>> 
>> Since "developer" can mean individual or organization, I'm fine with this simplifying change as long as there's no objection from the WG.
>> 
>> Thanks again for the review.
>> -- Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth