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

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.

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

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

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

Received on Monday, 5 May 2014 12:07:20 UTC