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

Improvements for the ontology

From: Henry Story <henry.story@bblfish.net>
Date: Sun, 13 Mar 2011 09:25:20 +0100
Cc: foaf-protocols@lists.foaf-project.org, Peter Williams <home_pw@msn.com>
Message-Id: <964578E5-7AE5-44A4-B5CB-6F798AFB0FB6@bblfish.net>
To: WebID XG <public-xg-webid@w3.org>

On 13 Mar 2011, at 08:39, Peter Williams wrote on the foaf-protocols mailing list:

> I spent the day building a new foaf+ssl type demonstrator. Unlike last year, it now uses very simple .net4 code, and uses the azure Access Control service to generate wrap tokens authorizing an http client to talk to a trivial rest webservice - built from .NETs channel and service hosting classes. It’s actually just a 50 line modification of microsoft’s teaching code. Hosting it in the cloud is an exercise for tomorrow (once I swap hosting containers); whether client certs work in that load-balanced, firewalled cloud is quite another matter!

Very good.

> In two command windows, for now, an https client and https exist, with self-signed cert support both ways.. Opera can connect too, as a client authn client. The service host exposes an extension point, into which I inserted the client cert validation class (having checked it for webid, for being self-signed, for being trusted locally by windows cert stores). And, now, rather than use any RDF libraries natively, it simply calls uriburner  as a service – asking that service to test for the existence of named pubkeys in the webid’s document. It COULD authenticate to uriburner (assuming uriburner adopted WRAP scheme for www-authorization, too!)

Trusting uriburner is a good way to get going.

> "# DEFINE get:soft \"replace\"\r\nPREFIX cert: <http://www.w3.org/ns/auth/cert#> \r\nPREFIX rsa: <http://www.w3.org/ns/auth/rsa#> \r\nselect  ?webid \r\nFROM <http://foaf.me/serverpeter34#me>\r\nWHERE {\r\n[] cert:identity ?webid ;\r\nrsa:modulus ?m ;\r\nrsa:public_exponent ?e .\r\n?m cert:hex \"qYVMO2ngIsrCKmwRNNYq8lMMnFassZJAB+zLDZI6X+ohayakYjcaMZlnNYjb1+KWnrOsz4zJ74OL6LGUIpCw5Sy24jCCJoOnwl4SIUYf9J9gfjmj9XcXPe8gGe3Rnx3sijuzxtUdbp3WhBF5B2V0LywncpirggpAomOcD2duZn0=\"^^xsd:string .\r\n?e cert:decimal \"AQAB\"^^xsd:string\r\n}\r\n"

Our queries are now simpler than this. They could  be as simple as
PREFIX cert: <http://www.w3.org/ns/auth/cert#> .
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#> .
SELECT ?mod ?exp
   [] cert:identity ?webid;
      rsa:modulus ?mod;
      rsa:public_exponent ?exp . 

Modulus and exponent are Numeric literals, which means they can be encoded in any number of ways, and so of course in base64 too.

>  I can only urge (and I know Im going to be ignored) that we  change the ontology to allow the mod and exp to be base64 encoded, optionally. The query above is incorrect in that the values supposedly in formats cert:hex and cert:dec are actually in cert:base64 (not that this exists.) It’s just that 2 billion PC with 5 years of legacy already support RSA pubkeys in that encoding (I got the values from some xml-sig XML code, being produced from some weird organization called W3C); and its nuts to make folks jump through hoops to use otherwise. The base64 of mod/exp in the xmldsig key format is all properly specified and tested with a 100 vendors already on board; having properly sorted the translation of ASN.1 signed INTEGER to the base64 blob.

I am for adding a cert:base64 type in addition to cert:hex and cert:int . The cert:hex is useful as it is what browsers and openssl tools show, that makes it easy for users to look compare the html with what their browser shows them. Base64 would be for large service as it would allow them to reduce the size of publishing a key.

> If you want mass adoption, quickly, keep things to 100 line delta to stuff folks already have.

There are two other improvements I would like to suggest for the ontology.

1. A relation from the WebID to the key.  A public key is very close to being
   a literal: it has 2 OWL2 keys which completely define it. So since it is 
   a general policy in rdf to have relations to literals and not from them, this will 
   make other things possible. 

2. To move the rsa ontology to the cert ontology. When I started writing the ontology
  I just did not know how complex these things may be, so I separated them. But it turns out that rsa is very simple, and dsa would be so too.

queries would then look like this

PREFIX : <http://www.w3.org/ns/auth/cert#> .
SELECT ?mod ?exp
  ?webid :pubkey [  :rsaModulus ?mod;
                               :rsaExponent ?exp ] .

A simplification such as 1 has been on the books for a long time. I was just waiting for us to have a more formal setting such as this one to be able to go through this process.


> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect
Received on Sunday, 13 March 2011 08:25:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:23 UTC