I'm responsible for a City government web site, so not large but
perhaps representative of a large set of potential RPs:
Our most wanted list, in order, is:
1) Display name
(for public comments, community forums, etc.)
2) Email address
(so we can send updates on service requests submitted by the user, etc.)
3) Full name and mailing address
(to make it easier to fill out forms for paying fees & taxes online)
4) Phone number
(alternative to email)
Once we initiate a program to verify residency/identity, I think we'd also
be interested in
5) Preferred links to human-readable online presence
(as John said, but plural, so residents and biz owners might
be able to highlight multiple sites)
6) Avatars
(I frankly hadn't given this much thought, but that's probably because
I'm not fond of them myself.)
Both the preferred links and avatars would open avenues for self-promotion,
and I'd rather limit those opportunities to individuals with obvious
ties to the community. We don't have much staff for moderating a
wide-open forum.
Gender wouldn't normally be on my list, but since it's in AX Schema and
available from one of our two featured directed identity OPs (Yahoo), we
will be adding that to our user profile model and requesting it from OPs
when our users indicate that we may ask OPs for contact info.
We'd love to get metadata about the attributes, too -- date on which
the email address was verified, whether the OP vouches that the avatar
is actually a picture of the individual, etc.
-Peter
On Tue, Dec 08, 2009 at 10:06:18PM -0800, John Panzer 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
> > >> --Breno
> > > --
> > > Chris Messina
> > > Open Web Advocate
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
