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

Justin Richer <> Thu, 24 April 2014 13:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C22EE1A0232 for <>; Thu, 24 Apr 2014 06:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mWq-UzWpTvYA for <>; Thu, 24 Apr 2014 06:51:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 570F81A01E3 for <>; Thu, 24 Apr 2014 06:51:49 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 47A3D2260071; Thu, 24 Apr 2014 09:51:43 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG ( []) by (Postfix) with ESMTP id 3304E2260070; Thu, 24 Apr 2014 09:51:43 -0400 (EDT)
Received: from [] ( by IMCCAS03.MITRE.ORG ( with Microsoft SMTP Server (TLS) id; Thu, 24 Apr 2014 09:51:42 -0400
Message-ID: <>
Date: Thu, 24 Apr 2014 09:51:03 -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: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Thu, 24 Apr 2014 13:51:53 -0000

On 04/24/2014 05:06 AM, Hannes Tschofenig wrote:
> Hi Justin,
> thanks again for the quick response.
> A few notes below.
> On 04/23/2014 10:25 PM, Justin Richer wrote:
>> 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).
> Maybe you want to say that this is a list of email addresses without the
> mailto URI scheme prefix. I am just seeing others putting all sorts of
> different stuff in there and expect it to work.

 From what I've seen, it's meant to be a human-facing string. So we 
should either call it a plain text string that MAY be an email address 
or other contact URI, or a formatted string with a particular format 
such as email without the mailto: scheme. I would lean toward the former 
and wash our hands of it. If people want a structured contact thing, 
people can standardize around an extension on a new metadata field.

>>> * 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?
> I am not sure what a policy document is.
> When you register your application with Facebook then you have to
> provide a link to your privacy notice. That made sense to me given the
> nature of the data sharing that is going on.
>>> * 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.
> It is difficult to describe the semantic if it is not further explained
> how it is supposed to be used. Is this field used in OpenID Connect?

Yes, it's used in OpenID Connect and other protocols that add 
key-related stuff on top of it.

> Ciao
> hannes
>>   -- Justin
>>> Ciao
>>> Hannes
>>> _______________________________________________
>>> OAuth mailing list