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

Can you post the links for your proposal so i (/ we)  can go through it and understand it...

> intertwining?

whats that mean… 

cheers.

On 4 May 2014, at 3:02 pm, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

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