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

On 5 May 2014 14:06, Anders Rundgren <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.


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