backchannel/endpoint URLs, desired attributes
Jonathan Coffman
jonathan.coffman at gmail.com
Tue Dec 15 22:26:29 UTC 2009
Not to be too much of a stickler but I believe we're referring to a
specific use case/need for 'salutation' not to be confused with sex,
which is not to be confused with gender :-) (although maybe an RP
wants all 3!)
-
Jonathan Coffman
http://www.jonathancoffman.com
Twitter: @jdcoffman
Sent from my iPhone.
On Dec 15, 2009, at 2:27 PM, Paul Madsen <paulmadsen at rogers.com> wrote:
> If you dont have a pressing need for the user's gender, why ask for
> it?
>
> paul
>
> On 12/15/2009 12:12 PM, Peter Watkins wrote:
>> 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<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
>>>>>>>>
>>
>>>>>> --Breno
>>>>>>
>>
>>>>> --
>>>>> Chris Messina
>>>>> Open Web Advocate
>>>>>
>> _______________________________________________
>> 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
More information about the specs
mailing list