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).
* 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?
* 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
