Re: Slash URIs and WebID Experiment

On 1/11/12 3:36 PM, Jürgen Jakobitsch wrote:
> hi,
>
> this image [1] actually illustrates the situation quite well...
> the verifi-cat-ion is the moment of truth for the webID.
> in case the webID is a non-# uri it is either a name or an address, it can't be both by definition.
>
> in case the server did not respond with 303 seeOther, it seems to be a common agreement,
> that the uri is an information resource [2], in other words it's an address.
>
> =>  now accepting said uri, from which we now know that it's an address, means accepting
>     login from a document about a foaf:Agent which is in sharp contrast to the spec :
>
>     "WebID : A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions."
>
>     "WebID Profile or Profile Page
>      A structured document asserting the relationship between the =>  Subject (identified by his WebID)<= "
>
>    and therefor WRONG.
>
> the tricky part is to understand that although you have all triples for authentication at hand, you must not
> even start to look for modulus match and stuff, because you would authenticate the document.
>
> wkr j
>
> p.s.: see again the 3 solutions from kingsley below. it should be noted that there is also the 4th solution :
>        having a #-uris as the only valid webids, but that's not cool.
>
>
> [1] http://www.flickr.com/photos/girliemac/6513125065/in/set-72157628409467125/
> [2] to be verified with this webID http://www.turnguard.com/mylifeasdocument here http://validator.linkeddata.org/vapour
>      (see the conclusion)

Awesome!

Henry: I hold my position, Jurgen will get you there :-)

"Check!"


