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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> > wrote: > >> > >> On Tue, Dec 8, 2009 at 11:01 AM, John Panzer <[email protected]> > 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 > >> > [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 > >> > > >> > > >> > >> > >> > >> -- > >> --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 > >> [email protected] > >> 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 > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > > _______________________________________________ > > specs mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
