Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-metadata-00

Justin Richer <> Wed, 23 April 2014 20:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8CC01A064C for <>; Wed, 23 Apr 2014 13:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.471
X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RFKZxmvxoKOa for <>; Wed, 23 Apr 2014 13:25:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A8441A0644 for <>; Wed, 23 Apr 2014 13:25:58 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 75ECF1F0837; Wed, 23 Apr 2014 16:25:52 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG ( []) by (Postfix) with ESMTP id 5706A1F0822; Wed, 23 Apr 2014 16:25:52 -0400 (EDT)
Received: from [] ( by IMCCAS01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id; Wed, 23 Apr 2014 16:25:51 -0400
Message-ID: <>
Date: Wed, 23 Apr 2014 16:25:13 -0400
From: Justin Richer <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Hannes Tschofenig <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020309060309000809080901"
X-Originating-IP: []
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-metadata-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Apr 2014 20:26:00 -0000

Thank you for the review, responses inline (and this draft still needs 
to be factored back into the main one):

On 04/23/2014 03:14 PM, Hannes Tschofenig wrote:
> Hi all,
> I read through the document as part of my shepherding task; it is nicely
> written and easy to understand.
> I only have a few minor suggestions:
> * client_uri: URL of the homepage of the client.
> Would it be better to say that this is the URI provides further
> information about the client software (provided by the client software
> developer)?

I personally think "homepage" is a clear designator of that, but would 
not be adverse to extending the definition somewhat.

> * logo_uri: The value of this field MUST point to a valid image file.
> Would it make sense to provide a type field here as well, such as in
> HTML (e.g., type="image/png")?

Unless we're going to allow the client to register and manage multiple 
images (please, no), then we shouldn't go out of our way to store 
mimetypes. This is a URL to be fetched and/or stored -- its content 
doesn't much matter.

> * contacts: Would these email addresses be in the format of
> or would you just use
> I am asking because with the URI scheme one could potentially provide
> other contact information here as well, such as XMPP URIs or so.

I think you could do either, but what I've seen deployed is the non-URI 
version of I think it would make sense for it to be 
listed as not just email addresses but also other contact URIs -- 
however, I don't think it's particularly useful to devolve into a full 
contact record. It should be simple and actionable by a person, and 
email fits that bill (as well as XMPP might, arguably).

> * policy_uri: Would it be better to call this a privacy notice rather
> than policy document?
> Here is a short description what a privacy notice is:

I would think that policy document is a superset of privacy notice, right?

> * jwks_uri: The text provides little information about how this element
> is used. I believe that this is an alternative way of using the PoP
> architecture, where the client registers keys with the authorization
> server that can then be tied to access tokens. Right? I could add some
> text in the PoP overview document to explain this and maybe you could
> include a reference to the PoP document (as an informative reference,
> for example).

The text states that this is there for the use of higher level 
protocols. Several of which (including OIDC and BB+, not to mention more 
advanced token types and client authentication methods) have a need to 
tie a key to a client. This, and the proposed jwks value, provide a hook 
for that kind of stuff.

  -- Justin

> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list