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

Chris Drake christopher at pobox.com
Wed Apr 4 07:25:22 UTC 2007


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






More information about the general mailing list