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.
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.) 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. -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins <[email protected]> wrote: > On Tue, Dec 08, 2009 at 10:32:12AM -0800, John Panzer wrote: > > > provide to RPs. If you send an endpoint URL to the RP instead of the > > information itself, the RP can then retrieve it via a backchannel (and > cache > > it). If you have private data, use a capability URL with a token that > > allows read-only access. > > Exactly. OpenID requests and responses are very chatty, and backchannel > URLs could be an easy way to get around the 2k GET limit (the cost of > course being additional time needed to make the additional HTTP requests). > > I don't see any reason for backchannel URLs to be requested multiple times, > so in addition to a request or response using strongly random nonces in > the backchannel URLs, the backchannel URLs should be very short-lived, > probably each side "SHOULD" allow a URL to be requested only once, and > throw a 403/404 for subsequent requests. > > Is there any draft of AX using backchannel URLs? > > -Peter >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
