W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 05 May 2014 07:15:21 -0400
Message-ID: <536772C9.7040408@openlinksw.com>
To: public-webid@w3.org
On 5/5/14 5: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!

No.

We have separation of concerns here that really need to be accepted and 
acknowledged.

A WebID is an HTTP URI that denotes an Agent. That's it.

The WebID-TLS protocol, which is what's vulnerable to the TLS CCA 
(Client Certificate Authentication) UI and UX idiosyncrasies you 
mention, is distinct. Conflating these items will not help resolution of 
these matters.

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

The banking world cannot be the yardstick for the kind of harmonization 
you seek. How about signed and/or encrypted emails as a starting point?

Kingsley
>
> Best
> Anders
>
>
>> Best regards,
>> JP
>>
>>> Due to this and a bunch of other issues related to HTTPS Client Cert Auth, I believe that we need a somewhat bigger "patch" to actually get anywhere.
>>>
>>> FWIW, I hereby submit a concept and sample implementation which I believe could be a suitable replacement both for the TLS-solution in WebID-TLS as well as for the proprietary systems used in the EU:
>>> http://webpki.org/papers/PKI/webauth.pdf
>>>
>>> I encourage other developers in this space to do the same.
>>> The W3C may then run a "beauty contest" and select a concept for standardization :-)
>>>
>>> Cheers
>>> AndersR
>>>
>>>
>>>> timbl
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






Received on Monday, 5 May 2014 11:15:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC