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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Apr 2014 21:14:20 +0200

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)?

* 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")?

* contacts: Would these email addresses be in the format of
mailto:[email-masked] or would you just use [email-masked]?
I am asking because with the URI scheme one could potentially provide
other contact information here as well, such as XMPP URIs or so.

* 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

* 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).

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Wed, 23 Apr 2014 16:25:13 -0400

Thank you for the review, responses inline (and this draft still needs 
to be factored back into the main one):

> information about the client software (provided by the client software

I personally think "homepage" is a clear designator of that, but would 
not be adverse to extending the definition somewhat.

> 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.

> 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 [email-masked]. 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).

> https://www.privacyassociation.org/resource_center/privacy_glossary/privacy_notice

I would think that policy document is a superset of privacy notice, right?

> include a reference to the PoP document (as an informative reference,

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 11:06:52 +0200

Hi Justin,

thanks again for the quick response.

A few notes below.

> 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.

> 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.

> tie a key to a client. This, and the proposed jwks value, provide a hook

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Apr 2014 09:51:03 -0400

> 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.

> 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.