Yahoo available AX attrs - backchannel/endpoint URLs

Chris Messina chris.messina at gmail.com
Tue Dec 8 19:17:02 UTC 2009


Is it worth looking at how Facebook handles the passing of profile data? Or
is their architecture/use case different?

http://wiki.developers.facebook.com/index.php/Users.getInfo

On Tue, Dec 8, 2009 at 11:08 AM, Breno de Medeiros <breno at google.com> wrote:

> On Tue, Dec 8, 2009 at 11:01 AM, John Panzer <jpanzer at google.com> 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.
> > 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.
>
> A more lightweight alternative is to adopt an 'artifact' mode where
> most of the OpenID assertion (request and response) can be passed in
> the backchannel. That is a bit more difficult to implement but easier
> to spec (because the existing URLs can be used) and more general
> (compacts all extensions, not only AX).
>
> > --
> > John Panzer / Google
> > jpanzer at google.com / abstractioneer.org / @jpanzer
> >
> >
> >
> > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins <peterw at tux.org> 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
> > specs at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091208/7c7d80b6/attachment.htm>


More information about the specs mailing list