--- a/spec/index-respec.html Mon Jan 16 17:43:32 2012 +0100
+++ b/spec/index-respec.html Wed Oct 24 02:09:40 2012 -0400
@@ -343,28 +343,28 @@
<p>
The WebID protocol enables secure, efficient and maximally user friendly authentication on the Web.
-It enables people to authenticate onto any site by simply clicking on one of the certificates proposed to them by their browser.
-These certificates can be created by any Web Site for their users in one click.
+It enables people to authenticate onto any site by simply choosing one of the certificates proposed to them by their browser.
+These certificates can be created by any Web Site for their users.
The identifier, known as the <tref>WebID</tref>, is a URI whose sense can be found in the associated <tref>Profile Page</tref>, a type of web page that any Social Network user is familiar with.</p>
<p>
-These WebIDs can be used to build a Web of trust using vocabularies such as <a href="http://xmlns.com/foaf/0.1/">foaf</a> by allowing people to link together their profiles in a public or protected manner.
-Such a web of trust can then be used by a <tref>Service</tref> to make authorization decisions, by allowing access to resource depending on the properties of an agent, such that the he is known by some relevant people, works at a given company, is a family member, is part of some group, ...</p>
+These WebIDs can be used to build a Web of trust using vocabularies such as <a href="http://xmlns.com/foaf/0.1/">FOAF</a> by allowing people to link together their profiles in a public or protected manner.
+Such a web of trust can then be used by a <tref>Service</tref> to make authorization decisions, by allowing access to resource depending on the properties of an agent, such that he/she is known by some relevant people, works at a given company, is a family member, is part of some group, ...</p>
<p>
-The WebID protocol specifies how a <tref>Service</tref> can authenticate a user after requesting his <tref>Certificate</tref> without needing to rely on this being signed by a well known Certificate Authority. This is done by dereferencing the <tref>WebID Profile</tref>, and checking if it describes the user as being in control of the the private key related to the <tref>Public Key</tref> published in the <tref>Certificate</tref> she used to authenticate.
+The WebID protocol specifies how a <tref>Service</tref> can authenticate a user after requesting his or her <tref>Certificate</tref> without needing to rely on this being signed by a well known Certificate Authority. This is done by dereferencing the <tref>WebID Profile</tref>, and checking if it describes the user as being in control of the private key related to the <tref>Public Key</tref> published in the <tref>Certificate</tref> used to authenticate.
</p>
<p>WebID authentication can also be used for automatic authentication by robots, such as web crawlers of linked data repositories, which could be agents working on behalf of users to help them in their daily tasks. The WebID protocol is not limited to authentication on the World Wide Web, but can work with any TLS based protocol.</p>
<section>
<h1>Outline</h1>
<p>This specification is divided in the following sections.</p>
-<p><a href="#introduction">This section</a> gives a high level overview of the WebID Protocol, and presents the organisation of the specification and the conventions used throughout the document.</p>
-<p><a href="#preconditions">Section 2</a> lists the preconditions that need to be in place for any authentication sequence to be successful: which include the creation of a <tref>WebID Profile</tref> and the creation of a <tref>WebID Certificate</tref></p>
+<p><a href="#introduction">This section</a> gives a high level overview of the WebID Protocol, and presents the organization of the specification and the conventions used throughout the document.</p>
+<p><a href="#preconditions">Section 2</a> lists the preconditions that need to be in place for any authentication sequence to be successful: which include the creation of a <tref>WebID Profile</tref> and the creation of a <tref>WebID Certificate</tref></p>.
<p><a href="#the-webid-protocol">Section 3</a> on the WebID Protocol describes in detail how a server can authenticate a user.</p>
</section>
<section>
<h1>Terminology</h1>
<dl>
<dt><tdef>Alice</tdef></dt>
-<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access</dd>
+<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access.</dd>
<dt><tdef>Bob</tdef></dt>
<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who is responsible for the private key the <tref>Client</tref> uses to authenticate to <tref>Service</tref>s.
@@ -377,7 +377,7 @@
The Subject is distinct from the <tref>Client</tref> which is used to connect to the <tref>Server</tref>.
</dd>
<dt><tdef>Client</tdef></dt>
-<dd>The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server. It can request authentication credentials from a <tref>Key Store</tref> to send to a server
+<dd>The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server. It can request authentication credentials from a <tref>Key Store</tref> to send to a server.
</dd>
<dt><tdef>Key Store</tdef></dt>
@@ -389,7 +389,7 @@
<dd>A Server is a machine contactable at a domain name or IP address that hosts a number of globally accessible Services.</dd>
<dt><tdef>Service</tdef></dt>
-<dd>A Service is a an agent listening for requests at a given IP address on a given Server</dd>
+<dd>A Service is a an agent listening for requests at a given IP address on a given Server.</dd>
<dt><tdef>TLS Service</tdef></dt>
<dd>A TLS Service is a transport level service listening on the <tref>Service</tref> port.
@@ -415,20 +415,20 @@
</dd>
<dt><tdef>Guard</tdef><dt>
-<dd>A Guard is an agent, usually on the <tref>Server</tref> that can look at a request from the <tref>Client</tref> and decide if it needs to be authorised by looking at the access control rules for that resource.
-If the request requires authorisation, the Guard can first demand authentication of the <tref>Client</tref> and use the <tref>WebID Verifier</tref> to check any claimed identies that would allow it to come to an authorization decision.
+<dd>A Guard is an agent, usually on the <tref>Server</tref> that can look at a request from the <tref>Client</tref> and decide if it needs to be authorized by looking at the access control rules for that resource.
+If the request requires authorization, the Guard can first demand authentication of the <tref>Client</tref> and use the <tref>WebID Verifier</tref> to check any claimed identies that would allow it to come to an authorization decision.
Finally the Guard can grant or deny access according to how the verfied identities satisfy the Access Control Rules.
</dd>
<dt><tdef>WebID Claim</tdef> or <tdef>Claimed WebID</tdef></dt>
-<dd>A <tref>WebID Certificate</tref> can be thought of a set of statements made and signed by a <tref>Certificate Authority</tref>.
+<dd>A <tref>WebID Certificate</tref> can be thought of as a set of statements made and signed by a <tref>Certificate Authority</tref>.
If the Certificate Authority is not known to be one whose every statement can be trusted, then the statements in the certificate must be thought of by a suspicious guard, as claimed statements only, that is as statements which have not been verified.
-In particular statements about the Subject Alternative Names of the agent that knows the private key, should not be assumed to be true until verified.
-A WebID Claim then is the statement of Identity between the a Subject Alternative name and the public key in the certificate.
+In particular, statements about the <code>Subject Alternative Name</code>s of the agent that knows the private key should not be assumed to be true until verified.
+A WebID Claim then is the statement of Identity between the <code>Subject Alternative Name</code> and the public key in the certificate.
In Turtle this can be written as
<pre class="example">
:bob cert:key [ a cert:RSAPublicKey;
- cert:modulus "00:cb:24:ed:85:d6:4d:79:4b..."^^xsd:hexBinary;
+ cert:modulus "00cb24ed85d64d794b..."^^xsd:hexBinary;
cert:exponent 65537 ] .
</pre>
</dd>
@@ -468,8 +468,8 @@
A structured document asserting the relationship between the Subject (identified by his WebID) and his <tref>Public Key</tref>s using relationships as defined by the Resource Description Framework [[RDF-CONCEPTS]] and published at the URL location of the Subject's WebID.
Dereferencing the <tref>WebID</tref> should return the Profile Page in one of a number of formats.
The Server MUST publish the document in at least the XHTML+RDFa [[!XHTML-RDFA]] serialization format or in Turtle [[!TURTLE-TR]].
-The document may be published in a number of other RDF serialization formats, such as RDF-XML [[!RDF-PRIMER]], or N3 [[!N3]].
-Any other serialisations that intend to be used by the WebID Protocol MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
+The document may be published in a number of other RDF serialization formats, such as RDF/XML [[!RDF-PRIMER]], or N3 [[!N3]].
+Any other serializations that intend to be used by the WebID Protocol MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
<p class="issue">Most profiles are currently written out in either of those formats. Whether or not XHTML+RDFa 1.1, both either serialization of RDF should be required serialization formats in the specification is currently under heavy debate and is open to change. </p>
</dd>
@@ -590,7 +590,7 @@
<p class="issue">Should we formally require the Issuer to be
O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority.
This was discussed on the list as allowing servers to distinguish certificates
-that are foaf+SSL enabled from others. Will probably need some very deep TLS
+that are FOAF+SSL enabled from others. Will probably need some very deep TLS
thinking to get this right.</p>
<p class="issue">The above certificate is no longer valid, as I took an valid
certificate and change the time and WebID. As a result the signature is now
@@ -602,7 +602,7 @@
Some <tref>Key Store</tref> allow a user to create the Certificate directly with a friendly User Interface.
But using a <tref>Key Store</tref> on the client still requires the public key to be published on the server as detailed in the next section.
It is possible to combine the creation of the key with its publication in one step in such a way as to allow the server to make the decision of what the WebID should be, by using the <a href="http://www.w3.org/TR/html5/the-button-element.html#the-keygen-element">HTML 5 keygen</a> element.
-This element can be placed in an HTML5 form, where on submitting the form, the browser asks the <tref>Key Store</tref> to create a public and private key pair, and on receiving the public part of that keypair the Client can sends a keyrequest as part of the form to the <tref>Service</tref>. The <tref>Service</tref> can then create a <tref>WebID Certificate</tref> and return it to the <tref>Client</tref> to pass onto the <tref>Key Store</tref>. In that way the Server is in the position to best make the decisions of what the <tref>Certificate</tref> should say and what the WebID should be without the private key ever leaving the secure <tref>Key Store</tref>. The user experience for this Certificate creation is a one click operation.
+This element can be placed in an HTML5 form, where on submitting the form, the browser asks the <tref>Key Store</tref> to create a public and private key pair, and on receiving the public part of that key pair, the Client can send a key request as part of the form to the <tref>Service</tref>. The <tref>Service</tref> can then create a <tref>WebID Certificate</tref> and return it to the <tref>Client</tref> to pass onto the <tref>Key Store</tref>. In that way the Server is in the position to best make the decisions of what the <tref>Certificate</tref> should say and what the WebID should be without the private key ever leaving the secure <tref>Key Store</tref>. The user experience for this Certificate creation is a one click operation.
</section>
</section>
@@ -613,13 +613,13 @@
The set of relations to be published at the <tref>WebID Profile</tref> document can be presented in a graphical notation as follows.</p>
<img alt="Web ID graph" width="90%" src="img/WebIdGraph.jpg"/>
<p>The document can publish many more relations than are of interest to the WebID protocol, as shown in the above graph by the grayed out relations.
-For example Bob can publish a depiction or logo, so that sites he authenticates to can personalise the user experience. He can post links to people he knows, where those have WebIDs published on other sites, in order to create a distributed Social Web.
+For example Bob can publish a depiction or logo, so that sites he authenticates to can personalize the user experience. He can post links to people he knows, where those have WebIDs published on other sites, in order to create a distributed Social Web.
He can also publish relations to protected documents, where he keeps more information for people who authenticate, such as his friend Alois or his friends friends who may not yet know him personally, such as Alice.
</p>
<p>
-The protocol does not depend on any particular serialisation of the graph, provided that agents are able to parse that serialisation and obtain the graph automatically.
+The protocol does not depend on any particular serialization of the graph, provided that agents are able to parse that serialization and obtain the graph automatically.
Technologies such as GRDDL [[!GRDDL-PRIMER]] for example permit any XML format to be transformed automatically to a graph of relations.
-HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serialisations of the same graph at the same URL, as explained by the working group note <a href="http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/">Best Practice Recipes for Publishing RDF Vocabularies</a> [[!SWBP-VOCAB-PUB]]</p>
+HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serializations of the same graph at the same URL, as explained by the working group note <a href="http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/">Best Practice Recipes for Publishing RDF Vocabularies</a> [[!SWBP-VOCAB-PUB]]</p>
<p class="note">
For reasons of interoperability, in order not to overburden the implementation and testing work of <tref>WebID Verifier</tref>s, and in order to provide a seamless experience for end users, of the many formats that can be publish at one location, it is established that at present publishers SHOULD publish their documents in at least one of RDFa [[!XHTML-RDFA]] or [[!TURTLE-TR]] as these MUST be understood by <tref>Verification Agent</tref>s.
If other formats grow in popularity, are implemented by verifiers, and gain community acceptance, these can be added to the list.
@@ -644,14 +644,14 @@
<p>RDF graphs are built using vocabularies defined by URIs, that can be placed in subject, predicate or object position.
The definition of each URI should be found at the namespace of the URI, by dereferencing it.
- Here we list the core cryptographic terms needed, and detail some of the useful optional relations from the foaf
+ Here we list the core cryptographic terms needed, and detail some of the useful optional relations from the FOAF
vocabulary that we have used in the diagrams.
</p>
<section class='normative'>
<h2>Cryptographic Vocabulary</h2>
<p>The following properties SHOULD be used when conveying the relation between the
- <tref>Subject</tref> and his key.
+ <tref>Subject</tref> and his or her key.
<tref>WebID Profile</tref> documents:</p>
<dl>
<dt><a href="http://www.w3.org/ns/auth/cert#RSAPublicKey">cert:RSAPublicKey</a></dt>
@@ -686,7 +686,7 @@
<dt>foaf:mbox</dt>
<dd>The e-mail address that is associated with the WebID URI.</dd>
<dt>foaf:name</dt>
- <dd>The name that is most commonly used to refer to the individual
+ <dd>The name of the individual
or agent.</dd>
<dt>foaf:depiction</dt>
<dd>An image representation of the individual or agent.</dd>
@@ -769,8 +769,8 @@
<p class="issue">In order to make the above modulus easy to read for humans who may wish to compare it with the modulus in their browser, one can add some javascript. Add some javascript here that adds a : between every two characters, and that splits the line up in chunks.</p>
<p>If a WebID provider would rather prefer not to mark up his data in RDFa, but
just provide a human readable format for users and have the RDF graph appear
-in a machine readable format such as RDF/XML then he MAY publish the link from
-the HTML to a machine readable format (if this is available at a dedicated URI)
+in a machine readable format such as RDF/XML then a link from
+the HTML to a machine readable format MAY be published
as follows:</p>
<p class="example">
<pre>
@@ -790,12 +790,12 @@
</section>
<section class='normative'>
<h1>Disabling a WebID Certificate</h1>
-<p>A <tref>WebID Certificate</tref> identifies the <tref>Subject</tref> alone and no one else, if and only if she is the only one to control the corresponding private key.
+<p>A <tref>WebID Certificate</tref> identifies the <tref>Subject</tref> alone and no one else, if and only if that <tref>Subject</tref> is the only one to control the corresponding private key.
It is very important therefore that the <tref>Subject</tref> take care of keeping the <tref>private key</tref> secure.
This can be done by keeping it in the <tref>Key Store</tref> of a personal machine in an account that is password protected and free of viruses, or best of all on some physical device where the private key is inaccessible to be read by any software.
In the second case having the device implies that the <tref>private key</tref> has not been lost or copied.
In the first case the user has to be more careful for signals of misuse.<p>
-<p>In either situation if the <tref>Subject</tref> is suspicious that his private key has been taken, then he can disable future authentications for that certificate by removing the corresponding <tref>public key</tref> from his <tref>WebID Profile</tref>.
+<p>In either situation if the <tref>Subject</tref> is suspicious that his private key has been taken, future authentications for that certificate can be disabled by removing the corresponding <tref>public key</tref> from the <tref>WebID Profile</tref>.
If the profile contains more than one public key for the <tref>Subject</tref> then it is suggested that each public key contain a label to help the user locate the key. In the examples above an <code>rdfs:label</code> with a creation date was used for this purpose.
</p>
</section>
@@ -826,9 +826,9 @@
The <tref>Guard</tref> can then intercept that request and by checking some access control rules determine if the client needs authorization and hence authentication.
We will consider the case here where the client does need to be authenticated.
</li>
- <li>The Guard MUST requests the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarised by the following steps:
+ <li>The Guard MUST request the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarized by the following steps:
<ol>
- <li>The guard requests of the TLS agent that it make a Certificate Request to the client. The TLS layer does this. Because the WebID protocol does not rely on Certificate Authorities to verify the contents of the <tref>Certificate</tref>, the <tref>TLS Agent</tref> can ask for any Certificate from the Client. More details in <a href="#requesting-the-client-certificate">Requesting the Client Certificate</a>
+ <li>The guard requests the TLS agent to make a Certificate Request to the client. The TLS layer does this. Because the WebID protocol does not rely on Certificate Authorities to verify the contents of the <tref>Certificate</tref>, the <tref>TLS Agent</tref> can ask for any Certificate from the Client. More details in <a href="#requesting-the-client-certificate">Requesting the Client Certificate</a>
</li>
<li>The Client asks Bob to choose a certificate if the choice has not been automated.
We will assume that Bob does choose a <tref>WebID Certificate</tref> and sends it to the client.
@@ -857,7 +857,7 @@
by dereferencing the URI, using the canonical method for dereferencing a URL of that scheme.
For an <code>https://...</code> <tref>WebID</tref> this would be done using the [[!HTTP-TLS]] protocol.
The dereferencing of the URI MAY use any representation caching mechanism it can to speed up the process.
- The returned representation is then transformed into an RDF graph [[!RDF-MT]] as specified in Processing the WebID Profile .
+ The returned representation is then transformed into an RDF graph [[!RDF-MT]] as specified in processing the WebID Profile .
This graph may be then be cached to speed up future requests.
</li>
</ol>
@@ -892,8 +892,8 @@
If the client sends a certificate, then neither of these have an impact on the <tref>WebID Verification</tref> steps (4) and (5).
Nevertheless, from a user interaction perspective both of these are problematic as they either force (NEED) or ask the user to authenticate himself even if the resource he wishes to interact with is public and requires no authentication.
Furthermore very few people will feel comfortable authenticating to a web site on the basis of reading the server certificate alone.
-Most people would like to know more about what the web site claims to be about, before divulging their identity.
-This is usually done by reading a few web pages without having authenticated.
+Most people would like to know more about what the web site claims to be about before divulging their identity.
+This is usually done by reading a few web pages without being authenticated.
Hence it is important for human users that authentication be only requested on user demand.
This can be done by using TLS renegotiation and moving the authentication to the application layer <tref>Guard</tref> which can make more fine grained decisions on when authentication is required.
@@ -914,11 +914,11 @@
<section class='normative'>
<h2>Requesting the Client Certificate</h2>
-<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [section 7.4.4] of TLS v1.1 [[!RFC5246]]. Since WebID TLS authentication does not rely on CA's signing the certificate to verify the WebID Claims made therein, the Server does not need to restrict the certificate it receives by the CA's they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
+<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [Section 7.4.4] of TLS v1.1 [[!RFC5246]]. Since WebID TLS authentication does not rely on CAs signing the certificate to verify the WebID Claims made therein, the Server does not need to restrict the certificate it receives by the CAs they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
<p class="note">From our experience leaving the certificate_authorities field empty leads to the correct behavior on all browsers and all TLS versions.</p>
<p class="note">A security issue with TLS renegotiation was discovered in 2009, and an IETF fix was proposed in [[!RFC5746]] which is widely implemented.</p>
<p>If the Client does not send a certificate, because either it does not have one or it does not wish to send one, other authentication procedures can be pursued at the application layer with protocols such as OpenID, OAuth, BrowserID, etc... </p>
-<p>As far as possible it is important for the server to request the client certificate in <code>WANT</code> mode, not in <code>NEED</code> mode.
+<p>As much as possible it is important for the server to request the client certificate in <code>WANT</code> mode, not in <code>NEED</code> mode.
If the request is made in <code>NEED</code> mode then connections will be broken off if the client does not send a certificate.
This will break the connection at the application protocol layer, and so will lead to a very bad user experience. The server should therefore avoid doing this unless it can be confident that the client has a certificate - which it may be because the client advertised that in some other way to the server.
</p>
@@ -927,8 +927,8 @@
</section>
<section class='normative'>
<h2>Verifying the WebIDs</h2>
-<p>The <tref>Verification Agent</tref> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and it's meaning can be had by dereferencing it using the protocol indicated in its scheme. </p>
-<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [[!RFC3986]]
+<p>The <tref>Verification Agent</tref> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and its meaning can be obtained by dereferencing it using the protocol indicated in its scheme. </p>
+<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [[!RFC3986]]:
<blockquote>
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.
The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
@@ -1008,20 +1008,20 @@
</section>
<section class="normative">
<h2>Verifying the WebID claim without SPARQL</h2>
-<p>If the RDF library does datatype normalisation of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <tref>WebID</tref> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.
+<p>If the RDF library does datatype normalization of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <tref>WebID</tref> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.
</p>
-<p>For triples stores that do not normalise literals on loading a graph, the normalization will need to be done after the query results and before matching those with the values from the <tref>Certificate</tref>. Because one could not rely on the modulus having been normalized, one would have to start with the <tref>WebID</tref> - <code>bob:me</code> and find all it's <code>cert:key</code> relations to objects - which we know to be keys - and then iterate through each of those keys' modulus and exponent, and verify if the normalised version of the value of those relation is equal to the numbers found in the certificate. If one such key is found then the answer is <code>true</code>, otherwise the answer will be <code>false</code>.</p>
+<p>For triples stores that do not normalize literals on loading a graph, the normalization will need to be done after the query results and before matching those with the values from the <tref>Certificate</tref>. Because one could not rely on the modulus having been normalized, one would have to start with the <tref>WebID</tref> - <code>bob:me</code> and find all it's <code>cert:key</code> relations to objects - which we know to be keys - and then iterate through each of those keys' modulus and exponent, and verify if the normalized version of the value of those relation is equal to the numbers found in the certificate. If one such key is found then the answer is <code>true</code>, otherwise the answer will be <code>false</code>.</p>
</section>
</section>
<section class='normative'>
<h2>Authorization</h2>
-<p>The Authorization step may be as simple as just allowing everybody read access. The authentication phase may then just have been useful in order to gain some extra information from the <tref>WebID Profile</tref> in order to personalise a site.</p>
+<p>The Authorization step may be as simple as just allowing everybody read access. The authentication phase may then just have been useful in order to gain some extra information from the <tref>WebID Profile</tref> in order to personalize a site.</p>
<p>Once the <tref>Guard</tref> has a WebID he can do a lookup in a database to see if the agent is allowed the required access to the given resource.
-Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalise the site for the requestor.
+Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalize the site for the requestor.
But the interesting thing about such a WebID is that because it is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another.
-It is therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains.
-It is even be possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
+It is therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends' friends (FOAF), stated by them at their domains.
+It is even possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
There are too many possibilities to list them all here.
</p>