Subject: [OAUTH-WG] Dynamic Client Registration: policy_uri

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2014 14:10:08 +0200

Hi all,

two earlier reviews I have noticed that the policy_uri meta-data
attribute is not correctly specified. I offered a suggestion and in both
cases my request was ignored.

Maybe there is a reason to reject my request but I am uncertain about
the relationship with another meta-data attribute, the terms-of-service
attribute.

Here is what I said in my last review:
http://www.ietf.org/mail-archive/web/oauth/current/msg12879.html

"
policy_uri: In my previous review I argued that the right terminology
here is privacy notice and you can even re-use the IAPP terminology.
Unless the policy URI has nothing to do with privacy I would prefer this
terminology change. If you disagree I would prefer to have a
description about what policy means in this context.
"

Could you guys explain?

Ciao
Hannes

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 Jul 2014 21:43:57 +0900

policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.0
[1].

It goes:

policy_uriOPTIONAL. URL that the Relying Party Client provides to the
End-User to read about the how the profile data will be used. The value of
this field MUST point to a valid web page. The OpenID Provider SHOULD
display this URL to the End-User if it is given. If desired, representation
of this Claim in different languages and scripts is represented as
described in Section 2.1
<http://openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScripts>
.

It is clearly privacy related. In fact, it used to be a part of OpenID
Connect Core in which the RP had to send it to obtain the permission. It is
optional only because in certain enterprise type setting, it is
unnecessary. In the consumer case, I regard it as essential. In any case,
this is something a trust framework should set as its rule, and not the
protocol itself.

The draft -18 text goes:

policy_uri
      URL that points to a human-readable Policy document for the
      client.  The authorization server SHOULD display this URL to the
      end-user if it is given.  The policy usually describes how an end-
      user's data will be used by the client.  The value of this field
      MUST point to a valid web page.  The value of this field MAY be
      internationalized, as described in Section 2.2
<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18#section-2.2>.

It has been converted to be a bit vague. I would +1 to tighten it up. Note
that there is tos_uri to describe the Terms of Service by the client and
poicy_uri is not intended for this purpose but only for the
service/client's privacy policy.

BTW, I just found that a lot of text are more or less the duplicate or
re-statement of [1]. IMHO, it should try to refer the original document
where possible as it is a referable standard, and put [1] in the Reference
section as well.

Best,

Nat

[1] http://openid.net/specs/openid-connect-registration-1_0.html

2014-07-08 21:10 GMT+09:00 Hannes Tschofenig <[email-masked]>:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2014 14:50:58 +0200

For example, even Facebook calls this stuff "Privacy Policy URL".

On 07/08/2014 02:43 PM, Nat Sakimura wrote:
>     OPTIONAL. URL that the Relying Party Client provides to the End-User
>     to read about the how the profile data will be used. The value of
>     this field MUST point to a valid web page. The OpenID Provider
>     SHOULD display this URL to the End-User if it is given. If desired,
>     representation of this Claim in different languages and scripts is
>     represented as described in Section 2.1
>     <http://openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScripts>.
> 
> Connect Core in which the RP had to send it to obtain the permission. It
> is optional only because in certain enterprise type setting, it is
> unnecessary. In the consumer case, I regard it as essential. In any
> case, this is something a trust framework should set as its rule, and
> not the protocol itself. 
> 
> The draft -18 text goes: 
> 
> policy_uri
>       internationalized, as described in Section 2.2 <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18#section-2.2>.
> 
> 
> It has been converted to be a bit vague. I would +1 to tighten it up.
> Note that there is tos_uri to describe the Terms of Service by the
> client and poicy_uri is not intended for this purpose but only for the
> where possible as it is a referable standard, and put [1] in the
> Reference section as well. 
> 
> Best, 
> 
> Nat
> 
> 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>>:
> 
>     Hi all,
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 Jul 2014 22:25:35 +0900

I am not against using the term "Privacy Policy" in the description.
Depending on the jurisdiction and language, direct translation of such
can be "Data Protection Policy", "Personal Data Protection Policy", etc.,
instead so just dodging it by avoiding the label would be more politically
neutral,
but it could be fine after all.

I am not fine with changing the parameter name though.
Slight variation in the parameter between the specs generally do not help
the developers.

Nat

2014-07-08 21:50 GMT+09:00 Hannes Tschofenig <[email-masked]>:

> >     <
> http://openid.bitbucket.org/openid-connect-registration-1_0.html#LanguagesAndScripts
> >.
> >
> >       internationalized, as described in Section 2.2 <
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18#section-2.2>.
> >
> >

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Jul 2014 18:59:15 +0000

I agree with Nat’s assessment.  I’m fine updating the textual description of the parameter, but we should not consider breaking changes to the parameter names at this point.

Do you have specific wording in mind, Hannes?

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Tuesday, July 08, 2014 6:26 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

instead so just dodging it by avoiding the label would be more politically neutral,

I am not fine with changing the parameter name though.
Slight variation in the parameter between the specs generally do not help the developers.

Nat

2014-07-08 21:50 GMT+09:00 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>:
For example, even Facebook calls this stuff "Privacy Policy URL".

On 07/08/2014 02:43 PM, Nat Sakimura wrote:
> 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>:
>
>     Hi all,
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: John Bradley <[email-masked]>
Date: Tue, 8 Jul 2014 15:05:32 -0400

I am OK with clarifying the description as privacy/data protection policy.   I don't think it needs privacy in the parameter name.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 13:24:50 +0200

Here is the suggested new text:

"
policy_uri
   OPTIONAL. URL that the Deployment Organization provides to the end
   user to read about the privacy policy. A privacy policy is a
   statement that describes how the Deployment Organization collects,
   uses, retains and discloses personal information.

   The value of this field MUST point to a valid web page. The
   Deployment Organization SHOULD display this URL to the end user.
   Information for displaying a privacy policy in different languages
   and scripts can be found in Section 2.2.
"

Ciao
Hannes

On 07/08/2014 09:05 PM, John Bradley wrote:
> I am OK with clarifying the description as privacy/data protection
> policy.   I don't think it needs privacy in the parameter name.
> On Jul 8, 2014, at 2:59 PM, Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> I agree with Nat’s assessment.  I’m fine updating the textual
>> description of the parameter, but we should not consider breaking
>> changes to the parameter names at this point.
>>  
>> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Nat Sakimura
>> *Sent:* Tuesday, July 08, 2014 6:26 AM
>> *To:* Hannes Tschofenig
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
>>  
>> 2014-07-08 21:50 GMT+09:00 Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>>:
>> > 2014-07-08 21:10 GMT+09:00 Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>
>> > <mailto:[email-masked] <mailto:[email-masked]>>>:
>> >
>> >     Hi all,
>> >
>> >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]>>
>>

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Jul 2014 16:18:12 +0000

Fine with me.  (I might change "the privacy policy" to "the site's privacy policy".)

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 4:25 AM
To: John Bradley; Mike Jones
Cc: Nat Sakimura; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri

"
policy_uri

Ciao
Hannes

On 07/08/2014 09:05 PM, John Bradley wrote:
>> I agree with Nat's assessment.  I'm fine updating the textual 
>> Depending on the jurisdiction and language, direct translation of 
>> such can be "Data Protection Policy", "Personal Data Protection 
>> Policy", etc., instead so just dodging it by avoiding the label would 
>> be more politically neutral, but it could be fine after all.
>>  
>> > policy_uri came down from OpenID Connect Dynamic Client 
>> > Registraiton 1.0 [1].
>> >
>> > It goes:
>> >
>> > policy_uri
>> > It is clearly privacy related. In fact, it used to be a part of 
>> > OpenID Connect Core in which the RP had to send it to obtain the 
>> > permission. It is optional only because in certain enterprise type 
>> > setting, it is unnecessary. In the consumer case, I regard it as 
>> > essential. In any case, this is something a trust framework should 
>> > set as its rule, and not the protocol itself.
>> >
>> > The draft -18 text goes:
>> >
>> > policy_uri
>> > client and poicy_uri is not intended for this purpose but only for 
>> > the service/client's privacy policy.
>> >
>> > BTW, I just found that a lot of text are more or less the duplicate 
>> > or re-statement of [1]. IMHO, it should try to refer the original 
>> > document where possible as it is a referable standard, and put [1] 
>> > in the Reference section as well.
>> >
>> > Best,
>> >
>> > Nat
>> >
>> >     attribute is not correctly specified. I offered a suggestion 
>> > and
>> in both

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 15 Jul 2014 09:02:42 +0900

Actually, it may be the API's privacy policy so that it can state more
specific purpose than the site's.
So, we should not constrain it to be "site's".

Also, I might prefer "personal data" instead of "personal information" but
that might be just me.

Nat

2014-07-15 1:18 GMT+09:00 Mike Jones <[email-masked]>:

> >> > <mailto:[email-masked] <mailto:[email-masked]
> >>>:
> >> >
> >> >     Hi all,
> >> >