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

Timothy,

HTTPS Client Certificate Authentication as featured in current browser does the following:
- Binds a client-supplied certificate through a secure method to session on the server
- Creates a bidirectionally authenticated and encrypted channel between the client machine and the server

That is, HTTPS Client Certificate Authentication doesn't know anything about the context since it is doing its job on the transport level

I don't suggest changing that except that my proposal performs the same process on top of the transport layer which also is the de-facto standard for almost all other web-based user-authentication systems in actual use today.  None of the major web-sites are using transport-level web-authentication in spite of being "standard".

It is possible that there could be advantages intertwining stuff but I don't see how.

Anders

On 2014-05-04 06:29, Tim Holborn wrote:
>
> 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 <mailto:timbl@w3.org>> 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
>>> 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 <http://cimba.co> experience
>> quite reasonable.
>>
>> timbl
>>
>>
>>
>>
>>
>