Yahoo available AX attrs - backchannel/endpoint URLs

Peter Watkins peterw at tux.org
Wed Dec 9 02:53:03 UTC 2009


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



More information about the specs mailing list