Re: Slash URIs and WebID Experiment

On 1/11/12 4:32 PM, Henry Story wrote:
> On 11 Jan 2012, at 21:36, 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.
> I like the picture.
>
> The other way to say it is, the meaning of the URI is given by dereferencing it, in either case.
> (The Web is a mapping from URIs to meanings http://blogs.oracle.com/bblfish/entry/possible_worlds_and_the_web )
Hmm.

You have a Object that Represents something. Said thing (an Entity) has 
a Name (an Identifier).

A URI is an Identifier. So we are just dealing with a new kind of Object 
ID. One that is network aware and protocol agnostic.

An Object is endowed with Identity distinct from its values 
(Representation).

You de-reference an Object Identifier to access the Object's 
Representation. They are not the same thing. You know that anyway. At 
least, I've since evidence of your possessing said knowledge. I remember 
you: 1 + 1 = 2 (or something like that) example in a thread with Peter.

>
> If the URI returned is not 303 then by http it names an information resource (i.e. a foaf:Document )
> otherwise it can name anything else.
>
> If it is in the SAN then it is a foaf:Agent.
>
> So we then have these questions:
>   - are  a foaf:Document and a foaf:Agent non overlapping classes

They are disjoint, you know that.

>      - if they are overlapping, is this a case of where they are?

See comment above.

>      - if they are not overlapping, or this is not a case where they are overlapping
>          + is this something the verifier should care about.

Warmer ...

>            how deeply should it care?

Warmer ...
>            what are the security risks it takes by not caring
>            what non security risks does it take by not caring

Irrelevant at this stage, we are trying to make sense of:

1. WebID spec
2. Cool URIs
3. Linked Data.

>
> The other option is that SAN's are just a bit fuzzy, sometimes they name documents,sometimes they name agents.

Warmer....
> But then the protocol soon gets more complicated, and the question is: is it really worth it.

And we are home!! And home means this: WebID is a system that has either 
High or Low Linked Data fidelity. It just cannot be both. That's not 
possible.

"Check!"

>
>> 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.
> IF you were being very precise yes. Otherwise you could continue with the proviso that there was an error in the
> HTTP headers, or somewhere else.
>
> What are the well known practical issues with confusing objects with documents?

Come on now!

> Well things like the following come to mind: If you do that you can  no longer name the document without also naming the thing. If you want to say the document was created on a certain day you also end up saying the thing was created on that day, etc... And soon you have to introduce ambiguity along the whole chain.
>
> But is that relevant to the authenticator?

Come on now!

>
> I don't think that for security reasons it is directly relevant, though it will lead to confusions.

Oh yes it would!

So once again, we arrive at the effects of the http-Range-14 imbroglio. 
The Linked Data luxury tax.

>   So I would say that if one were to go down this line, one would not say MUST not, but rather MAY not, or something weaker. Unless you can develop a scenario where things are problematic.

Ambiguity == Insecurity !!!


Kingsley
>
> Henry
>
>
>> 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)
>>
>>
>>
>> ----- 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
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

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