Re: Recovery of compromised WebID

On 3/2/19 8:19 AM, Sebastian Hellmann wrote:
>
> Hi all,
>
> I know that everybody is enthusiastic about WebID, but I would like to
> know a bit more about what to take care of, when setting this up.
>
> 1.   https://xkcd.com/792/  applies, right? So If use another server
> for hosting WebID like http://holycrab13.github.io/webid.ttl  
> Microsoft could change the pub key in some requests (without changing
> the data) and then log into almost anything.
>

A WebID is an identifier. That's it.

A WebID-Profile Document is the document to which a WebID resolves. It
is the place where credentials (Identity Claims) reside.

The WebID-TLS and WebID-TLS+Delegation protocols are Authentication
Protocols that verify a WebID by reconciling Identity Claims in an X.509
with specific claims in a WebID-Profile document, courtesy of the
objects of a specific relation i.e., cert:key .

Logging into a Data Space doesn't mean you have access to anything.  A
Data Space will use WebACLs to control access (in various modes) to
resources.

In this game,  the following are loosely-coupled ensuring no single
point of failure or vulnerability:

Identity (WebID), Identification (WebID-Profile Doc), Authentication
(WebID-TLS or WebID-TLS+Delegation protocols), Authorization (WebACLs),
and Storage (Data Spaces hosting a collection of Resources/Documents). 


> Same for the WebId on my own server: http://kurzum.net/webid.ttl   If
> this get's compromised it is like a meteor hit, since you would have
> only one identity for everything.
>
> 2. This weakness is also mentioned in the security section of OpenID
> https://en.wikipedia.org/wiki/OpenID#Privacy_and_trust_issues and
> therefore all OpenID Connect weaknesses and security risks apply for
> WebID OpenConnect as well.
>

No!

OpenID isn't driven by the same mechanisms as WebID-TLS or
WebID-TLS+Delegation.


> 3. anything else? I guess the TLS part is quite standard then.
>

TLS is a standard extended by WebID lookups re. WebID-TLS and
WebID-TLS+Delegation.


> Although I would need to check whether third parties listening to the
> traffic can trace your public key. (inversefunctional?) So they would
> know that you made a connection, but not the content of the connection.
>

Your Public Key doesn't mean much in a loosely-coupled system that's
driven by logic expressed in RDF statement collections.


Kingsley

> -- 
> All the best,
> Sebastian Hellmann
>
> Director of Knowledge Integration and Linked Data Technologies (KILT)
> Competence Center
> at the Institute for Applied Informatics (InfAI) at Leipzig University
> Executive Director of the DBpedia Association
> Projects: http://dbpedia.org, http://nlp2rdf.org,
> http://linguistics.okfn.org, https://www.w3.org/community/ld4lt
> <http://www.w3.org/community/ld4lt>
> Homepage: http://aksw.org/SebastianHellmann
> Research Group: http://aksw.org


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