- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 06 May 2014 15:13:48 -0400
- To: public-webid@w3.org
- Message-ID: <5369346C.4080205@openlinksw.com>
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? 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 <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 > > > > > -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 6 May 2014 19:14:10 UTC