- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 13 Aug 2021 20:24:26 -0400
- To: Aaron Coburn <acoburn@apache.org>
- Cc: "public-rww@w3.org" <public-rww@w3.org>
- Message-ID: <aa43cc08-0f1d-fd09-a673-00c91d50e207@openlinksw.com>
On 8/13/21 11:08 AM, Aaron Coburn wrote:
> 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
Hi Aaron,
Re "From my perspective, if the WebID draft simply required "an RDF
serialization" rather than a particular serialization, this would allay
my principal concern."
Amen!
That's the fundamental issue, and a totally unnecessary own-goal.
RDF is fundamentally abstract in nature, it isn't bound to any
serialization format or content-type. Unfortunately, it has a checkered
history of being held captive by the aforementioned with regards to
various efforts that end up with "W3C" labeling (most ironically!).
In the beginning it was RDF/XML -- ramifications still reverberating to
this very minute.
Then it was RDF-Turtle -- totally wrecked WebID (as you are experiencing
on the Solid front)
And today, it is JSON-LD as per DiD etc..
At OpenLink we handle all of the above and more.
I've never understood why RDF remains distracted and utterly compromised
(adoption wise) by serialization formats and content type specificity.
Kingsley
>
>
>
> On Fri, 13 Aug 2021 at 10:20, Timothy Holborn
> <timothy.holborn@gmail.com <mailto:timothy.holborn@gmail.com>> wrote:
>
> https://www.google.com/search?q=define+identity
> <https://www.google.com/search?q=define+identity>
> https://en.wikipedia.org/wiki/Identity_(social_science)
> <https://en.wikipedia.org/wiki/Identity_(social_science)>
>
> no sparql?
>
> On Sat, 14 Aug 2021 at 00:12, Kingsley Idehen
> <kidehen@openlinksw.com <mailto: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> <mailto: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 <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 <http://www.openlinksw.com>
> Community Support: https://community.openlinksw.com <https://community.openlinksw.com>
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog <https://medium.com/openlink-software-blog>
> Virtuoso Blog: https://medium.com/virtuoso-blog <https://medium.com/virtuoso-blog>
> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers <https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers>
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen <https://medium.com/@kidehen>
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/ <http://www.openlinksw.com/blog/~kidehen/>
> http://kidehen.blogspot.com <http://kidehen.blogspot.com>
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/ <https://www.pinterest.com/kidehen/>
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen <https://www.quora.com/profile/Kingsley-Uyi-Idehen>
> Twitter: https://twitter.com/kidehen <https://twitter.com/kidehen>
> Google+: https://plus.google.com/+KingsleyIdehen/about <https://plus.google.com/+KingsleyIdehen/about>
> LinkedIn: http://www.linkedin.com/in/kidehen <http://www.linkedin.com/in/kidehen>
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i <http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i>
> : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this <http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this>
>
--
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 Saturday, 14 August 2021 00:24:43 UTC