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

On 5/5/14 8:06 AM, Anders Rundgren wrote:
> Kingsley,
>
> I'm sorry but the fact remains: WebID doesn't come with a strong and SSO-friendly
> authentication method that works satisfactory, and therefore the rest no matter how
> ingenious it may be, is only of moderate interest.

I would say: WebID-TLS is an authentication protocol for WebID that's 
susceptible to browser TLS CCA idiosyncrasies in regards to 
Single-Sign-On UI/UX. This problem can be solved once browser vendors 
are provided with appropriate incentives to fix their implementations. 
One big incentive is the increasing rise of privacy issues that arise 
from identity compromises.

>
> Which BTW is pretty much the same problem as the WebPayment folks are grappling with.
> Or to be more correct: Since they couldn't fix the problem, they ignored it :-)

Sorta.
>
> Based on the e-mail responses it is obvious that these issues are out of scope for the W3C.

Not necessarily.


Kingsley
>
> Anders
>
>
>
> On 2014-05-05 13:15, Kingsley Idehen wrote:
>> 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