- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 05 May 2014 16:52:14 +0200
- To: Tim Holborn <timothy.holborn@gmail.com>
- CC: Jiří Procházka <ojirio@gmail.com>, public-webid <public-webid@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
On 2014-05-05 16:08, Tim Holborn wrote: > i’ve dropped timbl off the list - considering what his inbox probably looks like without our help specifically… Good idea :-) > > you’ve noted ‘replacement’, i’m sure you mean ‘alternative’? > > meaning the specification could (in theory) support multiple solutions that perform the same or similar function to webid-tls? (using the x509v3 cert specifically) Yes, this is possible to some extent although it requires additional code. Anders > > On 6 May 2014, at 12:05 am, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > >> On 2014-05-05 15:22, Jiří Procházka wrote: >> >> Jiří, >> >> Before going into details, I think it fair to say that very few people on >> this list have probably ever seen the consumer-bank-PKIs I'm referring to. >> Naturally that makes most of my argumentation appear as "Greek". >> >> There's very little I can about that, except maybe answering very >> specific questions that gradually paints the "big picture". >> >> >>> On 05/05/2014 11:19 AM, Anders Rundgren wrote: >>>> On 2014-05-05 10:33, Jiří Procházka wrote: >>>>> On 05/04/2014 05:13 AM, Anders Rundgren wrote: >>>> <snip> >>>> >>>> Hi Jiří, >>>> >>>>> Hi everyone. Anders, I might be wrong, but I think the banking/e-gov use >>>>> case is quite different from the major WebID use case - WebID as a >>>>> single sign-on (SSO) solution. >>>>> >>>>> I think the banks supply their own proprietary browser plugins because >>>>> the problem they are solving is safely using the certificate established >>>>> just for their use (one website), >>>> >>>> 100% agreed. The question here is therefore why they *rejected* the built-in >>>> HTTPS Client Certificate Authentication support which fully addresses this >>>> [principally] simple use-case? >>>> >>>>> while WebID needs a widely available >>>>> client software with certificate selection UI which the users trust (so >>>>> it is not supplied by websites), because they need to be able to trust >>>>> it with their certificate which they use potentially on 100s of >>>>> websites. >>>> >>>> 100% agreed. >>>> >>>>> Also doing something like the banks do (one-website >>>>> certificates), would be impractical for WebID even if it was done by a >>>>> standardized browser plugin, as there would be new UI/communication >>>>> headache with binding the certificate generated for a particular >>>>> website, with the WebID profile hosting solution of choice. >>>> >>>> I'm not suggesting changing a *single line* of the WebID concept, I'm merely claiming >>>> that the currently only fully specified authentication alternative is at an X-road. >>>> >>>> That you can use "any" authentication scheme won't make WebID an SSO solution >>>> which was I think at least Henry had in mind and IMO remains a very noble goal! >>>> >>>> Since the banks and WebID as far as I can tell, can use *exactly the same solution*, >>>> I believe that there could be a way reaching "critical mass" for a new scheme, >>>> something which I'm pretty sure WebID (or the banks) alone won't ever achieve. >>>> >>>> The EU banks have invested more than $1Bn in X.509 technology for client authentication >>>> and will therefore very unlikely switch to U2F (in its current incarnation). >>> >>> Right, in short: now it is best for the banks to have their own >>> implementations which they vouch for to their clients, but we want to be >>> working towards a solution with secure implemenatations across all >>> platforms and browsers, supporting both the use case of the banks and >>> the SSO WebID scenario. >> >> Me too :-) >> >> >>> What I don't understand is how your proposal fits into this and what it >>> actually is, as what I have seen in the PDF are basically just 2 JSON >>> structures... >> >> The JSON structures represent a "Challenge" which the authenticating server >> packages in an HTML form (TBD at this stage), and a signed "Response" produced >> by the browser client sent back to the server. This is BTW exactly what U2F do >> albeit using an entirely different privacy model. >> >> >>> what are you proposing to be done? >> >> It is really up to the WebID group finding a suitable replacement to the TLS >> solution specified in WebID-TLS. >> >> >>> How it relates to WebID-TLS? >> >> It accomplishes the same thing as the HTTPS Client Certificate Authentication >> solution used in WebID-TLS which is [technically] strong authentication of a >> client-certificate which in the case of WebID would hold an HTTP URI. >> >> >> What exactly are the non-UX issues of HTTPS CCA? >> >> They are listed on the first page of the presentation. >> >> Best >> Anders >> >>> >>> Best, >>> JP >
Received on Monday, 5 May 2014 14:52:56 UTC