- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 13 Aug 2021 10:11:43 -0400
- To: public-webid@w3.org, "public-rww@w3.org" <public-rww@w3.org>
- Message-ID: <c9515520-0bbb-377d-bc1a-cebcf8d357a8@openlinksw.com>
On 8/13/21 1:24 AM, Henry Story wrote: > >> On 13. Aug 2021, at 01:02, bergi <bergi@axolotlfarm.org> 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 > > https://co-operating.systems > WhatsApp, Signal, Tel: +33 6 38 32 69 84 > Twitter: @bblfish > > Hi Henry, *Retrospective* * 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 persistence *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 Schema.org 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 *Related* * Virtuoso Authentication Layer (VAL) screencast <https://www.youtube.com/watch?v=Ea2iHPnP40k> * OpenLink Structured Data Sniffer "Save As" demo re Solid Pods <https://www.youtube.com/watch?v=ifq19zkB210> * NetID and NetID-TLS Presentation <https://www.slideshare.net/kidehen/how-virtuoso-enables-attributed-based-access-controls> (circa 2014) * NetID Wiki Entry <https://www.w3.org/community/rww/wiki/NetID> * Tweets about NetID <https://twitter.com/search?q=HashEmoji%20%2540kidehen%20%2523NetIDTLS&src=typed_query&f=live> -- for some historical perspective -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Home Page: http://www.openlinksw.com Community Support: https://community.openlinksw.com Weblogs (Blogs): Company Blog: https://medium.com/openlink-software-blog Virtuoso Blog: https://medium.com/virtuoso-blog Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers Personal Weblogs (Blogs): Medium Blog: https://medium.com/@kidehen Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/ http://kidehen.blogspot.com Profile Pages: Pinterest: https://www.pinterest.com/kidehen/ Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen Twitter: https://twitter.com/kidehen Google+: https://plus.google.com/+KingsleyIdehen/about LinkedIn: http://www.linkedin.com/in/kidehen Web Identities (WebID): Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 13 August 2021 14:12:02 UTC