+1 RP discovery. If something is likely to persist beyond the active request, then it shouldn't be in the request necessarily.
RP discovery would allow, for instance, an OP to show a page of all RPs a user has connected to, and links to their respective privacy policies. They can model the OP as a single database row with a "privacy_url" field, instead of having to keep track of a different url for every user, when in fact that are largely the same thing. I like the "service" suggestion as made below. I'm worried about spoiling the simplicity of the UX extension by making it a "kitchen sink" when CX or even PAPE is more appropriate. From an engineering perspective, it seems this belongs in a simple RP discovery spec. There are other nice things like RP images and nice display names that would be nice to include. Also, curious: what's the process for rolling extensions back into revs of the main spec? It will become weird that "return_to" discovery is in the spec but this isn't. On 6/2/09 11:44 AM, "Allen Tom" <a...@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 <http://openid.net> @netmesh.us <http://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" <a...@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@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ________________________________ _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
