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

Dick Hardt dick at sxip.com
Mon Apr 9 15:10:41 UTC 2007


Hi John

Rather then muddy the waters more on what user-centric is, I prefer  
to view Credentica and IBM's work as privacy enhancing that requires  
a user-centric flow.

There is a difference between user empowerment and user-centric.

btw: I assume you meant blind the IdP from the RP below.

-- Dick

On 9-Apr-07, at 6:50 AM, frumioj at mac.com wrote:

> 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
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>




More information about the general mailing list