What problem is a WebID Specification trying to address?

Hi All,

*Problem*

In the current landscape, our online identities are predominantly 
managed by third-party service providers. This control significantly 
limits our ability to access and utilize a wide array of online 
services, tying us to the specific authentication services provided by 
these third parties.

*Solution*

A framework that loosely couples identity, identification, 
authentication, authorization, and storage, thereby  removing 
third-party control over:

 1. Access to Services.
 2. How Services are Used.
 3. The Privacy of Our Data.

This can be achieved through the adoption of open standards enabling:

 1. The utilization of HTTP URIs to uniquely name People, Organizations,
    and Software.
 2. The creation of Profile Documents (for example, "Link In Bio" pages)
    that utilize HTTP URIs to describe entities through an entity
    relationship graph comprising relationship type semantics
    understandable by both humans and machines.
 3. Development authentication protocols that are loosely bound to identity

In the past, this community coalesced around the WebID-TLS protocol, 
with regards to item 3. Unfortunately, that endeavor has been stifled by 
two significant hurdles:

 1. Browser issues with TLS implementation.
 2. Non-existent baseline specification that resonates with Web Developers.

In the meantime, at OpenLink Software, we've looked to address the WebID 
Authentication protocol issue via IndieAuth <https://indieauth.net/> and 
RelMeAuth <https://indieauth.com/faq> Protocol implementations, since 
both support using HTML to build Profile Documents. These documents 
comprise an entity relationship graph expressed in Plain Old Semantic 
HTML (POSH) scoped to a subject unambiguously named by an HTTP URI.


*Practical Demonstration*

Consider my "Link In Bio" Profile Document, hosted on a Virtuoso-powered 
WebDAV Filesystem: 
https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html.

Courtesy of either the IndieAuth or RelMeAuth protocols, I consistently 
log into my target application (i.e., the OpenLink Personal Assistant 
[OPAL]) using the identifier: 
https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid. 
The same applies to any Virtuoso SPARQL endpoint.

Watch YouTube hosted screencast at: 
https://youtu.be/kawIzW1PHj0?si=u16pnaHLUOxkCzot

*Related*

  * About IndieAuth <https://sl.bing.net/e2ppWNNdoWW> -- via CoPilot
  * About RelMeAuth <https://sl.bing.net/dGDyKMmaldA> -- via CoPilot


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

Received on Friday, 9 February 2024 20:43:51 UTC