- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 05 May 2014 18:49:36 -0400
- To: public-webid@w3.org
- Message-ID: <53681580.7000100@openlinksw.com>
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 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.. > 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. 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 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 Monday, 5 May 2014 22:50:00 UTC