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 <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura >> *Sent:* Tuesday, July 08, 2014 6:26 AM >> *To:* Hannes Tschofenig >> *Cc:* oauth@ietf.org <mailto:oauth@ietf.org> >> *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 >> <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>: >> 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 >> <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net> >> > <mailto:hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>>: >> > >> > 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 >> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> >> > 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 >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth