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:u...@example.com or would you just use j...@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 j...@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. > >> * 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? Ciao hannes > > -- Justin > >> >> Ciao >> Hannes >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
