Re: [OAUTH-WG] FW: Review of the Dynamic Registration Draft

Justin Richer <jricher@mitre.org> Tue, 04 June 2013 17:33 UTC

Return-Path: <jricher@mitre.org>
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 ED9CD21F8FB6 for <oauth@ietfa.amsl.com>; Tue, 4 Jun 2013 10:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.779
X-Spam-Level:
X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, 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 yBKV6roMCmfI for <oauth@ietfa.amsl.com>; Tue, 4 Jun 2013 10:33:49 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5EC21F9EE0 for <OAuth@ietf.org>; Tue, 4 Jun 2013 09:00:37 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF67E1F0351; Tue, 4 Jun 2013 12:00:33 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C1E341F038E; Tue, 4 Jun 2013 12:00:33 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 12:00:33 -0400
Message-ID: <51AE0EF3.8040809@mitre.org>
Date: Tue, 04 Jun 2013 11:59:47 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
References: <1373E8CE237FCC43BCA36C6558612D2A9F1480@USCHMBX001.nsn-intra.net>
In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2A9F1480@USCHMBX001.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.56]
Cc: "OAuth@ietf.org" <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] FW: Review of the Dynamic Registration Draft
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: Tue, 04 Jun 2013 17:33:55 -0000

On 06/04/2013 08:06 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Re-send: my earlier mail seems to have gotten lost.
>
> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Tuesday, June 04, 2013 2:21 PM
> To: 'OAuth@ietf.org'
> Subject: Review of the Dynamic Registration Draft
>
> Dear draft authors, Dear working group,
>
> I read through the dynamic registration draft and here a few observations I have made:
>
> * The 'Initial Access Token' is really more a developer identifier. If you give it a different
> name then it might be more intuitive for the reader since the current wording is a bit fuzzy.
"Initial Access Token" is a name added in the latest draft to call it 
out as a separate object. I'd be happy to have a better name for it, but 
it's not a developer identifier, because:
> For example, in Section 1.3 you only hint to the fact that this identifier refers to the
> developer later in the text.
This is because it might not refer to the developer at all. In practice, 
we've seen it tied to a developer, but it could be tied to an 
enterprise's application publishing system or any number of other 
things. At its root, it's an OAuth 2.0 access token that controls 
authorized access to the Client Registration Endpoint. However you want 
to get an OAuth 2.0 token is your own business and out of scope for the 
draft.

>
> * From the description I have problems understanding the value of the "Registration Access Token".
> I believe you can accomplish exactly the same security benefits if you just use the client
> credentials instead. Do I see this wrong?
Yes, you've got it wrong. The lifecycles and targets of these two items 
are different, as explained in the client tokens and credentials section 
(1.3). The registration access token is issued by the registration 
endpoint and used at the client information endpoint. The client 
credentials are issued by the registration endpoint and used at the 
token endpoint. The former is required, the latter is optional.

While it seems like you can just re-use the client credentials, this is 
only true if you have client credentials issued by the server, which 
isn't the case for public clients. There is still a use for public 
clients, though it's very true that clients that used to *have* to be 
public (such as native clients) can now register each instance on its 
own behalf using this protocol and they don't need to be public anymore. 
However, requiring public clients to have client credentials just to do 
registration doesn't make sense and is very difficult to implement. We 
know this because the OpenID Connect group *tried* to do this and it 
doesn't work. I would rather we learn from their well-documented mistake 
instead of trying to repeat it again.

And there are still useful public clients, such as:

> * OAuth 2.0 supports a number of authorization grants and I have assumed that the dynamic
> client registration would focus on the authorization code grant. To my surprise the
> implicit grant also seems to be supported. The implicit grant has weak security properties
> and it's usage should actually be discouraged. Why would you want to support the implicit
> grant for the dynamic client registration?
The dynamic registration draft should support any and all authorization 
grants, why would it focus on just one? And the use case for a dynamic 
registration of an implicit grant is clear in the case where you have an 
implicit client talking to multiple authorization servers. It needs to 
get its client_id from each auth server in order to talk to them, 
otherwise you've got to come up with some other mechanism to publish an 
agreed-upon client_id for a public client across all auth servers. Why 
do that when you can just register at each one like you would with any 
other grant type?

>
> * There is a lot of RFC 2119 language in the document but it is used in a way that does not
> relate to protocol interoperability. Every time you write SHOULD or MAY think about whether
> a developer could write some useful code. Just to give you an example:
>
> "
>     client_name
>        Human-readable name of the Client to be presented to the user.  If
>        omitted, the Authorization Server MAY display the raw "client_id"
>        value to the user instead.
> "
>
> First, in this sentence what is presented to the user isn't really part of protocol interoperability.
> So, I wouldn't use RFC 2119 language here. What is necessary for protocol interoperability is whether
> the field is optional/mandatory to send by the client-side, and optional/mandatory to understand on
> the server-side. Additionally, do you think that an end user will likely see a lot of meaning in the
> client_id, which is a random string. What is the end user supposed to use that information for?
It's a suggestion for consistent user experience at the authorization 
page and letting the developers of the applications on both ends know 
what a server might do with that particular field. If it's better for 
this to be non-normative, we can lowercase all of those.

>
> Another example:
> "
>     Extensions and profiles of this specification MAY expand this list,
>     but Authorization Servers MUST accept or ignore all parameters on
>     this list.  The Authorization Server MUST ignore any additional
>     parameters sent by the Client that it does not understand.
> "
>
> In the first sentence you don't want to use RFC 2119 language either. If there are ways to extend the
> functionality via registries then point to the sections that explain how to extend it. The next two
> sentences are confusing. It seems that you want to have any additional parameter to be purely optional
> for the authorization server to understand. That's fine but what does this sentence then mean:
> "Authorization Servers MUST accept or ignore all parameters on this list."?
That last bit's probably a wording problem, what I'm trying to say is 
that the server can't reject a message with one of the parameters on 
this list. This is for interoperability purposes -- you're allowed to at 
the very least send everything on this list to any server. Some servers 
can accept more, and some might require more and need to document that 
appropriately. If there's a better way to tie that together, let me know.

>
> * An editorial issue: There is an excessive usage of capitalization in the document. If you look
> at previously published RFCs in the OAuth working group you will noticed that the RFC editor
> changes those to lower-case. For example, just use authorization server instead of Authorization
> Server. Same for Client, Developer, etc.

I was trying to use the terminology as defined and used in RFC6749. I 
can lowercase those.

>
> Ciao
> Hannes
>
> PS: I obviously noticed that the WGLC had trigger some discussion. In some sense that's good since this
> is what WGLCs are for. On the other hand it would be good to reach an agreement on the open issues.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth