- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 11 Jan 2012 15:56:27 +0100
- To: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
- Cc: Peter Williams <home_pw@msn.com>, public-xg-webid@w3.org
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. 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/
Received on Wednesday, 11 January 2012 14:57:00 UTC