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

[Dick Hardt]

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 ... :-)

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