Kingsley
>
>
>
> ----- Original Message -----
> From: "Henry Story"<henry.story@bblfish.net>
> To: "Jürgen Jakobitsch"<j.jakobitsch@semantic-web.at>
> Cc: "Peter Williams"<home_pw@msn.com>, public-xg-webid@w3.org
> Sent: Wednesday, January 11, 2012 3:57:35 PM
> Subject: Re: Slash URIs and WebID Experiment
>
>
> On 11 Jan 2012, at 15:56, Henry Story wrote:
>
>> On 11 Jan 2012, at 15:47, Jürgen Jakobitsch wrote:
>>
>>> hi,
>>>
>>> conclusion :
>>>
>>> if none of the solutions kingsley presented [see below] is applied
>>> a verifier currently MUST reject non-# uris that don't respond with 303 if said verifier wants to be spec-compliant.
>> Why MUST? That is very strong.
> Or put another way: Can you imagine a misidentification taking place if it is not a MUST?
>
> Henry
>
>> Henry
>>
>>
>>> wkr j
>>>
>>>
>>> ----- Original Message -----
>>> From: "Peter Williams"<home_pw@msn.com>
>>> To: public-xg-webid@w3.org
>>> Sent: Wednesday, January 11, 2012 12:58:25 AM
>>> Subject: RE: Slash URIs and WebID Experiment
>>>
>>>
>>> NOw answer the hard question I asked a long time ago (before folks with actual intelligence analyzed the issue).
>>>
>>> one cannot assume the self-signed or not-signed cert sender does it right - and that is the nature of the project (recall). (If it wasnt Id have had a windows SSL verifier up a long time ago.)
>>>
>>> So, what MUST the verifier do.
>>>
>>> As it stands, some reject, some dont. Henry told: its sort of ok-ish, jsut recognize folks may think you are a document. Having been a queen, I dont mind being anything at this point. If I can be a document and get access, I dont care. Im not here to be anything but a (stupid) user, or hacker, gaming the system.
>>>
>>> Now, there could be a rule that says: Verifiers shall insist http/s URIs have a particular syntax. The webid URI is rejected, if its not.
>>>
>>> FCNS code does not so reject; but others do for this syntactic reason alone, or for reasons derived from it consequences on then resolving the name. For a while, I believed FCNS was the abiter a conformance testing site. But, its not the case, it accepts at least 2 profile/certs that others reject.
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Date: Tue, 10 Jan 2012 18:33:32 -0500
>>>> From: kidehen@openlinksw.com
>>>> To: public-xg-webid@w3.org
>>>> Subject: Re: Slash URIs and WebID Experiment
>>>>
>>>> On 1/10/12 6:27 PM, Jürgen Jakobitsch wrote:
>>>>> hi kingsley,
>>>>>
>>>>> i'm glad i could help, thanks for making it as clear as it can get.
>>>>>
>>>>> i have updated my profile and i feel much better as "any kind of resource" than as "information resource" :)
>>>>>
>>>>> for people who want to follow your steps below, i did backup my old slash-profile @ http://www.turnguard.com/mylifeasdocument.
>>>>>
>>>>> one note on my old profile and uriburner : you might have an old version cached.
>>>>>
>>>>>
>>>>> so your point is simply,
>>>>>
>>>>> if we want webid to stick (hard) to linked data principles, we must have a possibility to put the difference between
>>>>> name and address into the certificate. why? because linked data principles are not limited to 2-in-1-hash-uris
>>>>> and a webid like http://www.turnguard.com/mylifeasdocument must be rejected because it can't be both (name and address)
>>>>> without breaking said principles.
>>>>>
>>>>> right?
>>>> Amen!
>>>>
>>>> Kingsley
>>>>> wkr j
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Kingsley Idehen"<kidehen@openlinksw.com>
>>>>> To: public-xg-webid@w3.org
>>>>> Sent: Tuesday, January 10, 2012 7:35:53 PM
>>>>> Subject: Re: Slash URIs and WebID Experiment
>>>>>
>>>>> On 1/10/12 11:58 AM, Jürgen Jakobitsch wrote:
>>>>>> hi,
>>>>>>
>>>>>> i'm not sure if this webid [1] meets your test criteria. anyway here are the results.
>>>>>>
>>>>>> 1. http://id.myopenlink.net/ods/webid_demo.html
>>>>>> accepted
>>>>>> 2. https://webid.turnguard.com:8443/WebIDTestServer/
>>>>>> accepted
>>>>>> 3. https://resourceme.bergnet.org
>>>>>> failed
>>>>>> 3.1. http://www.w3.org/2005/Incubator/webid/earl/RelyingParty#profileGet =>  failed
>>>>>> and consequently all tests southwards failed.
>>>>>> 4. http://webid.fcns.eu/
>>>>>> passed (when using https://auth.fcns.eu/auth/index.php?authreqissuer=http://webid.fcns.eu/index.php)
>>>>>> passed (when using https://foafssl.org/srv/idp?authreqissuer=http://webid.fcns.eu/index.php)
>>>>>> 5. https://foafssl.org/test/WebId
>>>>>> passed
>>>>>>
>>>>>> cleared cache, cookies and active logins (in firefox) and retried
>>>>>>
>>>>>> 6. https://resourceme.bergnet.org
>>>>>> failed
>>>>>> 6.1. http://www.w3.org/2005/Incubator/webid/earl/RelyingParty#profileAllKeysWellFormed =>  failed
>>>>>> and consequently all tests southwards failed.
>>>>>>
>>>>>> wkr j
>>>>>>
>>>>>> [1] http://www.turnguard.com/turnguard
>>>>> Jurgen,
>>>>>
>>>>> For WebID, great i.e., you put it in SAN and it worked.
>>>>>
>>>>> For Linked Data no [1][2]!
>>>>>
>>>>> What you have proven is this: WebID doesn't need the full fidelity of
>>>>> Linked Data. If it did, then your use of a slash URI that returns a 200
>>>>> OK means Name/Address ambiguity, a Linked Data no-no. Ultimately, you
>>>>> end up with problems associated with object equivalence fidelity (be it
>>>>> by names or values). Using more conventional Linked Data parlance, via
>>>>> this URI, you are confusing yourself with a document.
>>>>>
>>>>> Conclusion: your slash URI doesn't exhibit the same Linked Data
>>>>> characteristics demonstrated by mine [3][4]. That's not a bad thing
>>>>> since my fundamental point is that:
>>>>>
>>>>> 1. my slash based HTTP URI is generated by my Linked Data platform.
>>>>>
>>>>> 2. use of my platform or others, shouldn't be the base requirement for
>>>>> WebID if it seeks full Linked Data fidelity as a mandatory requirement
>>>>> for HTTP URIs in a Certs. SAN.
>>>>>
>>>>> You are proving my point !
>>>>>
>>>>> SPARQL Query Proof:
>>>>>
>>>>> ## using old WebID query pattern since your graph is using old WebID
>>>>> related relations still
>>>>>
>>>>> PREFIX :<http://www.w3.org/ns/auth/cert#>
>>>>> PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
>>>>> SELECT * WHERE {
>>>>> ?identity cert:identity<http://www.turnguard.com/turnguard>  .
>>>>> ?identity rsa:modulus ?m ;
>>>>> rsa:public_exponent ?e . }
>>>>>
>>>>> SPARQL Protocol URL Links:
>>>>>
>>>>> 1. http://uriburner.com/c/IBZM4R -- sparql query results
>>>>> 2. http://uriburner.com/c/IBJUQG -- sparql query editor.
>>>>>
>>>>>
>>>>> Links:
>>>>>
>>>>> 1. http://uriburner.com/c/IBJUQP -- URI debugger output (note: re.
>>>>> Linked Data that should be a 200 OK)
>>>>>
>>>>> 2. http://uriburner.com/c/IBJUQS -- note how it shows you only have
>>>>> descriptor (information) resource address
>>>>>
>>>>> 3. http://uriburner.com/c/IBZM45 -- notice the 303 (how HTTP message
>>>>> exchange is used to facilitate indirection via redirection)
>>>>>
>>>>> 4. http://uriburner.com/c/IBYXSV -- note how the report concludes that I
>>>>> have a generic Name distinct from a descriptor (information) resource
>>>>> address.
>>>>>
>>>>> Thank you once again, for helping me showcase an inevitable problem for
>>>>> those who want to start their WebID journey in commodity/consumer mode
>>>>> leveraging "cut, paste, and place at an address" patterns i.e., the most
>>>>> common Web technology exploitation pattern.
>>>>>
>>>>> Solutions:
>>>>>
>>>>> 1. Lower Linked Data fidelity requirements in WebID -- it becomes an
>>>>> option, so 200 OK is fine if the SPARQL ASK still works
>>>>> 2. Allow multiple HTTP URIs in SAN where functions are clear re. Name
>>>>> and Address roles
>>>>> 3. Consider another (optional) location for the descriptor (information)
>>>>> resource address e.g. sIA.
>>>>>
>>>>> We need at least one of the above to address the problem introduced by
>>>>> HTTP URIs. One that many just don't understand until bitten.
>>>>>
>>>>>
>>>>> Kingsley
>>>>>> ----- Original Message -----
>>>>>> From: "Kingsley Idehen"<kidehen@openlinksw.com>
>>>>>> To: "WebID XG"<public-xg-webid@w3.org>
>>>>>> Sent: Tuesday, January 10, 2012 3:30:32 PM
>>>>>> Subject: Slash URIs and WebID Experiment
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> The URI:
>>>>>> http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen , is
>>>>>> now fine for testing purposes.
>>>>>>
>>>>>> I've verified successfully using:
>>>>>>
>>>>>> 1. http://id.myopenlink.net/ods/webid_demo.html
>>>>>> 2. https://webid.turnguard.com:8443/WebIDTestServer/
>>>>>> 3. https://resourceme.bergnet.org
>>>>>> 4. http://webid.fcns.eu/
>>>>>> 5. https://foafssl.org/test/WebId .
>>>>>>
>>>>>>
>>>>>> Now, it would be nice to see someone else produce a Cert. with a slash
>>>>>> based HTTP URI in its SAN that passes through all of the above, or at
>>>>>> least a majority of them.
>>>>>>
>>>>>> At this juncture, for experimentation you have the following HTTP URI
>>>>>> based Names:
>>>>>>
>>>>>> 1. http://kingsley.idehen.net/dataspace/person/kidehen#this
>>>>>> 2. http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen .
>>>>>>
>>>>>>
>>>>
>>>> --
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen
>>>> Founder&  CEO
>>>> OpenLink Software
>>>> Company Web: http://www.openlinksw.com
>>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>>> Twitter/Identi.ca handle: @kidehen
>>>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> | Jürgen Jakobitsch,
>>> | Software Developer
>>> | Semantic Web Company GmbH
>>> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
>>> | A - 1070 Wien, Austria
>>> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>>>
>>> COMPANY INFORMATION
>>> | http://www.semantic-web.at/
>>>
>>> PERSONAL INFORMATION
>>> | web   : http://www.turnguard.com
>>> | foaf  : http://www.turnguard.com/turnguard
>>> | skype : jakobitsch-punkt
>>>
>> Social Web Architect
>> http://bblfish.net/
>>
> Social Web Architect
> http://bblfish.net/
>
>
>
> --
> | Jürgen Jakobitsch,
> | Software Developer
> | Semantic Web Company GmbH
> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
> | A - 1070 Wien, Austria
> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>
> COMPANY INFORMATION
> | http://www.semantic-web.at/
>
> PERSONAL INFORMATION
> | web   : http://www.turnguard.com
> | foaf  : http://www.turnguard.com/turnguard
> | skype : jakobitsch-punkt
>
>


-- 

Regards,

Kingsley Idehen 
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen