backchannel/endpoint URLs, desired attributes

Tue Dec 15 19:27:35 UTC 2009

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
>
>    