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

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? 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. Very
easy to create duplicate accounts with the wrong cert, or collect hundreds
of certs and have a big mess.

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