W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

Re: Aligning WebID with U2F. Was: UI for client cert selection

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 06 May 2014 15:13:48 -0400
Message-ID: <5369346C.4080205@openlinksw.com>
To: public-webid@w3.org
On 5/6/14 6:30 AM, Nick Jennings wrote:
> On Tue, May 6, 2014 at 12:49 AM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>     On 5/5/14 10:21 AM, Nick Jennings wrote:
>>     Thanks Kingsley, one comment below:
>>     On Mon, May 5, 2014 at 3:23 PM, Kingsley Idehen
>>     <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>>         On 5/5/14 8:45 AM, Nick Jennings wrote:
>>>         Excuse me if I'm missing something, but isn't this more an
>>>         issue of what our expectations are from previous cookie
>>>         usage, rather than an actual problem?
>>         No, there's an actual problem. It boils down to conflating:
>>         1. identity
>>         2. identification
>>         3. authentication.
>>         Identity is an issue missing from many applications and
>>         services due to their underlying programming environment and
>>         frameworks.
>>>         If we use a single browser profile per-cert, then it makes
>>>         sense that you will always be logged in (and that's better
>>>         than being logged out after a certain amount of time, IMO).
>>>         If you want to be anonymous, or log in with a different
>>>         account, use a different profile.
>>         You should be able to have different identifies across
>>         different interactions with services. It isn't about one
>>         identity vs anonymity. It's just about identity,
>>         identification, and authentication en route to a "trust
>>         context" (e.g., a Web of Trust) as a result of identity
>>         verification.
>>     Doesn't it confuse things from a UX perspective to have a ton of
>>     certs to choose from everytime you want to authenticate with a site?
>     No it doesn't. You see, this is one of those "premature
>     optimization" issues that arise from the programmers perspective
>     taking precedence over an actual end-user perspective.
>     If an end-user understands that each certificate is an identity
>     card issued and signed by an identity provider the utility of
>     multiple identity cards becomes apparent.
>     Note, in between verifiable identity and anonymity sits a sweet
>     spot that's increasingly overlooked. Having many identity cards
>     enhances control over privacy. I can have different cards for my
>     different group membership. It should never be an all or nothing
>     proposition, for end-users.
> I see your point, for sure, but as a user I found having a large 
> number of certs (that you still have to choose from yourself) unwieldy.

Yes, because you haven't had to assess the costs vs the benefits, so to 
speak. I have many cards in my wallet, it isn't ideal, but its the best 
solution for my circumstances, pre., Bitcoin wallet prevalence and 
overall ecosystem maturity etc..

> You end up looking through a list and trying to remember what was for 
> what.

Depends on the CN and filenames (e.g., for the pkcs#12 files) combo that 
results from certificate generation. This does have something to do with 
the tools used to generate certificates.

I like to know which persona I am presenting to an online system.

> A large part of this was just bad UI in the browser - so there are 
> things that can be improved from a UI perspective that can make things 
> better, but also I think this direct management of certs is more of a 
> power user thing (to be asked to choose every time, giving each cert 
> special names to help remember).

If people are taught they become knowledgeable users. The trouble is 
programmers (at times) is that there is this misconception called the 
"dumb end-user" as opposed to what in reality is the "unengaged 
end-user" who is yet to make a full commitment to your app/service.

The pain points need to be understood by end-users. Application and its 
packaging should help the end-user understand its fundamental value 
proposition. This is the kind of skill that's diminishing due to the 
rise of a kind of "programming and programmers only" culture in today's 
computing realm.

> If it was automatic, (a site registers an identity card to your 
> browser, and says "this is for my site" and can fetch it without 
> having to ask you about it every time) then I guess that still serves 
> the same purpose I'm eluding to, which is that the user has one 
> profile, avatar, per-"internet identity" and things are kept simple 
> (with potential for advanced configuration by power users in the 
> settings).

The issue isn't one that's solved via an "automatic" anything. Users and 
Programmers need to understand Identity and Privacy. These issues have 
never been simple, in an realm of interaction.

> So, for example, I could have "Nick Jennings" as one browser profile, 
> with all my legitimate accounts, and a "Internet Troll 1291245167" 
> profile where I just flame people in youtube comments. :)

