Yahoo available AX attrs - backchannel/endpoint URLs

Wed Dec 9 13:17:55 UTC 2009

Avatars would definitely be huge. I can't tell you how frustrating it  
is as a user to update my avatar on all of the hundreds of sites I may  
encounter that require login.

Professionally, I've run into problems when bringing up Gravatar as a  
potential option... but again, that sets the bar so high that users  
are pretty unlikely to even go through that process.

Jonathan

On Dec 9, 2009, at 2:09 AM, Chris Messina wrote:

> +1. I think those are the basic profile building blocks for social  
> software. The avatar is something we particularly need for openid.
>
> Sent from my iPhone 2G
>
> On Dec 8, 2009, at 22:06, John Panzer <john at johnpanzer.com> wrote:
>
>> For my use cases, the important things are, unscientifically,
>>
>> 1. Display name
>> 2. Avatar / photo
>> 3. Preferred link to human-readable online presence -- profile,  
>> blog, whatever strikes their fancy.
>>
>>
>>
>> On Tue, Dec 8, 2009 at 8:38 PM, David Recordon  
>> <recordond at gmail.com> wrote:
>> I'm sure that the data is wildly out of date, but at the time the  
>> SREG
>> fields (http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format 
>> )
>> were based on looking at what a few hundred different sites were
>> asking for.
>>
>> I unscientifically think that the extremely common stuff is:
>>  - Name
>>  - Avatar / photo
>>  - Email address
>>
>> Scientifically, we should actually put some effort into looking at
>> sign in pages again. :)
>>
>> --David
>>
>> On Tue, Dec 8, 2009 at 7:59 PM, Jonathan Coffman
>> <jonathan.coffman at gmail.com> wrote:
>> > 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
>> >
>> >
>> > _______________________________________________
>> > specs mailing list
>> > specs at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs
>> >
>> >
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
> _______________________________________________
> 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/20091209/79d7b045/attachment.htm>