change of namespace as agreed in weekly meeting, and clearing up of ontology and test example.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/earl/RelyingParty.n3 Sun Sep 25 00:28:44 2011 +0200
@@ -0,0 +1,265 @@
+@prefix cert: <http://www.w3.org/ns/auth/cert#> .
+@prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+@prefix dct: <http://purl.org/dc/terms/> .
+@prefix earl: <http://www.w3.org/ns/earl#> .
+@prefix log: <http://www.w3.org/2000/10/swap/log#> .
+@prefix owl: <http://www.w3.org/2002/07/owl#> .
+@prefix wit: <http://www.w3.org/2005/Incubator/webid/earl/RelyingParty#> .
+
+
+_:certificate a cert:Certificate;
+ rdfs:comment "The certificate containing the claims and for which the private key was verified";
+ cert:base64der "MIIMIICMjCCAZugAwIBAgIGATJ8skgWMA0GCSqGSIb3DQEBCwUAMA0xCz...A";
+ cert:principal_key _:publicKey;
+ log:semantics [ log:includes _:certWebIDClaim_1 ] .
+
+# Native SAN string. Could contain more than one URI!
+_:certificateSAN
+ owl:sameAs "http://example.tld/card#me".
+
+_:verificationTimestamp
+ owl:sameAs "2011-09-22T22:10:00.000Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>.
+
+_:publicKey a rsa:RSAPublicKey;
+ rsa:modulus "a...b"^^cert:hex;
+ rsa:public_exponent "65537"^^cert:int.
+
+_:certWebIDClaim_1 a wit:WebIDClaim;
+ log:n3String """
+ @prefix cert: <http://www.w3.org/ns/auth/cert#> .
+ @prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+
+ [] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;
+ cert:identity <http://example.tld/card#me>;
+ rsa:modulus "..."^^cert:hex
+ """ .
+
+_:certWebIDClaim_2 a wit:WebIDClaim;
+ log:n3String """
+ @prefix cert: <http://www.w3.org/ns/auth/cert#> .
+ @prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+
+ [] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;
+ cert:identity <http://example.tld/card#me>;
+ rsa:modulus "..."^^cert:hex;
+ rsa:public_exponent "..."^^cert:int .
+ """ .
+
+# NOTE the above two ways of writing things can be heavy since the modulus can be very large,
+# and gets repeated for each graph. Since we are only interested in the public key we could
+# extract that with the following two relations
+
+_:certWebIDClaim_1 a wit:WebIDClaim ;
+ wit:claimedKey _:publicKey;
+ wit:claimedIdentity "http://example.tld/card#me"^^xsd:anyURI . #avoid the reference, since otherwise an inferencing engine could substitute this URL with another one, if they were found to owl:sameAs each other
+
+# but the above will only save space if there is a lot more than one WebID per certificate, and in the case of the profiles, each public key should be different, so there is less saving there. So perhaps a case of pre-mature optimization.
+
+
+# Reduced profile graph: the full information relevant to these tests about a particular key
+# we can imagine having two keys in the profile
+
+<http://example.tld/card#me> log:semantics [ log:includes _:profilePubkey1Graph, _:profilePubkey2Graph ] .
+
+_:profilePubkey1Graph
+ log:n3String """
+ @prefix cert: <http://www.w3.org/ns/auth/cert#> .
+ @prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+
+ [] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;
+ cert:identity <mailto:joe@smith.example>;
+ rsa:modulus "..."^^cert:hex;
+ rsa:public_exponent "..."^^cert:int .
+ """ .
+
+_:profilePubkey2Graph
+ owl:sameAs "[] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;....."^^log:parsedAsN3.
+
+_:modulus
+ owl:sameAs "a...b"^^cert:hex.
+
+_:publicExponent
+ owl:sameAs "65537"^^cert:int.
+
+
+# Did the client provide a X509 certificate?
+[] a earl:Assertion;
+ earl:test wit:certificateProvided;
+# earl:subject -> there can't be an earl subject here, because then the test would be verified in its own desciption. In any case there is no way at this point of referring to the subject.
+ earl:result [ a earl:TestResult;
+ dct:description "Certificate provided";
+ earl:outcome earl:passed;
+ earl:pointer _:certificate;
+ ] .
+
+# Does the client certificate contain a subject alternative name?
+# note: it should perhaps contain 2, just to help make clear that we are not only requiring https
+# the other SAN should be an e-mail address.
+[] a earl:Assertion;
+ earl:subject _:certificate;
+ earl:test wit:certificateProvidedSAN;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer "http://example.tld/card#me"^^xsd:anyUri, "mailto:joe@smith.example"^^xsd:anyUri ] .
+
+# Is the current timestamp between begin and end date of the certificate?
+[] a earl:Assertion;
+ earl:subject _:certificate ;
+ earl:test wit:certificateDateOk ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:verificationTimestamp ] .
+
+# Could the public key be recognised (is the algorithm known, is it well formed, etc...)?
+# The other question is: is this a public key we know how to parse in rdf. So we don't yet have ontologies
+# for DSA. We may later, but some implementations may not at that point know how to.
+[] a earl:Assertion;
+ earl:subject _:certificate;
+ earl:test wit:certificatePubkeyRecognised;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicKey ] .
+
+# Does the certificate contain no unnecessary critical extensions?
+[] a earl:Assertion;
+ earl:subject _:certificate;
+ earl:test wit:certificateCriticalExtensionsOk;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ ] . # the earl pointer here could be used to point to the name of the critical extension used.
+
+# Does the certificate fulfill all requirements for a WebID certificate?
+[] a earl:Assertion;
+ earl:subject _:certificate ;
+ earl:test wit:certificateOk ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ ] . #the pointer here would point to some part of the certificate that was wrong, or perhaps it should point to the testresult that invalidated it?
+
+# Is the WebID Profile accessible and downloadable?
+[] a earl:Assertion;
+ earl:subject <http://example.tld/card#me>; #note: we should put a demo profile up at ./card with an xml version ./card.rdf and an n3 version ./card.n3 for example, so here we are speaking about a particular version of the card.
+ earl:test wit:profileGet;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer <http://example.tld/card.n3> ] . #is this a good pointer? Well if we received the n3 representation, then yes, this is pointing more precisely.
+
+# Does the profile contain only well formed keys for that WebID?
+[] a earl:Assertion;
+ earl:subject <http://example.tld/card.n3>; # I think we maintain the name of the document, or we speak of a representation. Ie, now we are speaking about a particular string, with a particular semantics. Putting the whole document in the report may be a bit heavy, so it's not required. Perhaps there should be a link to it. todiscuss
+ earl:test wit:profileWellFormed;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:profilePubkey1Graph ].
+
+# Does the public key contain only one modulus?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph; #agree it makes sense here to have the minigraph as subject
+ earl:test wit:pubkeyRSAModulusFunctional;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:modulus ]. #if there were two modulii would this be two pointers?
+
+# Is the RSA modulus a literal number?
+# btw, failure here is not necessarily a deadly problem - as long as we allow the old notation.
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAModulusLiteral;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:modulus ] .
+
+# Is the RSA modulus well formed?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAModulus;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:modulus ] .
+
+# Does the public key contain only one public exponent?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAExponentFunctional;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicExponent ] . # if there is more than one, then two pointers would make sense.
+
+# Is the RSA public exponent a literal number?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAExponentLiteral;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicExponent ] .
+
+# Is the RSA public exponent well formed?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAExponent;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicExponent ] .
+
+# Is the public key well formed?
+# The reduced profile contains only the public key.
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:profileWellFormedPubkey;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:profilePubkey1Graph ] .
+
+# Does the profile contain only well formed keys for that WebID?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:profileAllKeysWellFormed;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:profilePubkey1Graph ] .
+
+# Does the profile fulfill all requirements for WebID authentication?
+[] a earl:Assertion;
+ earl:subject <http://example.tld/card.n3>;
+ earl:test wit:profileOk;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer <http://example.tld/card#me> ]. #in particular with regard to this webid.
+
+# Could the particular WebID claim be verified?
+# TODO: How should we use the earl:pointer in this test case?
+[] a earl:Assertion;
+ earl:subject _:certWebIDClaim_1;
+ earl:test wit:webidClaim ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed ] . # does a pointer here make sense ?
+
+# Could at least one WebID claim be verified?
+# TODO: How should we use the earl:pointer in this test case?
+# TODO: Can we use multiple earl:subject properties?
+# bblfish: I don't think so. In the definition of subject is says "the subject". But could be an oversight.
+[] a earl:Assertion;
+ earl:subject _:certificate ;
+ earl:test wit:webidAuthentication ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:certWebIDClaim_1 ] . #points to the WebIDClaims that were verfied
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/earl/RelyingPartyExample.n3 Sun Sep 25 00:28:44 2011 +0200
@@ -0,0 +1,265 @@
+@prefix cert: <http://www.w3.org/ns/auth/cert#> .
+@prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+@prefix dct: <http://purl.org/dc/terms/> .
+@prefix earl: <http://www.w3.org/ns/earl#> .
+@prefix log: <http://www.w3.org/2000/10/swap/log#> .
+@prefix owl: <http://www.w3.org/2002/07/owl#> .
+@prefix wit: <http://www.w3.org/2005/Incubator/webid/earl/RelyingParty#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+_:certificate a cert:Certificate;
+ rdfs:comment "The certificate containing the claims and for which the private key was verified";
+ cert:base64der "MIIMIICMjCCAZugAwIBAgIGATJ8skgWMA0GCSqGSIb3DQEBCwUAMA0xCz...A";
+ cert:principal_key _:publicKey;
+ log:semantics [ log:includes _:certWebIDClaim_1 ] .
+
+# Native SAN string. Could contain more than one URI!
+_:certificateSAN
+ owl:sameAs "http://example.tld/card#me".
+
+_:verificationTimestamp
+ owl:sameAs "2011-09-22T22:10:00.000Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>.
+
+_:publicKey a rsa:RSAPublicKey;
+ rsa:modulus "a...b"^^cert:hex;
+ rsa:public_exponent "65537"^^cert:int.
+
+_:certWebIDClaim_1 a wit:WebIDClaim;
+ log:n3String """
+ @prefix cert: <http://www.w3.org/ns/auth/cert#> .
+ @prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+
+ [] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;
+ cert:identity <http://example.tld/card#me>;
+ rsa:modulus "..."^^cert:hex
+ """ .
+
+_:certWebIDClaim_2 a wit:WebIDClaim;
+ log:n3String """
+ @prefix cert: <http://www.w3.org/ns/auth/cert#> .
+ @prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+
+ [] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;
+ cert:identity <http://example.tld/card#me>;
+ rsa:modulus "..."^^cert:hex;
+ rsa:public_exponent "..."^^cert:int .
+ """ .
+
+# NOTE the above two ways of writing things can be heavy since the modulus can be very large,
+# and gets repeated for each graph. Since we are only interested in the public key we could
+# extract that with the following two relations
+
+_:certWebIDClaim_1 a wit:WebIDClaim ;
+ wit:claimedKey _:publicKey;
+ wit:claimedIdentity "http://example.tld/card#me"^^xsd:anyURI . #avoid the reference, since otherwise an inferencing engine could substitute this URL with another one, if they were found to owl:sameAs each other
+
+# but the above will only save space if there is a lot more than one WebID per certificate, and in the case of the profiles, each public key should be different, so there is less saving there. So perhaps a case of pre-mature optimization.
+
+
+# Reduced profile graph: the full information relevant to these tests about a particular key
+# we can imagine having two keys in the profile
+
+<http://example.tld/card#me> log:semantics [ log:includes _:profilePubkey1Graph, _:profilePubkey2Graph ] .
+
+_:profilePubkey1Graph
+ log:n3String """
+ @prefix cert: <http://www.w3.org/ns/auth/cert#> .
+ @prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
+
+ [] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;
+ cert:identity <mailto:joe@smith.example>;
+ rsa:modulus "..."^^cert:hex;
+ rsa:public_exponent "..."^^cert:int .
+ """ .
+
+_:profilePubkey2Graph
+ owl:sameAs "[] a <http://www.w3.org/ns/auth/rsa#RSAPublicKey> ;....."^^log:parsedAsN3.
+
+_:modulus
+ owl:sameAs "a...b"^^cert:hex.
+
+_:publicExponent
+ owl:sameAs "65537"^^cert:int.
+
+
+# Did the client provide a X509 certificate?
+[] a earl:Assertion;
+ earl:test wit:certificateProvided;
+# earl:subject -> there can't be an earl subject here, because then the test would be verified in its own desciption. In any case there is no way at this point of referring to the subject.
+ earl:result [ a earl:TestResult;
+ dct:description "Certificate provided";
+ earl:outcome earl:passed;
+ earl:pointer _:certificate;
+ ] .
+
+# Does the client certificate contain a subject alternative name?
+# note: it should perhaps contain 2, just to help make clear that we are not only requiring https
+# the other SAN should be an e-mail address.
+[] a earl:Assertion;
+ earl:subject _:certificate;
+ earl:test wit:certificateProvidedSAN;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer "http://example.tld/card#me"^^xsd:anyUri, "mailto:joe@smith.example"^^xsd:anyUri ] .
+
+# Is the current timestamp between begin and end date of the certificate?
+[] a earl:Assertion;
+ earl:subject _:certificate ;
+ earl:test wit:certificateDateOk ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:verificationTimestamp ] .
+
+# Could the public key be recognised (is the algorithm known, is it well formed, etc...)?
+# The other question is: is this a public key we know how to parse in rdf. So we don't yet have ontologies
+# for DSA. We may later, but some implementations may not at that point know how to.
+[] a earl:Assertion;
+ earl:subject _:certificate;
+ earl:test wit:certificatePubkeyRecognised;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicKey ] .
+
+# Does the certificate contain no unnecessary critical extensions?
+[] a earl:Assertion;
+ earl:subject _:certificate;
+ earl:test wit:certificateCriticalExtensionsOk;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ ] . # the earl pointer here could be used to point to the name of the critical extension used.
+
+# Does the certificate fulfill all requirements for a WebID certificate?
+[] a earl:Assertion;
+ earl:subject _:certificate ;
+ earl:test wit:certificateOk ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ ] . #the pointer here would point to some part of the certificate that was wrong, or perhaps it should point to the testresult that invalidated it?
+
+# Is the WebID Profile accessible and downloadable?
+[] a earl:Assertion;
+ earl:subject <http://example.tld/card#me>; #note: we should put a demo profile up at ./card with an xml version ./card.rdf and an n3 version ./card.n3 for example, so here we are speaking about a particular version of the card.
+ earl:test wit:profileGet;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer <http://example.tld/card.n3> ] . #is this a good pointer? Well if we received the n3 representation, then yes, this is pointing more precisely.
+
+# Does the profile contain only well formed keys for that WebID?
+[] a earl:Assertion;
+ earl:subject <http://example.tld/card.n3>; # I think we maintain the name of the document, or we speak of a representation. Ie, now we are speaking about a particular string, with a particular semantics. Putting the whole document in the report may be a bit heavy, so it's not required. Perhaps there should be a link to it. todiscuss
+ earl:test wit:profileWellFormed;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:profilePubkey1Graph ].
+
+# Does the public key contain only one modulus?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph; #agree it makes sense here to have the minigraph as subject
+ earl:test wit:pubkeyRSAModulusFunctional;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:modulus ]. #if there were two modulii would this be two pointers?
+
+# Is the RSA modulus a literal number?
+# btw, failure here is not necessarily a deadly problem - as long as we allow the old notation.
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAModulusLiteral;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:modulus ] .
+
+# Is the RSA modulus well formed?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAModulus;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:modulus ] .
+
+# Does the public key contain only one public exponent?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAExponentFunctional;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicExponent ] . # if there is more than one, then two pointers would make sense.
+
+# Is the RSA public exponent a literal number?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAExponentLiteral;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicExponent ] .
+
+# Is the RSA public exponent well formed?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:pubkeyRSAExponent;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:publicExponent ] .
+
+# Is the public key well formed?
+# The reduced profile contains only the public key.
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:profileWellFormedPubkey;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:profilePubkey1Graph ] .
+
+# Does the profile contain only well formed keys for that WebID?
+[] a earl:Assertion;
+ earl:subject _:profilePubkey1Graph;
+ earl:test wit:profileAllKeysWellFormed;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer _:profilePubkey1Graph ] .
+
+# Does the profile fulfill all requirements for WebID authentication?
+[] a earl:Assertion;
+ earl:subject <http://example.tld/card.n3>;
+ earl:test wit:profileOk;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer <http://example.tld/card#me> ]. #in particular with regard to this webid.
+
+# Could the particular WebID claim be verified?
+# TODO: How should we use the earl:pointer in this test case?
+[] a earl:Assertion;
+ earl:subject _:certWebIDClaim_1;
+ earl:test wit:webidClaim ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed ] . # does a pointer here make sense ?
+
+# Could at least one WebID claim be verified?
+# TODO: How should we use the earl:pointer in this test case?
+# TODO: Can we use multiple earl:subject properties?
+# bblfish: I don't think so. In the definition of subject is says "the subject". But could be an oversight.
+[] a earl:Assertion;
+ earl:subject _:certificate ;
+ earl:test wit:webidAuthentication ;
+ earl:result [ a earl:TestResult;
+ dct:description "";
+ earl:outcome earl:passed;
+ earl:pointer "http://example.tld/card#me"^^xsd:anyURI ] . #points to the WebIDClaims that were verfied
+
--- a/tests/earl/test.n3 Mon Jun 13 18:58:43 2011 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,205 +0,0 @@
-@prefix cert: <http://www.w3.org/ns/auth/cert#> .
-@prefix earl: <http://www.w3.org/ns/earl#> .
-@prefix zz: <http://clerezza.org/release/#> . #for the clerezza agent
-@prefix doap: <http://usefulinc.com/ns/doap#> .
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix wit: <http://www.w3.org/2005/Incubator/webid/test/> . #Web Id Test
-@prefix http: <http://www.w3.org/2006/http#> .
-@prefix dct: <http://purl.org/dc/terms/> .
-@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
-@prefix owl: <http://www.w3.org/2002/07/owl#> .
-@prefix : <#> .
-
-wit: a owl:Ontology .
-
-zz:r05 a earl:Software;
- doap:repository <https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.security.foafssl/test>;
- doap:programming-language "Scala";
- doap:developer <http://bblfish.net/#hjs>;
- doap:name "WebID Test suite in Clerezza" .
-
-
-<https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.security.foafssl/test> a doap:SVNRepository .
-
-###############################################
-#
-# Initial Test vocabulary to write somewhere
-#
-# todo: where should these be placed?
-#
-################################################
-
-# pure certificate tests
-
-wit:certificateProvided a earl:TestRequirement;
- dct:title "The client provided a x509 certificate".
-
-wit:certificateProvidedSAN a earl:TestRequirement;
- dct:title "The client certificate contains a subject alternative name".
-
-wit:certificateDateOk a earl:TestRequirement;
- dct:title "The current timestamp is between begin and end date of the certificate".
-
-wit:certificatePubkeyRecognised a earl:TestRequirement;
- dct:title "Public key in certificate recognised ";
- dct:description """The public key in the certificate is recognised by the WebId code. If it is not then it is not going to be possible
- to match it with the remote certificate. """ .
-
-wit:certificateCriticalExtensionsOk a earl:TestRequirement;
- dct:title "The certificate contains no unecessary critical extension";
- dct:description "Critical Extensions are not a direct problem for WebID, but can cause many servers to reject the certificate before the WebID code gets to see the certificate. These tests should not generate errors but only warnings" .
-
-
-# profile tests
-
-wit:profileGet a earl:TestRequirement;
- dct:title "WebId Profile is accessible and downloadable".
-
-wit:profileWellFormed a earl:TestRequirement;
- dct:title "WebId Profile is well formed";
- dct:description "The WebId Profile is parseable Content and transformable to RDF" .
-
-wit:profileWellFormedKey a earl:TestRequirement;
- dct:title "WebIdProfile Contains well formed Keys";
- dct:description "All the keys in the profile are well formed and not misleading";
- skos:note "One does not need to test all keys in a profile, only those that are tied to the WebIDs found in the X509 cert. But to help users one could give them a deeper test of the profile." .
-
-wit:profileWellFormedPubkey a earl:TestRequirement;
- dct:title "Public Key is well formed" ;
- dct:description "A particular Public key is well formed" .
-
-wit:pubkeyRSAModulus a earl:TestRequirement;
- dct:title "rsa:modulus is well formed" .
-
-wit:pubkeyRSAModulusFunctional a earl:TestCase;
- dct:title "not more than one modulus";
- dct:description "More than one modulus if they don't convert to the same number will lead to erratic behavior (one server will choose one the other server will chose the other)".
-
-wit:pubkeyRSAModulusLiteral a earl:TestCase;
- dct:title "rsa:modulus is a literal number";
- dct:description "In the current ontology we have moved to literals as the standard way of describing modulus and exponents".
-
-wit:pubkeyRSAExponent a earl:TestRequirement;
- dct:title "rsa:public_exponent is well formed" .
-
-wit:pubkeyRSAExponentFunctional a earl:TestCase;
- dct:title "not more than one public exponent per RSA public key - or else they have to be identical" ;
- dct:description "More than one exponent if they don't convert to the same number is very likely to create erratic behavior (one server will choose one the other server will chose the other)".
-
-wit:pubkeyRSAExponentLiteral a earl:TestCase;
- dct:title "rsa:exponent key is a literal";
- dct:description "In the current ontology we have moved to literals as the standard way of describing modulus and exponents".
-
-wit:pubkeyRSAModulusOldFunctional a earl:TestCase;
- dct:title "if modulus is using non literal notation, there should be only one cert:hex relation to plain literal";
- skos:note "this should be a deprecated test sooner rather than later. Warn people to move to newer notation.".
-
-wit:pubkeyRSAExponentOldFunctional a earl:TestCase;
- dct:title "if exponent is using non literal notation, there should be only one cert:decimal relation to plain literal" .
-
-
-# webid protocol tests: ie: tying pubkey and Webid in certificate to remote WebID identifying description
-
-wit:webidAuthentication a earl:TestRequirement;
- dct:title "WebID Authentication Test";
- dct:description "At least one webid claimed in the certificate has public key that verifies. " .
-
-wit:webidClaim a earl:TestRequirement;
- dct:title "Particular WebId Claim Test";
- dct:description "Verification of a particular WebID claim" .
-
-
-###############################################
-#
-# Example test result to make sure the above ontology is at least partially correct
-#
-################################################
-
-@prefix : <http://test.example/> .
-
-[] a earl:Assertion;
- earl:test wit:webid_verification;
- earl:result [ a earl:TestResult;
- dct:description "rsa public key has two relations for modulus";
- earl:outcome earl:failed ];
- earl:subject :webProfile, :x509;
-#{
-# for turtle parsers
-# [] cert:identity <http://bblfish.net/person/henry/card#me>;
-# cert:modulus "as123123..."^^cert:hex, "dfff32093sd..."^^cert:hex;
-# cert:public_exponent "65537"^^cert:int .
-#};
- earl:assertedBy zz:0_5-SNAPSHOT .
-
-
-[] a earl:Assertion;
- earl:test wit:pubkeyMod_func;
- earl:result [ a earl:TestResult;
- dct:description "webid http://user.example/#me does not have a matching public key in profile";
- earl:outcome earl:success ];
- earl:subject :webProfile, :x509;
- earl:assertedBy zz:0_5-SNAPSHOT .
-
-[] a earl:Assertion;
-earl:test wit:certificate_provided_san;
-earl:result [ a earl:TestResult;
- dct:description "SAN missing";
- earl:outcome earl:failed;
- earl:pointer :x509 ];
-earl:subject :webProfile, :x509 .
-
-[] a earl:Assertion;
-earl:test wit:webid_verification;
-earl:result [ a earl:TestResult;
- dct:description "ok";
- earl:outcome earl:passed ];
-earl:subject :webProfile, :x509 .
-
-[] a earl:Assertion;
-# verification also on the URI level!!!
-earl:test wit:webid_verification_uri;
-earl:result [ a earl:TestResult;
- dct:description "ok";
- earl:outcome earl:passed;
- earl:pointer <http://bblfish.net/person/henry/card#me> ];
-earl:subject :webProfile, :x509 .
-
-[] a earl:Assertion;
-earl:test wit:pubkey_rsa_modulus;
-earl:result [ a earl:TestResult;
- dct:description "modulus missing";
- earl:outcome earl:failed;
- earl:pointer <http://bblfish.net/person/henry/card#me2> ];
-earl:subject :webProfile, :x509 .
-
-:x509 a cert:X509Certificate;
- cert:base64der """
-MIIDgzCCAuygAwIBAgIQZ84ABvhjj7hqFoWqSsvBFjANBgkqhkiG9w0BAQUFADBj
-MREwDwYDVQQKDAhGT0FGK1NTTDEmMCQGA1UECwwdVGhlIENvbW11bml0eSBvZiBT
-ZWxmIFNpZ25lcnMxJjAkBgNVBAMMHU5vdCBhIENlcnRpZmljYXRpb24gQXV0aG9y
-aXR5MB4XDTExMDMyODE0MDY1MFoXDTEyMDMxODE2MDY1MFowgYsxETAPBgNVBAoM
-CEZPQUYrU1NMMSYwJAYDVQQLDB1UaGUgQ29tbXVuaXR5IE9mIFNlbGYgU2lnbmVy
-czE3MDUGCgmSJomT8ixkAQEMJ2h0dHA6Ly9iYmxmaXNoLm5ldC9wZW9wbGUvaGVu
-cnkvY2FyZCNtZTEVMBMGA1UEAwwMYmJsZmlzaCBjYXJkMIIBIjANBgkqhkiG9w0B
-AQEFAAOCAQ8AMIIBCgKCAQEA5+kuueCGksuOuQciIrf7hjSRiahB8c3hd8hPjTH/
-6k+NBKN+H0MRHPiSVCVwvvhstF2zmE6Ms0NwzSDWHuSOqjEwu6+CKE8tvL0Y0OHk
-bkhVDhenLPQagKIWjXe0k4CDIcizyNj1L8zRwsN0TaxrYZZPlaTx2/VpMI3ApaVK
-yb/4+mJ4UZDBol9TMkTfyBbPq3iISMz6rt3vsNgksXar0DCftGag2V2E1L/t8Hvu
-De0UaqKajsIlVtu/iUMSYKu41dZJCVCYm/DrqcX0m1aUwHAYWKtSap9Z5p7PnJVo
-wqp2/3jnsf7h6WlUN9yQtm/FeEeMp+3Mx7DokAYYTElTaQIDAQABo4GKMIGHMAwG
-A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgLsMBEGCWCGSAGG+EIBAQQEAwIFoDAd
-BgNVHQ4EFgQUzoQy71OnKyW8qE7boOHpLrjN2aQwNQYDVR0RAQH/BCswKYYnaHR0
-cDovL2JibGZpc2gubmV0L3Blb3BsZS9oZW5yeS9jYXJkI21lMA0GCSqGSIb3DQEB
-BQUAA4GBAH0kxSBDYGAMah4cloznjsnglGNMCTd2zPtxnWDFUjuD2YWhc8QXd/k7
-T1GlVZdLfT175/D7jYpXEVH7UyO8DTnttlAePmDqbspT+vcpV1orUrWlMTJ7hAzP
-Ev9aBOHrZPyKDeUJO0JgwAWxOU/ND347Ssg3lTbFt0jrZxDLHLxC""";
- # should we also have a relation to the openssl type text format? Is that a standard?
- cert:subjectAlternativeName <http://bblfish.net/people/henry/card#me>;
- cert:IssuerDistinguishedName "O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority".
-
-:webProfile a http:Response;
- http:httpVersion "1.1";
- http:headers [];
- http:body "#the rdf file used. could be n3, or something. This could also point to the content?..." .
-