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