+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 <[email protected]> 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 <[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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
