- From: Tim Holborn <timothy.holborn@gmail.com>
- Date: Sun, 4 May 2014 14:29:06 +1000
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Andrei Sambra <andrei.sambra@gmail.com>, public-webid <public-webid@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
- Message-Id: <9BBF0CAA-0FC5-4A1C-8F81-7FC75E8330AD@gmail.com>
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 > > > > >
Received on Sunday, 4 May 2014 04:30:39 UTC