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