Re: UI for client cert selection (Was: Releasing RWW.IO)

I’ve spent some time with anders last night (i’m in oz); showing Cimba, running on other services - i.e. TLS AUTH to RWW.io (not TLD/app host - i.e. Cimba[1] / Kima[2] (whatever, perhaps best described as rdflib[3]?), and am looking forward to understanding more of his considerations and possible alternatives (or additions) he seeks to introduce to the group/s for consideration.  IMHO, the tangential differences relating to decentralisation change paradigms in ways that are difficult to understand without looking at the stack, rather than a specified segment.  If the mission was simply to authenticate to a traditional web2 methodology - inc. client(browser session) / server (.TLD with Relational DB) then some considerations would become more difficult to understand.

tangentially; 

Some questions I’ve had for a while (re: data layer, not auth. or privacy crypto specifically) is why the WebID-TLS seeks to ID a person (foaf:person / foaf:agent) - rather than a machine / local account (i.e.: WebID:thing< rel:foaf/me#>).  A possible alternative use-case could be that TLS defaults to issuing a client certificate that says something like - Timh’s desktop; which in-turn means if a friend wants to use their RWW Services temporarily on my machine - they can authenticate, link to that cert (perhaps i need to authorise that action, and give it a profile..).

I understand the end-result is to provide identity services to users (therein, FOAF records); however, IMHO, the WebID Enabled TLS Cert appears to identify the machine account / browser - not the person sitting in front of the machine at the time of use. re: POC work (proof of concept) i don’t think it matters, but as things progress having WoT (web of trust) ID’s for each entity (things / legal entities) would seemingly enhance accessibility…? 

I imagine, 

- I have a desktop machine, with one profile. 
- I install an RWW Cloud account on that machine, as administrator.
- In the SubjectAltName link - I embed ubiquitous.rww.io/profile/card#me and perhaps ubiquitous.rww.io/things/workstation#home or ubiquitous.rww.io/profile/card#homemachine or whatever alternative.

An alternative could be to define a WebID ontology...


WoT (or IoT) Related records might have server-side info; like 
- what Subnet the device lives on (if the machine is moved somewhere else - it might not have access anymore, without additional authentication..)
- a description of the capability / permissions of/with the device (can send anything you want from that HDD to your cloud account, or alternatively - it’s not allowed - not thinking rules, just the ability to create them.)
- a description of my relationship to the device (inc. preferences - similar to above.)


With regard to persona - the client-side cert for a person / persona (of a person) might be located on the cloud somewhere..  whether this is a public or an encrypted record is tangential, the fact would be that in accessing that record user-intervention is required and in some instances this may require multiple devices to interact in a specified way.   

I imagine the mechanism around this ‘agreement’ to be segmented from the user-device (i.e.: workstation).  (understanding, that some may choose to build their own environments internally: at home, on a NAS or ubuntu phone, etc.); and that agreements between entities can be transcribed to rdf, forging ACL’s around data-sharing, etc..

I can also imagine a UI creating authorisation procedures, in a recipe format: which could then be defined differently for different machines used by a particular individual or persona (work, family, accounting, etc.) of a persons life, in relation to machines they’re using.

WebID Ontology?
When this gets down to the WebID-TLS Spec[4] - it currently it defines FOAF specifically, which kinda excludes the concept of ‘thing’.  A possible alternative I’ve considered, is to create a WebID ontology, using w3id[5] perhaps…


RE: AUTH SPECIFICALLY
When describing concepts relating to AUTH recently,  The use-case of traditional lock-keys (doors, vehicles, padlocks, etc.) seemed useful.  One of the characteristics of a keyring is not simply that someone needs to get them from you; but also, the possession of the key does not = knowledge of which key fits which lock.  That information is generally information stored in someones head.   if you loose your keyring at a pub, even if you put your phone number on it - someone still needs to ‘link’ the keyring, to the specified location of the lock, in-order to use it.  

I imagine that the future of AUTH will feature some of these concepts / considerations - including the use of multiple keys, rather than a specified master-key (understanding we also live in a world where if all else fails we can seek some help from a locksmith) let alone a master-key that’s provided on traditional web portal terms…  (i’m not entirely sure how far the privacy issue goes, but the email is long enough already. )

timh.

[1] https://github.com/social-webarch/cimba or live at http://cimba.co/
[2] https://github.com/rww-apps/kima/  or live at http://rww-apps.github.io/kima/
[3] https://github.com/linkeddata/rdflib.js
[4] http://www.w3.org/2005/Incubator/webid/spec/tls/
[5] https://w3id.org/

On 4 May 2014, at 4:51 am, Tim Berners-Lee <timbl@w3.org> wrote:

> 
> On 2014-05 -03, at 10:45, Anders Rundgren <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.
> 
> timbl
> 
> 
> 
> 
>