[OpenID] User-centric criteria & how well current proposals stack up

frumioj at mac.com frumioj at mac.com
Mon Apr 9 13:50:08 UTC 2007


Hi Dick,

Dick Hardt wrote:
> Note that Stefan has a very different definition of user centric then  
> most of the rest of us ... the model is very skewed towards the  
> privacy enhancing tech that he is flogging ... :-)

Although one might quibble with the order of "least user-centric -> most
user-centric" tech that Stefan gives, I think his list of aspects is a
very reasonable piece of work, irrespective of his work on
privacy-enhancing credentials.

Furthermore, I would note that privacy-enhancing credentials (such as
Credentica's, or IBMs Camenisch credentials) that can blind the identity
of the RP from the IdP, and allow the user to avoid passing passwords
cleartext across a network /are/ very user-centric, in that they help
avoid phishing of user credentials, and the tracking of user behaviour
by a "panopticon" IdP.

I hope that the "definition of user-centric" of those in the OpenID
community to which you refer is close to what Stefan is suggesting
below. You could do a lot worse.

Disclosure: I don't work for or with Stefan.

Regards,

- John
> 
> On 4-Apr-07, at 12:25 AM, Chris Drake wrote:
> 
>> Hi,
>>
>> For those who've not seen the idworkshop list, here's a post neatly
>> explaining "user centric", unfortunately painting OpenID as one of the
>> "least user centric" protocols currently available.
>>
>> Kind Regards,
>> Chris Drake
>>
>>
>> Thursday, February 8, 2007, 12:40:46 AM, Stefan Brands wrote:
>>
>> SB> Many of the criteria used by the broad sub-field of modern  
>> crypto that has
>> SB> been researching "user empowerment" architectures for I&AM are  
>> listed at
>> SB> http://www.idcorner.org/?p=142 (see below). According to these  
>> criteria, the
>> SB> current ID schemes stack up as follows:
>>
>>
>> SB>    LEAST USER-CENTRIC         National id card
>> SB>           ^                   tied to central DB
>> SB>           |
>> SB>           |                   MS Passport (V1)
>> SB>           .
>> SB>           .                   OpenID
>> SB>           .                   .
>> SB>           .                   .
>> SB>           .                   .
>> SB>           .                   Liberty ID-WSF
>> SB>           .
>> SB>           .                   CardSpace
>> SB>           .
>> SB>           .                   Higgins + IBM Idemix
>> SB>           .                   .
>> SB>           .                   .
>> SB>           .                   .
>> SB>           |                   CardSpace/ID-WSF/Higgins
>> SB>                               combined with strong PET(s)
>> SB>    MOST USER-CENTRIC
>>
>>
>> SB> Partial list of user-centric aspects in I&AM:
>> SB> =============================================
>>
>> SB> - Can the data subject consent to or withhold the release of
>> SB> identity data? (on a case-by-case basis, informed, non-coerced, .)
>>
>> SB> -Can the data subject see the actual identity data that is  
>> flowing?
>> SB> (Or is it encrypted for the SP?)
>>
>> SB> -Can the data subject hide the identity of the RP from the IdP?
>>
>> SB> -Can the data subject hide the RP's request from the IdP?
>>
>> SB> -Can the data subject locally store and manage long-lived identity
>> SB> credentials? (If not, then all the data subject's actions - and  
>> therefore
>> SB> accounts - can be traced and linked via trivial timing analysis.)
>>
>> SB> -Can the data subject selectively disclose attribute data on  
>> identity
>> SB> credentials? (If not, the data subject cannot reveal the  
>> minimum information
>> SB> required for long-lived identity credentials.)
>>
>> SB> -Can the data subject avoid correlation handles across IdPs and  
>> SPs? (If
>> SB> not, then data subjects are unknowingly linking up -  
>> "federating" - all of
>> SB> their account relations with each and every disclosure.)
>>
>> SB> - With regard to the last two, consider also the degree to  
>> which a user must
>> SB> trust third parties; in the extreme, there is no need to trust  
>> any third
>> SB> party. In practice, one will always have to trust at the very  
>> least the
>> SB> proper functioning of one's own software.
>>
>> SB> NOTE: This list can be expanded with a number of aspects  
>> related to
>> SB> - UI-related control functions
>> SB> - Security for users
>>
>>
>> SB> --~--~---------~--~----~------------~-------~--~----~
>> SB> You received this message because you are subscribed to the
>> SB> Google Groups "Identity Gang" group.
>> SB> To post to this group, send email to idworkshop at googlegroups.com
>> SB> To unsubscribe from this group, send email to
>> SB> idworkshop-unsubscribe at googlegroups.com
>> SB> For more options, visit this group at
>> SB> http://groups-beta.google.com/group/idworkshop?hl=en
>> SB> -~----------~----~----~----~------~----~------~--~---
>>
>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general




More information about the general mailing list