Re: Verifying WebID fails

Kingsley,

I am speaking about the WebID-TLS spec, more specifically Authentication
sequence and Verifying the WebID:
https://www.w3.org/2005/Incubator/webid/spec/tls/#the-
webid-authentication-protocol

None of the sections (see below) on WebID verification address the failure
to verify the public key, and I think a robust protocol should. Am I
missing something?

4.1. step 6.2

The graph returned in the previous step is then queried as explained in
Verifying the WebIDs. If the query is answered positively, then that WebID
is verified. If the query fails and the graph was not up to date, then the
Verifier may start again at point 6.1.2 by making a request to an up to
date graph.

4.2.5.2 Verifying the WebID Claim

To check a WebID Claim one has to find if the graph returned by the profile
relates the WebID to the Certificate Public Key with the cert:key relation.
In other words, one has to check if those statements are present in the
graph.

4.2.5.2.1 Verifying the WebID Claim with SPARQL

An ASK query simply returns true or false. If it returns true, then the key
was found in the graph with the proper relation and the claim is verified.

On Wed, 28 Jun 2017 at 16.16, Kingsley Idehen <kidehen@openlinksw.com>
wrote:

> On 6/27/17 8:44 PM, Martynas Jusevičius wrote:
>
> Kingsley,
>
> I am implementint WebID authentication in our software, and key mismatch
> is a real scenario.
>
> Can you show me where in the spec it is addressed?
>
>
> Martynas,
>
> Your comments are confusing.
>
> Are you speaking of the WebID+TLS protocol which is basically a
> TLS-handshake extension that uses a WebID lookup (using value of SAN
> attribute in an X.509 Cert)  to locate a Public Key in a WebID-Profile
> document? If not, then we are not speaking about the same thing, and as a
> result not communicating effectively.
>
> Terms:
>
> 1. WebID -- HTTP URI that identifies an Agent and adheres to Linked Data
> principles
> 2. WebID-Profile Document -- a collection of RDF statements in an RDF
> document that describe an Agent identified by a WebID
> 3. WebID+TLS -- TLS handshake extension that matches Public Keys in an
> X.509 cert and a WebID-Profile document by way of WebID de-reference
> 4. WebID+TLS+Delegation -- adds an additional lookup route to #3 via
> acl:delegates relation
>
>
> Kingsley
>
>
> On Wed, 28 Jun 2017 at 02.04, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>
>> On 6/27/17 6:33 PM, Martynas Jusevičius wrote:
>> > Hi,
>> >
>> > I think there is another case where failure scenario is not defined in
>> > protocol: verifying the WebID.
>> >
>> > What happens if the certificate key does not match the WebID key? None
>> > of the verification steps or sections seem to consider that. I suggest
>> > again that a 400 Bad Request should be returned.
>> >
>> > I think it is important for the protocol to handle failures if we want
>> > robust implementations.
>> >
>> > Is this group active enough to fix such issues?
>> >
>> >
>> > Martynas
>>
>>
>> Hi Martynas,
>>
>> What do you mean by Certificate Key? Are you referring to the Public Key
>> component of an X.509 Certificate?
>>
>> Bearing in mind that WebID+TLS isn't new, are there are implementations
>> out in the wild, wouldn't it be better if you started off by testing
>> authentication of your WebID against existing implementations?
>>
>> You might also find the YouID browser extension we built interesting
>> since its sole purpose is simplification of WebID+TLS and/or
>> WebID+TLS+Delegation protocol usage (e.g., negating the UX headache
>> introduced by browsers when toggling WebIDs over and existing TLS
>> session) [1].
>>
>> You can try:
>>
>> [1] http://linkeddata.uriburner.com/sparql -- click on "login" button
>>
>> [2] http://osdb.openlinksw.com -- click on the "login" button
>>
>> [3] http://id.myopenlink.net/ods/webid_demo.html -- most basic WebID+TLS
>> authentication tool we have
>>
>> Links:
>>
>> [1]
>> https://medium.com/openlink-software-blog/simple-youid-
>> browser-extension-usage-exercise-57fa3ff6c6b7
>> -- Simple YouID Browser Extension Usage Exercise.
>>
>> --
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software   (Home Page: http://www.openlinksw.com)
>>
>> Weblogs (Blogs):
>> Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
>> Blogspot Blog: http://kidehen.blogspot.com
>> Medium Blog: https://medium.com/@kidehen
>>
>> 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/dataspace/person/kidehen#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)
>
> Weblogs (Blogs):
> Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
> Blogspot Blog: http://kidehen.blogspot.com
> Medium Blog: https://medium.com/@kidehen
>
> 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/dataspace/person/kidehen#this
>         : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>
>