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

On Thu, May 8, 2014 at 2:24 PM, Kingsley Idehen <kidehen@openlinksw.com>wrote:

>  On 5/8/14 7:28 AM, Nick Jennings wrote:
>
>
> On Tue, May 6, 2014 at 9:13 PM, Kingsley Idehen <kidehen@openlinksw.com>wrote:
>
>>  On 5/6/14 6:30 AM, Nick Jennings wrote:
>>
>>  On Tue, May 6, 2014 at 12:49 AM, Kingsley Idehen <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>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.
>>
>
>  So either you, or the host, or a 3rd party provide a cert, you allow it
> and link it to the website.
>
>
> I want to be in a position to pick the identity card presented to the
> service. I don't want it hardwired, I am human, I change my mind a lot,
> amongst other quality :-)
>
>
>
You want to change your mind about which cert you use to authenticate
yourself as? Doesn't this


>    It lives in your single profile and you don't have to be shown a list
> of potentially hundreds of certs whenever you've been logged out of the
> site, asking you to pick one.
>
>
> I don't want a single profile. In reality, nobody has a single profile.
>

I didn't mean you can only have one single profile, I meant a single
profile can contain multiple certs.  Personally I don't see the point in
using one cert for facebook, another for youtube, if you are presenting
yourself as the same person or identity... and if I was presenting myself
as different identities I prefer to have a separate browser profile for
this (ala chrome users or firefox profiles).




>
>
>
>
>>
>>
>>  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.
>>
>
>
>  I think you're assuming that I'm coming from a programmers perspective.
> Not at all, my feedback is 100% based on my experience as an end user.
>
>
> End-users need options. Basically, the same kind of freedom the have
> outside computing. Some might want the illusion of a single profile others
> might not. My point is that well designed systems (e.g., AWWW) are
> implicitly dexterous.
>

Options with reasonable defaults. I am not against options.




>
>    I find it extremely unpleasant to have to remember which cert to give
> to which website.
>
>
> Yes, but that's you as opposed to everyone else.
>

Oh, I see :)



> A good system has to let you do your things and others do theirs. On Mac
> OS X, via Keychain, you can pegg a Certificate to a Site, if you so choose.
> Thus, whenever there's a TLS CCA challenge that certificate is presented
> without any dialog presenting a list of certificate.
>

That's what I was suggesting, I would prefer the relationship to be
automatic: when I go to a site for the first time and do the authentication
dance, my browser then stores and remembers this for me. Next time I'm
asked, my browser says "it's this one"... maybe there's an option to click
"no let me select from a list of certs" but in most cases, the quicker we
get through that process, with the least amount of clicking, the better.




>
>   I had this trouble since the first time I used WebID, and I don't think
> naming your cert file uniquely is a satisfactory solution to the problem.
>
>
> Using a CN attribute value to appropriately denote the certificate
> subject, literally is an option for those systems that will list that in
> their cert. selection dialogs.
>
> Your troubles have nothing to do with WebID-TLS and everything to do with
> the browser you are using. For instance, does your Browser interact with a
> keystore such that you can bind a Cert. to a http: or mailto: scheme URI?
>

I thought we were talking about improvements to make (including to
browsers) that would improve the user experience?



>
>
>   A user is not going to know (as I did not) what a good naming scheme is
> which will allow them to make the right choice and not accidentally create
> a new user account the next time they visit the site and are asked to
> select a cert.
>
>
> A certificate generator should factor in the certificate listing issue by
> making default CN attribute values that provide hints to users when
> presented with certificate selection list.
>
>
>
Good idea. I think we're actually much more on the same page than we think,
we just went about approaching it from different places. :)

-Nick



>
>
>
>>
>>   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.
>>
>
>  I don't see how educating users and programmers about identity and
> privacy is in conflict with the suggestions I made.
>
>
> Automatic isn't a nirvana. In most cases, it a shortcut to hell. A little
> education reduces fallibility inherent in defaults and premature
> optimization.
>
>    In fact I think it improves the case by providing visual feedback
> about what you are doing within your browser while still removing the
> hassle of having to choose from a giant list every time you visit a site.
>
>
> This is a problem with the browser you are using. Thus, by understanding
> its root you can then start a path towards pain alleviation which might end
> up with you changing your browser and/or adapting certain CN attribute
> conventions etc..
>
>
>   You should be able to tell your computer *do this* and have it remember
> that next time.
>
>
> Yes, but computers are a composite of operating systems, application
> programs etc., developed by lots of different parties. It isn't a monolith.
>
>
>  I agree with you that you should be able to provide different websites
> with different cert "cards", but I think that your browser should from then
> on remember which cert you either generated or were issued, and link it to
> that website.
>
>
> Yes, it should have that kind of capability. Thus, if your preferred
> browser lacks this capability you have to make the vendor aware of the
> problems its inflicting on your workflow etc..
>
>   I don't care if your browser profile is simply a keychain with a
> billion certs attached to it for all the sites you use, I don't want to
> have to manage them on a daily basis.
>
>
> I am not implying you should. Quite the contrary.
>
>   I would like the ability to do so in an advanced configuration menu
> (much like we can with cookies nowadays) but do not think it's user
> friendly (speaking from myself, a user) to have to proactively name a cert
> title in such a way that you can remember which one you used for facebook,
> or which you used for youtube, and then have some expiration time at which
> point you are asked to select which cert to use, from your existing chain.
> I have often chosen the "wrong" cert and made a new user, that is annoying
> (as a user) to have happen.
>
>
> Keychain lets you do what you seek. Browsers that use Keychain inherit
> this capability. The problem is that those browsers (e.g. Mozilla) that use
> their own keystores ultimately end up missing out on advances that exist as
> the OS level, as this use-case demonstrates.
>
> Kingsley
>
>
>  -Nick
>
>
>
>>   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?
>>
>> Kingsley
>>
>>
>>
>>
>>>
>>>    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
>>>> > 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> <anders.rundgren.net@gmail.com> wrote:
>>>>>
>>>>>  >>>> >> We can call it whatever we like, the user-experience offered by WebID as featured>>>> >> on http://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 the 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
>>>>> 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
>>>> 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
>>> 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
>> 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
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>