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

On 2014-05-05 14:22, Melvin Carvalho wrote:
>
>
>
> On 5 May 2014 14:06, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> 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.
>
>     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, you're confusing WebID and WebID+TLS, a common misconception.
>
> 1. A WebID is a URI (Ed. preferably hash URI) that denotes a person and when dereferenced gives back RDF, with mandatory turtle serialization
>
> Facebook use this in their graph and never touch the TLS part.  So there are examples of webid's deployed independent of TLS. 
>
> Why do we separate the two?  Because Identification is different from auth.  Techies care about auth.
>
> Non users care about identification, because it's the version of you on the web, which is the discourse of humanity.  You can see your friends, link to them, let them link to you.  You can see pictures of them, their status etc. 

Melvin,

The WebID and WebPayments groups are free ignoring user-authentication if it is only of interest to techies.
I'm indeed a die-hard techie but I also see a value of WebID (your definition of it).

If these interests can't be combined I have a feeling that WebID won't go as far as it could and should.

The vision of the decentralized Facebook is up the creek.

Anders

>  
>
>
>     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:40:37 UTC