W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

RE: a remark on the webid spec

From: Peter Williams <home_pw@msn.com>
Date: Wed, 14 Dec 2011 01:26:07 -0800
Message-ID: <SNT143-W323B88CE73BB7AFF386E3592A20@phx.gbl>
To: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

For what its worth, I found an old cookie session that still grants me write access to my post bearing a webid profile. I amended the type statement, and retested. I also amended the script object with the cert as element content to have type=application/x-x509-usercert;fingerprint=<20byesofHex> I changed the type of the resource to  foaf:PersonNot (which ideally should be a schema violation).  The test site https://auth.fcns.eu/auth/index.php?verbose=on doesnt care. ill assume that its now irrelevant (for webid validation purposes) what the foaf objecyt class is. Since the https://auth.fcns.eu/auth/index.php?verbose=on site spits out a base64 cert as part of the test, I recommend the script spits out the cert not as text (as shown today) but as the script element, with typing as above. Then we  can refer to it programatically. For the test, I migrated my IE keying material to Opera, and things work fine (but slightly differently). I had no reason to generate a second pubkey in opera (since IE and opera share the .p12 file format for import/export certs and private keying material). And, similarly Ive yet to need a second key in my profile (but...that only becuase I have not tested things with the 4 other devices and browsers I have). But, this issue does suggest that the spec contain a specific example of 2 pubkeys in the RDFa graph example.  FYI: for the test site, declares the global-sign rooted server cert fine (whereas IE objects, giving warnings (about fraud)). Second, opera has no way (obvious anyway) to use different client certs. Its missing what IE8 and IE9 added (the new session menu option). In 5m of research, I also could not figure how to send some javascript that will induce SSL connection tear downs and sessionID cache entry elimination (effecting what Henry calls a logout). From: henry.story@bblfish.net
Date: Wed, 14 Dec 2011 09:17:29 +0100
CC: mischa.tuffield@garlik.com
To: public-xg-webid@w3.org
Subject: Re: a remark on the webid spec

On 14 Dec 2011, at 03:43, Kingsley Idehen wrote:
    On 12/13/11 8:33 PM, Mischa Tuffield wrote:
        PREFIX : <http://www.w3.org/ns/auth/cert#>
        PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
           GRAPH ?g {
            ?g foaf:primaryTopic ?webid .
             ?webid a foaf:Person . 
              ?webid :key [
                 :modulus ?mod;
                 :exponent ?exp;
      ] .


    That introduces issues re. meaning of ?g. This varies across SPARQL
    services. Thus, the spec is better off staying with:


    PREFIX : <http://www.w3.org/ns/auth/cert#>

    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

    ASK {

       <https://bob.example/profile#me> :key [


          :exponent 65537;

       ] .


agree, but +1 on all the other points Mischa made.
We are also trying to keep the SPARQL as simple as possible. Adding primary topics, and foaf:Person (rather than say foaf:Group, or foaf:Agent)is going to create false negatives. Of course if it were well defined that GRAPH ?G would GET the latest Graph from the web, deal correctly with caches etc... then we would have a massive simplification of our spec :-) Well not quite, because we'd still have to explain it for the moment for people who don't have the latest sparql implementation, or else they would think our protocol requires it.



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


Social Web Architect

Received on Wednesday, 14 December 2011 09:29:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC