SREG's Privacy Policy URL

Andrew Arnott andrewarnott at gmail.com
Tue Jun 2 18:46:08 UTC 2009


Whether we go for passing a parameter or not, I like the idea of (also)
having RP discovery offer a URL as well so that unsolicited assertions from
OPs can show the privacy policy to the user.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Tue, Jun 2, 2009 at 11:44 AM, Allen Tom <atom at yahoo-inc.com> wrote:

>  The internationalization problem is one of the reasons why it might make
> more sense for the privacy policy url to be passed in as a parameter by the
> RP. The RP already is passing the user's language to the OP as part of the
> UI extension, so we could just make this an additional parameter.
>
> Alternatively, we can just say that the RP has a single privacy policy url,
> and the Privacy Polocy URL can take an optional openid.ui.lang parameter.
> The privacy policy url can be discoverable.
>
> Allen
>
>
>
> Andrew Arnott wrote:
>
> Would internationalizing entail the OP getting the URL for the RP's privacy
> policy in the right language?
>
> If so, why not just have one URL and let the RP detect the user agent's
> preferred language? (Yes, I know the UI extension has this for the reason
> that the user agent isn't properly configured, so it's an interesting
> point...)
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Tue, Jun 2, 2009 at 11:24 AM, Johannes Ernst <jernst+openid.net@
> netmesh.us> wrote:
>
>> Is there a way this can be internationalized?
>>
>> On Jun 2, 2009, at 11:14, Allen Tom wrote:
>>
>>  OK, how about if we define a new Privacy Policy <Service> for RPs to
>>> include in their XRDS, with a link to their privacy policy?
>>>
>>> So the RP would just include the following snippet in its discovery
>>> document, discoverable under its realm:
>>>
>>> <Service>
>>> <Type>http://specs.openid.net/path/to/privacy/policy</type>
>>> <URI>http://www.relyingparty.com/path/to/privacy/policy.html
>>> </Service>
>>>
>>> I'm not sure where we can formally document this. I guess we can put it
>>> in the UI spec?
>>>
>>> Allen
>>>
>>>
>>>
>>> George Fletcher wrote:
>>>
>>>> I think for a short-term solution we'd need to define service "types"
>>>> for the privacy policy and TOS for XRDS.
>>>>
>>>> For the long-term, the same could potentially be used as "rel" values in
>>>> the XRD markup. The XRD spec is solidifying but is not 100% stable.
>>>>
>>>> I think we should have a discovery option regardless of whether we
>>>> update UX or AX. So I'd like to see a proposal for XRDS and then when XRD is
>>>> available, supporting that.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> Allen Tom wrote:
>>>>
>>>>> Hi Luke,
>>>>>
>>>>> Yes, this is what we're looking for. Currently, in OpenID, the only way
>>>>> for the RP to link to its privacy policy (which is sort of like linking to
>>>>> its ToS) is by passing it in the openid.sreg.policy_url parameter using
>>>>> SREG.
>>>>>
>>>>> Since we're trying to deprecate SREG, we can try to move this parameter
>>>>> to either the UI or AX Extension, or move it into Discovery.
>>>>>
>>>>> Is there an actual Discovery spec?
>>>>>
>>>>> Allen
>>>>>
>>>>>
>>>>> Luke Shepard wrote:
>>>>>
>>>>>> FWIW, Facebook Connect allows relying parties to define a “terms of
>>>>>> service” url. We then show that link to users when they click on it. With
>>>>>> OpenID, the equivalent URL would be set using relying party discovery. Is
>>>>>> this more or less what you’re looking for?
>>>>>>
>>>>>> Screenshot:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/2/09 10:21 AM, "Allen Tom" <atom at yahoo-inc.com> wrote:
>>>>>>
>>>>>>
>>>>>>   Alternatively, the RP could publish its privacy policy in its
>>>>>>   discovery
>>>>>>   document, which does make a lot of sense, but I understand that
>>>>>>   there's
>>>>>>   a lot of work going on to define the next generation of
>>>>>>   discovery, and
>>>>>>   I'm not quite sure what the timeframe is for that.
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> specs mailing list
>>>>> specs at openid.net
>>>>> http://openid.net/mailman/listinfo/specs
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
> ------------------------------
>
> _______________________________________________
> specs mailing listspecs at openid.nethttp://openid.net/mailman/listinfo/specs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090602/33e088da/attachment.htm>


More information about the specs mailing list