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

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>:

> Fine with me.  (I might change "the privacy policy" to "the site's privacy
> policy".)
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]]
> Sent: Monday, July 14, 2014 4:25 AM
> To: John Bradley; Mike Jones
> Cc: Nat Sakimura; [e-mail]
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
>
> Here is the text from the OpenID Connect spec (as provided by Nat):
>
> > policy_uri
> >   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
> >.
>
>
> Here is the draft -18 text:
>
> > 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>.
>
>
> 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 <[e-mail]
> > <mailto:[e-mail]>> 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.
> >>
> >> Do you have specific wording in mind, Hannes?
> >>
> >>                                                             -- Mike
> >>
> >> *From:* OAuth [mailto:[e-mail]] *On Behalf Of *Nat
> >> Sakimura
> >> *Sent:* Tuesday, July 08, 2014 6:26 AM
> >> *To:* Hannes Tschofenig
> >> *Cc:* [e-mail] <mailto:[e-mail]>
> >> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
> >>
> >> 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
> >> <[e-mail] <mailto:[e-mail]>>:
> >> For example, even Facebook calls this stuff "Privacy Policy URL".
> >>
> >> On 07/08/2014 02:43 PM, Nat Sakimura wrote:
> >> > policy_uri came down from OpenID Connect Dynamic Client
> >> > Registraiton 1.0 [1].
> >> >
> >> > It goes:
> >> >
> >> > policy_uri
> >> >     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
> >.
> >> >
> >> > 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
> >> <[e-mail] <mailto:[e-mail]>
> >> > <mailto:[e-mail] <mailto:[e-mail]
> >>>:
> >> >
> >> >     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
> >> >
> >> >
> >> >     _______________________________________________
> >> >     OAuth mailing list
> >> >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >> <mailto:[e-mail]>>
> >>
> >> >     https://www.ietf.org/mailman/listinfo/oauth
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Nat Sakimura (=nat)
> >> > Chairman, OpenID Foundation
> >> > http://nat.sakimura.org/
> >> > @_nat_en
> >>
> >>
> >>
> >>
> >> --
> >> Nat Sakimura (=nat)
> >> Chairman, OpenID Foundation
> >> http://nat.sakimura.org/
> >> @_nat_en
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
>


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