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

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:05:44 UTC