You would need at least two identity cards (certs.) for that. By that I 
mean, your "accounts" will ultimately be associated with different 
identities through which you express your varied personae, this is an 
integral part of being human and social (or anti social).

> The auto-issued certs from various sites can all be attached to their 
> respective browser profile key chains and I don't have to worry about 
> which is for which (but can go into settings to delete or make 
> advanced changes).

The Devil's in the details, with a penchant for using "convenience" and 
other niceties as a head-fake to hell. Who is auto-issuing these 
certificates, for instance?

>>     I think this is a detractor from WebID+TLS thus far. I've
>>     forgotten when certs I've used for what, and the unique naming
>>     (ie. Nick Jennings taskify, Nick jennings friendster, Nick
>>     Jennings aol) seems to be a hack more than anything.
>     Have you tested YouID [1] as a certificate generator? It enables
>     you generate a number of identify cards associated with a
>     combination of profile data providers (LinkedIn, Twitter, G+,
>     Facebook etc.) and identity credentials storage providers. Thus,
>     you can have an identify card comprised of identity claims from
>     Facebook that's stored on G+, Dropbox etc..
> I have not, will take a look at that.
>>     Very easy to create duplicate accounts with the wrong cert, or
>>     collect hundreds of certs and have a big mess.
>     Not, the Identity Card generator should make the it easy for users
>     to create Common Names (CN) that aid users during the TLS CCA.
>     I've added links to some examples [2][3] in the reference section
>     of this response.
>>     Although I have a feeling I'm overlooking some advanced uses of
>>     WebID outside of just "A guy using a website with a decentralized
>>     authentication and identity system", so I apologize in advance if
>>     I sound naive :)
>     The issue here is that once we separate concerns we can then
>     produce better narratives and working examples.
> Thanks for the links, will read up!
>     Links:
>     [1] http://youid.openlinksw.com
>     [2]
>     http://id.myopenlink.net/public_home/KingsleyUyiIdehen/Public/YouID/IDcard_Live_140430_212207/index.html
>     -- Identity Card (where Microsoft Live was the Profile Data
>     Provider and my personal ODS-Briefcase is the Identity Card
>     Storage Provider)
>     [3]
>     http://id.myopenlink.net/public_home/KingsleyUyiIdehen/Public/YouID/
>     -- collection of some of my Public Identity Cards generated by YouID
>     [4]
>     http://id.myopenlink.net/public_home/KingsleyUyiIdehen/Public/YouID/IDcard_Live_140430_212207/140430_212207_profile.ttl#identity
>     -- Identity Card WebID (HTTP URI that denotes me)
>     [5]
>     http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2FDAV%2Fhome%2FKingsleyUyiIdehen%2FPublic%2FYouID%2FIDcard_Live_140430_212207%2F140430_212207_profile.ttl
>     -- What you get when you dereference the WebID used by my Identity
>     Card .
>     Kingsley
>>>         The use-cases I can think of, would be:
>>>         1. You've lost your laptop and want to invalidate all your
>>>         certs.
>>         If you are using the WebID-TLS protocol, that amounts to
>>         removing all the relations that associate the public keys
>>         (that are pairs of the private keys in the lost laptop's key
>>         store) with WebIDs (HTTP URI that denotes an Agent and serves
>>         as the value of the SAN [SubjectAlternativeName] relation in
>>         your local X.509 cert. based identity card/doc) in your
>>         profile document/identity card. Basically, remove the
>>         relations in your public profile document and you laptop will
>>         not be a source of identity related compromises.
>>>         2. You had to recreate your certs and want to migrate from
>>>         one cert to another so you don't loose your user account.
>>         You can have you local credentials saved in a pkcs#12 file
>>         that's accessible from a USB, some cloud storage, your
>>         personal backup disk etc..
>>>         Both of these cases I don't think would be addressed with
>>>         'logout' anyway.
>>         They have nothing to do with login or logout.
>>>         But again, maybe I'm just missing something. My experience
>>>         with WebID is very limited so far.
>>         The WebID-TLS protocol (authenticating identity claims
>>         gleaned from "mirrored claims" across a combination of a
>>         local identity card [X.509 cert] and public identity
>>         card/profile document)  and a WebID (which addresses identity
>>         via denotation relations) are two things that are loosely
>>         coupled. Understanding starts by accepting these items are
>>         related (associated or connected), but not the same thing.
>>         Kingsley
>>>         -Nick
>>>         On Mon, May 5, 2014 at 2:32 PM, Kingsley Idehen
>>>         <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>>>             On 5/5/14 7:46 AM, Kingsley Idehen wrote:
>>>>             On 5/5/14 2:05 AM, Anders Rundgren wrote:
>>>>>             On 2014-05-04 23:36, Kingsley Idehen wrote:
>>>>>>             >On 5/3/14 11:13 PM, Anders Rundgren wrote:
>>>>>>>             >>On 2014-05-03 20:51, Tim Berners-Lee wrote:
>>>>>>>>>             >>> >On 2014-05 -03, at 10:45, Anders Rundgren<anders.rundgren.net@gmail.com>  <mailto:anders.rundgren.net@gmail.com>  wrote:
>>>>>>>>>>>             >>>> >>We can call it whatever we like, the user-experience offered by WebID as featured
>>>>>>>>>>>             >>>> >>onhttp://cimba.co  web doesn't meet reasonable user expectations [..]
>>>>>>>>>             >>> >So imagine the browser was going to be changed to make that better.
>>>>>>>>>             >>> >
>>>>>>>>>             >>> >People seem to widely agree that the client-side cert UI is bad on browsers
>>>>>>>>>             >>> >Can we at least do a thought experiment to be in a world where it is fixed -- what would that look like?
>>>>>>>>>             >>> >Maybe things like:-
>>>>>>>>>             >>> >
>>>>>>>>>             >>> >- Allowing the user to click a check box on "Always use this persona (client-side cert) with this web site (domain)"
>>>>>>>>>             >>> >- Allowing a preferences access to manage the persona/website allocation matrix
>>>>>>>>>             >>> >- Allow more screen space for selecting those certs
>>>>>>>>>             >>> >- Allow a user to label, color, and suppress certs in the list
>>>>>>>>>             >>> >- By default, not including expired certs in the list
>>>>>>>>>             >>> >- Tracking which persona is in use on this website (only when a user has more than one) in the URL bar
>>>>>>>>>             >>> >
>>>>>>>>>             >>> >and so on.  Maybe is someone sketched the UI then a browser code could be persuaded to do it.
>>>>>>>>>             >>> >It is necessary for existing client side cert sites anyway, and would maybe make thecimba.co  <http://cimba.co>  experience
>>>>>>>>>             >>> >quite reasonable.
>>>>>>>             >>Hi Tim,
>>>>>>>             >>
>>>>>>>             >>The hurdles aren't limited to the UI.  The following bug-report for Android
>>>>>>>             >>http://code.google.com/p/android/issues/detail?id=38393
>>>>>>>             >>shows that the server-initiated filtering feature that WebID-TLS presumes is set to "WorkingAsIntended" although it is not even implemented.
>>>>>>>             >>
>>>>>>>             >>In the several EU states X.509 client authentication is used quite extensively for on-line banking and e-government services.
>>>>>>>             >>These systems typically rely on proprietary browser plugins rather than using HTTPS Client Cert Auth.
>>>>>>>             >>Since plugins are to be "outlawed" by the browser vendors, they are now forced rewriting their systems to invoke local (native) applications to handle the certificate authentication.
>>>>>>>             >>I.e. they are effectively**giving up on the web**  for the authentication part!
>>>>>>>             >>
>>>>>>>             >>Due to this and a bunch of other issues related to HTTPS Client Cert Auth, I believe that we need a somewhat bigger "patch" to actually get anywhere.
>>>>>>>             >>
>>>>>>>             >>FWIW, I hereby submit a concept and sample implementation which I believe could be a suitable replacement both for the TLS-solution in WebID-TLS as well as for the proprietary systems used in the EU:
>>>>>>>             >>http://webpki.org/papers/PKI/webauth.pdf
>>>>>>>             >>
>>>>>>>             >>I encourage other developers in this space to do the same.
>>>>>>>             >>The W3C may then run a "beauty contest" and select a concept for standardization:-)
>>>>>>>             >>
>>>>>>>             >>Cheers
>>>>>>>             >>AndersR
>>>>>>>             >>
>>>>>>>             >>
>>>>>>             >Anders,
>>>>>>             >
>>>>>>             >Have you looked at how Safari works? The fact that it now uses a timeout to end TLS sessions, that are lingering or deemed "potentially inactive" ? Have you looked at this UX experience on iOS?
>>>>>>             >
>>>>>>             >Just asking as I've looked an the Android and your sketch, but don't sense evaluation of iOS.
>>>>>>             >
>>>>>>             >Apple is pretty good at UX. Sometimes they do enough just to be better than the competition, so I do tend to look at them first in regards to UX matters, ditto as the place to trigger changes that ultimately percolate to competitors etc..
>>>>>>             >
>>>>>             Kingsley,
>>>>>             I have not looked into Apple's dealing with TLS sessions or the certificate selection UI, because I don't have to.
>>>>>             The logic behind this somewhat quirky position is that I in similarity to Google, Microsoft, Paypal, ARM, RSA, and most of the EU banks have**rejected**  the idea of using HTTPS Client Certificate Authentication as the foundation for strong consumer authentication.  The motives probably vary, but I think my write-up contains the primary considerations.
>>>>             I looked up your write up prior to replying. Here are
>>>>             your fundamental issues:
>>>>             • TLS lacks a logout mechanism -- not so on iOS or when
>>>>             using Safari (which uses a timeout)
>>>             To verify my point, you can try our WebID verifier [1]
>>>             using Safari and/or iOS. Note, I've tried yours which
>>>             basically mandates G+ identity.
>>>             Initially, simply opt to "Cancel" when the TLS CCA UI is
>>>             presented. Under normal circumstances, you will not be
>>>             able to re-use this page without starting a new TLS
>>>             session, which is achieved by quitting and restarting
>>>             your browser. In the case of Safari, you simply wait a
>>>             little, and repeat en route to a TLS CCA challenge.
>>>             Not being able to configure the timeout (on Mac OS X or
>>>             iOS) is the only problem I have with the current
>>>             implementation by Apple.
>>>             Links:
>>>             [1] http://id.myopenlink.net/ods/webid_demo.html -- my
>>>             example which have varying behavior across browsers
>>>             (e.g., Chrome on Mac OS X or Android will require a
>>>             restart, but no so when using Safari on Mac OS X or iOS)
>>>             [2] https://mobilepki.org/webauth/ -- your example
>>>             -- 
>>>             Regards,
>>>             Kingsley Idehen	
>>>             Founder & CEO
>>>             OpenLink Software
>>>             Company Web:http://www.openlinksw.com
>>>             Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>>>             Twitter Profile:https://twitter.com/kidehen
>>>             Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
>>>             LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>         -- 
>>         Regards,
>>         Kingsley Idehen	
>>         Founder & CEO
>>         OpenLink Software
>>         Company Web:http://www.openlinksw.com
>>         Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>>         Twitter Profile:https://twitter.com/kidehen
>>         Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
>>         LinkedIn Profile:http://www.linkedin.com/in/kidehen
>     -- 
>     Regards,
>     Kingsley Idehen	
>     Founder & CEO
>     OpenLink Software
>     Company Web:http://www.openlinksw.com
>     Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>     Twitter Profile:https://twitter.com/kidehen
>     Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
>     LinkedIn Profile:http://www.linkedin.com/in/kidehen



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Tuesday, 6 May 2014 19:14:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC