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

i’ve dropped timbl off the list - considering what his inbox probably looks like without our help specifically…  

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)

On 6 May 2014, at 12:05 am, Anders Rundgren <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