Re: A Quick Note on WebID history

I have been following this discussion with interest.

I cannot comment on the history of WebID, but I can comment on real
difficulties encountered with building on the current WebID draft
specification document.

None of this is new, but I will reiterate it: *requiring* Turtle is a real
problem.

In particular, we are building a specification for Solid that makes use of
OpenID Connect: Solid-OIDC <https://solid.github.io/solid-oidc/>. This is
the successor to the old WebID-OIDC
<https://github.com/solid/webid-oidc-spec> authentication mechanism. One of
the challenges is that OpenID connect, like OAuth2, makes heavy use of JSON
while Solid makes heavy use of RDF. The natural intersection is JSON-LD,
but in order to define an application identifier
<https://solid.github.io/solid-oidc/#clientids> that sits in this
in-between world, we are a bit stuck. We currently call those identifiers
"Client WebIDs", but because a WebID MUST have a Turtle serialization, we
have some undesirable options:

1. Hand-waving: one option is to just ignore the WebID spec on the point
about the Turtle requirement (this is the current approach, which is
clearly problematic)
2. Remove the dependency on WebID altogether: this seems a bit drastic,
given how much Solid uses WebID as a conceptual entity, but that is
basically our only option given the state of the WebID draft

It is also somewhat concerning to build a specification that depends on a
draft that hasn't seen much activity recently. There is another dependency
on a draft specification (i.e. DPoP
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop>) but that is
under active development and making its way through IETF via the OAuth2
working group; the DPoP draft does not worry me. The dependency on WebID,
however, does not fall into that category.

There is obviously a lot of history with WebID and how it came about.
History is important, but I am interested in the present and future. Where
is this draft heading? How confident can I be when building on this draft?
Clearly one alternative is to just start using DIDs. Another is to be
entirely agnostic about these identifiers and view WebID as just one of
many possible identifiers.

From my perspective, if the WebID draft simply required "an RDF
serialization" rather than a particular serialization, this would allay my
principal concern.

Thanks, Aaron



On Fri, 13 Aug 2021 at 10:20, Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> https://www.google.com/search?q=define+identity
> https://en.wikipedia.org/wiki/Identity_(social_science)
>
> no sparql?
>
> On Sat, 14 Aug 2021 at 00:12, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>
>> On 8/13/21 1:24 AM, Henry Story wrote:
>>
>> On 13. Aug 2021, at 01:02, bergi <bergi@axolotlfarm.org> <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
>>
>>