On Tue, Dec 08, 2009 at 11:01:49AM -0800, John Panzer wrote: > For "one-time" URLs, you'd probably want to allow for retries for a short > period (or just allow it to be accessed for say 5m) which would have > approximately the same level of protection.
Yes, and that would make debugging easier. :-) More importantly, that would be good for transparency. One of the nice things about OpenID is that the information is visible to the end-user's web client throughout the process. It's easy to imagine a browser plugin that would show the user what info the OP is *really* providing and give the individual the ability to abort an authentication flow. Making the backchannel URLs short-lived as you suggest would allow end-users to better verify what data is passing between RP and OP (so long as the signature is not backchannel). > You could also imagine long-lived capabilities along the lines of OAuth > tokens that allow RPs to repeatedly refresh the data as needed. (Better of > course if they can subscribe to changes, but that's an implementation detail > and definitely a separate spec.) As long as it's part of OpenID, i.e. all OPs use the same mechanism. It would be great if the RP could specify a period of time during which it would like access to updates (polled or subscribe/callback), and if the OP response could override that request. RP wants updates for 10 years, but OP queries the user and the user says only allow updates for one month. End result: OP provides data, tells RP the access is limited to one month. And, as with most OAuth setups, the user should have the ability to deauthorize RPs on the OP side. > Given that AX already supports requesting URL-valued data (e.g., profile > photos) I think this just comes down to defining a fairly complicated data > type for AX and passing a URL around. As long as it works, I'd be happy. -Peter _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
