Document describing a vocabulary to allow a RelyingParty to make a report on an attempt at a WebID authentication. A WebID Claim is a graph that consists of a claim that a public key identifies some WebID. Every WebID published in a certificate constitutes one WebID claim: the claim that the referent of the WebID is the only one to know the private key of the public key that came in the certificate Critical Extensions are not a direct problem for WebID, but may cause many servers to reject the certificate before the WebID code gets to see it. These tests should not generate errors but only warnings Does the certificate contain no unnecessary critical extensions? The earl:subject property must point to the certificate. The certificate is described with the class cert:Certificate using the property cert:base64der. The property cert:principal_key should point to the contained public key. The time of this session should be between the begin and end date of the certificate validity times Is the certificate alive? The earl:subject property must point to the certificate. The certificate is described with the class cert:Certificate using the property cert:base64der. The property cert:principal_key should point to the contained public key. The certificate must be alive, have one or more WebIDs, should have a public key recognised by the semantic web layer, and should avoid having critical extensions. Does the certificate fulfill all requirements for a WebID certificate? If any of the child test cases fails this test requirement must return earl:failed. Without a client certificate this type of WebID Authentication can not take place. Did the client provide a X509 certificate? If the client provided an certificate, the earl:pointer property must point to it. The certificate is described with the class cert:Certificate using the property cert:base64der. The property cert:principal_key must point to the contained public key. The public key is described with a rsa:publicKey which contains the properties rsa:modulus and rsa:public_exponent. The log:semantics property must point to a blank node that contains a log:includes property for every WebIDClaim. The client certificate must contain at least one Subject Alternative Name in the SAN field of the certificate Does the client certificate contain a subject alternative name? The earl:subject property must point to the certificate. The earl:pointer must contain the complete subject alternative name string. The certificate is described with the class cert:Certificate using the property cert:base64der. The property cert:principal_key should point to the contained public key. The public key in the certificate is recognised by the WebId code. If it is not then this server will not know how to match it with the remote WebID Profile. Could the public key be recognised? The earl:subject property must point to the certificate. The earl:pointer must point to the public key. The certificate is described with the class cert:Certificate using the property cert:base64der. The property cert:principal_key should point to the contained public key. The public key is described with the class rsa:RSAPublicKey with the properties rsa:modulus and rsa:public_exponent like described in the WebID specification. Identity URI of a WebID Claim. Public key of a WebID Claim. All the keys in the profile should be well formed and semantically consistent. It is not necessarily fatal to a particular WebID authentication if they are not, but it is worth alerting the user, as this may lead to inconsistent user experience. Does the profile contain only well formed keys for that WebID? 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. The WebID profile must be retrievable if the claims are going to be verified. Is the WebID Profile accessible and downloadable? The earl:subject property should point to the WebID profile, or to a link where a copy of that profile can be fetched. The content could also be included in the document. Does the profile fulfill all requirements for WebID authentication? The WebId Profile must be parseable Content and transformable to an RDF graph Is the profile well formed? The earl:subject property should point to the WebID profile, or to a link where a copy of that profile can be fetched. The content could also be included in the document. A particular Public key should be well formed Is the public key well formed? The current cert ontology doesn't include properties for DSA, and so there are currently no tests for DSA keys either The earl:subject property must point to a graph that contains the public key and its webid relation. To help this being processed by tools that are not able to deal with n3 graphs, this should point using the log:n3string relation to a turtle serialisation of the graph (turtle is a subset of n3) Is the public key present in valid old non literal notation? There may be a number of ways of writing the exponent. Is this server able to parse this particular exponent? Is the RSA public exponent well formed? 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) Does the public key contain only one public exponent? In the current ontology we have moved to literals as the standard way of describing modulus and exponents Is the RSA public exponent a literal number? If public exponent is using non literal notation, is there only one cert:decimal relation to plain literal? There may be a number of ways of writing the modulus. Is this server able to parse this particular modulus? Is the RSA modulus well formed? 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) Does the public key contain only one modulus? In the current ontology we have moved to literals as the standard way of describing modulus and exponents Is the RSA modulus a literal number? If modulus is using non literal notation, is there only one cert:hex relation to plain literal? this should be a deprecated test sooner rather than later. Warn people to move to newer notation. At least one WebID claimed in the certificate has public key that verifies. Could at least one WebID claim be verified? Verification of a particular WebID claim Could the particular WebID claim be verified?