Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-metadata-00
Justin Richer <jricher@mitre.org> Thu, 24 April 2014 13:51 UTC
Return-Path: <jricher@mitre.org>
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 C22EE1A0232 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 06:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWq-UzWpTvYA for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 06:51:49 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 570F81A01E3 for <oauth@ietf.org>; Thu, 24 Apr 2014 06:51:49 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 47A3D2260071; Thu, 24 Apr 2014 09:51:43 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3304E2260070; Thu, 24 Apr 2014 09:51:43 -0400 (EDT)
Received: from [10.146.15.6] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 24 Apr 2014 09:51:42 -0400
Message-ID: <535916C7.6000900@mitre.org>
Date: Thu, 24 Apr 2014 09:51:03 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
References: <5358110C.9020503@gmx.net> <535821A9.8020503@mitre.org> <5358D42C.3000803@gmx.net>
In-Reply-To: <5358D42C.3000803@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.51]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8Rh1YZccRDOFYcc05LvSLGBrnKw
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-metadata-00
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: 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 >>> mailto:user@example.com or would you just use joe@example.com? >>> 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 joe@example.com. 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: >>> https://www.privacyassociation.org/resource_center/privacy_glossary/privacy_notice >> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-met… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg… Justin Richer
- Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg… Justin Richer