- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 11 Jan 2012 22:32:23 +0100
- To: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
- Cc: public-xg-webid@w3.org
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 ) 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 - if they are overlapping, is this a case of where they are? - if they are not overlapping, or this is not a case where they are overlapping + is this something the verifier should care about. how deeply should it care? what are the security risks it takes by not caring what non security risks does it take by not caring The other option is that SAN's are just a bit fuzzy, sometimes they name documents,sometimes they name agents. But then the protocol soon gets more complicated, and the question is: is it really worth it. > > 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? 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? I don't think that for security reasons it is directly relevant, though it will lead to confusions. 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. 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/
Received on Wednesday, 11 January 2012 21:32:56 UTC