Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt

"Richer, Justin P." <> Tue, 07 May 2013 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AC3B21F86D6 for <>; Tue, 7 May 2013 13:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yLxy1FF25OPN for <>; Tue, 7 May 2013 13:55:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D07C21F85C3 for <>; Tue, 7 May 2013 13:55:40 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 94D4E227006B; Tue, 7 May 2013 16:55:39 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG ( []) by (Postfix) with ESMTP id 7791B227005D; Tue, 7 May 2013 16:55:39 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS01.MITRE.ORG ([]) with mapi id 14.02.0342.003; Tue, 7 May 2013 16:55:39 -0400
From: "Richer, Justin P." <>
To: Josh Mandel <>
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt
Thread-Index: AQHOS0Wu5Sf7tCtsl0WcxmZ0zKLbDJj6dviA
Date: Tue, 07 May 2013 20:55:38 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5FAB4732821E451F97F0868619075F7Fmitreorg_"
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt
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: Tue, 07 May 2013 20:55:45 -0000

A true public client doesn't have a client_secret or its equivalent, so it would have token_endpoint_auth_method = none. A confidential client can't use the implicit flow (since you can't send a client_secret to the auth endpoint), so there's a bit of overlap there.

Would it be useful to have an explanatory paragraph or table to this effect in the draft? I'm currently thinking that'd be a bit overkill, but I'd definitely rather it be clear and unambiguous.

 -- Justin

On May 7, 2013, at 10:09 AM, Josh Mandel <<>>

As I understand it (corrections welcome!) rfc6749 says that public clients:

1.  are defined functionally, as clients "incapable of maintaining the confidentiality of their credentials" [section 2.1]
2.  "MAY establish a client authentication method" if the server allows. e.g. client password auth [section 2.3]

Given 1 and 2, it's technical possible for a public client to be assigned a (not-so-)secret that it uses not for authentication per se, but merely to go through the motions of client password auth.

(How) Does dyn-reg support the registration of a public client that (for whatever reason -- code re-use?) seeks to use a client authentication method? It seems to me that, given the current draft, a registration server couldn't tell such a client from a confidential client  (token_endpoint_auth_method, grant_types, and response_types would be indistinguishable).

Is this use case out of scope?  If so, the spec might benefit from a note to that effect.  If not, an explicit flag at registration time (conveying the app's explicitly asserted "public" vs. "confidential" status) might help servers make better decisions.


On Sun, May 5, 2013 at 12:45 PM, <<>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

        Title           : OAuth 2.0 Dynamic Client Registration Protocol
        Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
        Filename        : draft-ietf-oauth-dyn-reg-10.txt
        Pages           : 25
        Date            : 2013-05-05

   This specification defines an endpoint and protocol for dynamic
   registration of OAuth 2.0 Clients at an Authorization Server and
   methods for the dynamically registered client to manage its

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Internet-Drafts are also available by anonymous FTP at:

OAuth mailing list<>

OAuth mailing list<>