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
