Re: A Quick Note on WebID history

On 8/13/21 1:24 AM, Henry Story wrote:
>> On 13. Aug 2021, at 01:02, bergi <> wrote:
>> Am 10.08.21 um 22:40 schrieb Henry Story:
>>> There was a vote on Hash URLs and 303 and I supported keeping things
>>> simple and efficient with hash urls, as Tim Berners-Lee would have
>>> preferred, and I lost, so we allowed both.
>> I remember that call very well. There was a majority, and there was your
>> position. You claimed that you, as a chair, can make the decision. A
>> discussion with you was impossible. The rest of the call was about you
>> acting like a dictator, how we can remove you as a chair or if we should
>> close the group. Maybe I'm a little bit picky, but that's not the way I
>> want to work in a CG.
> The issue had been voted at TPAC with Tim Berners-Lee present, and on
> his suggestion, by a large majority. We also voted on removing
> the abstraction from URIs down to URLs, which I had allowed
> to enter the discussion after being pressured by some folks on it,
> and which end up using up a lot of our time.
> I imagine someone will say: but look that is what DIDs ended up doing: 
> they generaliseto DID URIs instead of URLs! Yes, and 
> 1. that took another 10 years nearly to get done, and 
> 2. was a massive effort. 
> 3. it shows that us not doing it did not stop anyone else from doing it: 
>    DIDs and WebIDs can work very well together. 
> Our aim was to be able to start building decentralised social networks 
> as soon as possible.
> For hash URLs I tried to stick with Tim Berners-Lee’s vote which
> I think is the right efficient way to do things. But we
> went to a second formal vote on that and I and Tim lost the vote.
> So the issue was one of one vote versus another vote, and trying to
> keep the group on track to get this finished. Democracy is just not a
> simple process. Furthermore this is an engineering project, which 
> is evaluated not by the people in the room voting for it, but by 
> the number of users.
> There were then very many other reasons for why it was nearly impossible
> to get the project to a final standard. You can ask Manu Sporny about
> just how much trouble he had with some very vocal people (who you can
> be sure where always shooting out loud about democracy, revolution, will
> of the people etc…) who were trying to undermine his project at every step 
> of the way. 
> My thought was simple: let us build implementations, and we will prove
> the value of what we have done with deployments. Because in the end
> it is not who is in a mailing list that counts: it is how many millions
> of people are using a system, because they like the deployments they are
> using. And that is not at all an easy thing to do, as I think you can imagine.
> Finally, we ended up having the problem of keygen being removed from
> Chrome, which made things very complicated. I spent a few weeks
> trying to argue with the Chrome developers not to remove that,
> and had the support from many others. But there was no argument that
> was going to work there. They even refused to discuss it with 
> Tim Berners-Lee. That is the power reality on the ground. There is what
> a Google team says and does, and that is pretty much the end of
> the matter. 
> Anyway, WebID-TLS as a result is not going to work long term. I was
> hoping there could be improvements made to TLS that would overcome our
> problems, but they were not made, even though they were attempted 
> (But of course not in this forum). 
> The other WebID spec is just a definition that is used by Solid to allow 
> hyper-apps to work, and to which we can attach other methods of 
> identification. So the Solid projects is really the one using WebIDs
> on a daily basis now.
> Henry Story
> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬ 
> Twitter: @bblfish

Hi Henry,


  * WebID shouldn't have been inextricably bound to RDF-Turtle, it
    should have fully embraced the abstract nature of RDF leaving
    identifier and content-type preferences to implementors. Basically,
    the specs could have applied SHOULD to both JSON-LD and RDF-Turtle
    to avert issues that eventually stalled the entire effort. 
  * Keygen was a broken from the onset. That's why delegation should
    have been the focal point. The so-called UI/UX issues associated
    with TLS Client Certificate Authentication (CCA) has a lot to do
    with fluid understanding and interpretation re the nature of
    TLS-sessions, the role of User Agents, and the manner in which both
    items blend with identity, authentication, and access controls.

I've repeated the following mantra many a time, "..these items MUST be
loosely-coupled" for any kind of decentralized system to work:

1. Identity -- mapping of Identifiers to Referents to establish and
Identity Principal
2. Identification -- Identity Principal Credentials
3. Authentication -- Credentials Verification
4. Authorization -- Resource Access & Control
5. Storage -- using a variety of protocols for content serialization and

*History Update*

OpenLink has been using WebIDs since forever, and we continue to do so.

We actually have large customers that have been using WebID for years to
solve fundamental challenges associated with:

1. Verifiable Identity

2. Single-Sign On (SSO)

3. Leveraging Logic for Identity Resolution & Reconciliation

4. Attribute-based Access Controls

WebID-TLS (with or without delegation) has been part of Virtuoso's
Multi-Protocol Authentication Layer for years, and isn't going to change
anytime soon.

We've also taken the same concepts that underlie WebID to other levels
of abstraction by being looser about the notion of a resolvable
identifier i.e., beyond HTTP by supporting other schemes e.g., ldap:
etc.  Ditto Credentials Document Content-Types. Basically, we always
practice what we preach.

We simply refer to this superset as NetID.

NetIDs can be used to extend TLS-handshakes by way of triangulation that
starts from the Subject Alternative Name slot in an X.509 Cert -- just
like WebID i.e., function as an Authentication Protocol that leverages
the combined ubiquity of X.509 and TLS re PKIX.

Naturally, NetID also handles delegation.

*OpenLink Products Snapshot*

  * *YouID* -- used for generating X.509 Certificates laced with WebIDs
    or NetIDs that resolve to profile documents comprising Entity
    Relationship Graphs where no content-type is mandated, while
    leveraging the ubiquity of HTML and the emergence of
    i.e., we can just use terms from that vocabulary to triangulate
    credentials reconciliations leveraging public keys or other
    attributes e.g., fingerprints; It all "just works" and built into
    many of our product offerings used by our customers
  * *OpenLink Structured Data Sniffer* -- this includes a "Save As"
    feature that persist data to an Data Space that supports basic HTTP,
    HTTP+WebDAV, HTTP+LDP, HTTP+SPARQL, SPARQL Graph Protocol etc.. ;
    thus, it works with Solid Pods and all of the modules (Briefcase,
    ODS-Calendar, and ODS-{whatever-else} )that comprise our OpenLink
    Data Spaces Platform
  * *OpenLink Data Spaces* -- collaboration platform built atop Virtuoso
  * *Virtuoso* -- combined Data Access, Integration, and Management
    platform that with integral support for WebID and NetID (and related
    concepts) that provides the loosely-coupled foundation for our
    higher-level products


  * Virtuoso Authentication Layer (VAL) screencast
  * OpenLink Structured Data Sniffer "Save As" demo re Solid Pods
  * NetID and NetID-TLS Presentation
    (circa 2014)
  * NetID Wiki Entry <>
  * Tweets about NetID
    -- for some historical perspective


Kingsley Idehen       
Founder & CEO 
OpenLink Software   
Home Page:
Community Support:
Weblogs (Blogs):
Company Blog:
Virtuoso Blog:
Data Access Drivers Blog:

Personal Weblogs (Blogs):
Medium Blog:
Legacy Blogs:

Profile Pages:

Web Identities (WebID):

Received on Friday, 13 August 2021 14:12:03 UTC