Hi Dick, 1. IdP's "advertising" a list of sites that accept OpenID - like the way PayPal list stores that accept their currency I guess. It's annoying to a user to have to come back to the place they just clicked in order to click a second time in order to go where they wanted to in the first place... Better to send them where they want when they click the first time...
2. Privacy and delegation: if we force the user to initially interact with the RP, this gives the RP the opportunity to profile our users, start collecting (and sharing with other RPs) correlating information about them, and otherwise destroys IdP ability to protect user privacy. Basically - this comes back to your "Discussion: bookmark login url discovery" message - and for the sake of additionally supporting future security enhancements (eg: anti-phishing), I'd recommend we place something inside the RP's login <FORM> page, like a <META> or <LINK> tag, for browser agents to use, or IdPs to find via referrer URLs. Kind Regards, Chris Drake Monday, October 16, 2006, 3:36:53 AM, you wrote: DH> Hi Chris DH> Would you clarify these IdP initiated scenarios? DH> I envisioned that an IdP learned of an RP from the user have an DH> initial interaction with the RP. The IdP would then save the RP URL DH> for later use in case the user wanted to go back to the RP directly DH> from the IdP. DH> -- Dick DH> On 15-Oct-06, at 10:30 AM, Chris Drake wrote: >> Hi Drummond, >> >> Don't forget we'll need some way for an IdP to discover the return_to >> URL from an RP in the IdP-initiated scenarios (I'd suggest a META or >> LINK tag in the web page that the RP displays for accepting a login, >> so an IdP (or browser plugin agent!) can "discover" this by parsing >> the referrer page directly. There's a lot of anti-phishing work >> taking place right now: such a scheme would allow OpenID instant >> access to these new standards too.) >> >> Kind Regards, >> Chris Drake >> >> >> Monday, October 16, 2006, 2:59:12 AM, you wrote: >> >> DR> +1. All of the "defined algorithms for obtaining the XRDS >> document" from >> DR> either a URL or XRI will be going into Working Draft 11 of XRI >> Resolution >> DR> 2.0 starting this week. So it seems all the OpenID >> Authentication 2.0 spec >> DR> needs to specify is that they work against the return_to URL. >> >> DR> =Drummond >> >> DR> -----Original Message----- >> DR> From: [EMAIL PROTECTED] >> DR> [mailto:[EMAIL PROTECTED] On Behalf >> DR> Of Johannes Ernst >> DR> Sent: Sunday, October 15, 2006 12:00 AM >> DR> To: specs@openid.net >> DR> Subject: Re: Discussion: RP Yadis URL? >> >> DR> Yes. Or any of the other defined algorithms for obtaining the XRDS >> DR> file, given the return_to URL. >> >> DR> On Oct 14, 2006, at 23:50, Dick Hardt wrote: >> >>>> I assume you are referring to the return_to URL? >>>> >>>> Current libraries add all kinds of parameters to that URL, would >>>> you be suggesting that the IdP does a GET on the return_to URL with >>>> content-type of XRDS? >>>> >>>> If so, then we should add that to the spec. I'd then like to get >>>> clear on what would need to be in the Yadis file for indicating the >>>> login_url. >>>> >>>> -- Dick >>>> >>>> On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote: >>>> >>>>> Given that the RP has at least one URL, we can perform regular >>>>> Yadis discovery on it. (Likely, all of the RP's URLs point to the >>>>> same Yadis document.) >>>>> >>>>> I don't think an extension to the protocol is needed. >>>>> >>>>> On Oct 14, 2006, at 22:39, Dick Hardt wrote: >>>>> >>>>>> Currently there is no method for the IdP to learn anything >>>>>> about the >>>>>> RP. As a path for extensibility, would anyone have a problem with >>>>>> having an optional parameter in the AuthN Request for the >>>>>> location of >>>>>> the RP's Yadis document? >>>>>> >>>>>> -- Dick >>>>>> _______________________________________________ >>>>>> specs mailing list >>>>>> specs@openid.net >>>>>> http://openid.net/mailman/listinfo/specs >>>>> >>>>> Johannes Ernst >>>>> NetMesh Inc. >>>>> >>>>> <lid.gif> >>>>> http://netmesh.info/jernst >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> specs@openid.net >>>>> http://openid.net/mailman/listinfo/specs >> >> DR> Johannes Ernst >> DR> NetMesh Inc. >> >> >> DR> _______________________________________________ >> DR> specs mailing list >> DR> specs@openid.net >> DR> 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
