Yahoo available AX attrs - backchannel/endpoint URLs

[Jonathan Coffman]

Out of curiosity, beyond the email discussion below what are the  
primary metadata needs around the other major (PoCo) fields?

Speaking to the use-cases I work off of here at PBS, I'm primarily  
concerned about emails being verified (and a signup date is also  
useful) and am most inclined to trust the OP (especially if it were a  
white-listed or otherwise vetted iDP).

Jonathan


On Dec 8, 2009, at 2:17 PM, Chris Messina wrote:

> 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
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091208/1ed1cd20/attachment.htm>