--- a/spec/index-respec.html Mon Nov 21 14:16:10 2011 +0100
+++ b/spec/index-respec.html Mon Nov 21 15:01:06 2011 +0100
@@ -406,8 +406,12 @@
<dt><tdef>Alice</tdef></dt>
<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access</dd>
+<dt><tdef>Subject</tdef></dt>
+<dd>The Subject is the Agent that is identified by the <tref>WebID</tref>. When used correctly it is the Subject who wishes to authenticate to a <tref>Service</tref>.
+When speaking of a particular agent, and in order to improve lisibility in this spec, we will name him <tref>Bob</tref>. The Subject is distinct from the <tref>Client</tref> which is used to connect to the <tref>Server</tref>.</dd>
+
<dt><tdef>Bob</tdef></dt>
-<dd>Bob is any agent who uses a Client to connect to Alice's Service, and who controls the private key the client uses to access the resource</dd>
+<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who controls the private key the client uses to access the resource.</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.</dd>
@@ -419,52 +423,47 @@
<dd>A Service is a an agent listening for requests at a given ip address on a given Server</dd>
<dt><tdef>Guard</tdef><dt>
-<dd>A guard is an agent that can look at a request from the <tref>Client</tref> and decide if it needs Authentication by looking at the Access control Rules. If it needs Authentication it can request it, and it can use the <tdef>WebId Verifier</tdef> to complete identity checks. Finally it can grant or deny access.</dd>
+<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 Authentication by looking at the Access control Rules.
+If it needs Authentication it can request it, and it can use the <tref>WebId Verifier</tref> to complete identity checks.
+Finally it can grant or deny access.
+</dd>
<dt><tdef>Verification Agent</tdef> or <tdef>WebId Verifier</tdef></dt>
-<dd>Performs authentication on provided WebID credentials, ie it verifies that the WebID is indeed identified by a given public key.</dd>
+<dd>Performs authentication on provided WebID credentials.</dd>
<dt><tdef>WebID Certificate</tdef></dt>
<dd>An X.509 [[!X509V3]] Certificate that MUST contain a
-<code>Subject Alternative Name</code> extension with at least one URI entry
-identifying the <tref>Client</tref>. This URI MUST be
-dereference-able and result in a document containing RDF data.
-For example, a certificate identifying the WebID URI
-<code>http://example.org/bob#me</code> would contain the following:
+<code>Subject Alternative Name</code> extension with at least one URI entry identifying the <tref>Subject</tref>.
+This URI MUST be one of the URIs with a dereferenceable secure scheme, such as https:// . Dereferencing this URI should return a representation containing RDF data.
+For example, a certificate identifying the WebID URI <code>http://bob.example/profile#me</code> would contain the following:
<pre>
X509v3 extensions:
...
X509v3 Subject Alternative Name:
- URI:http://example.org/bob#me
+ URI:http://bob.example/profile#me
</pre>
+Such a URI is known as a <tref>WebID</tref>.
</dd>
<dt><tdef>WebID</tdef></dt>
<dd>A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent as the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document.</dd>
</dd>
-<dt><tdef>public key</tdef></dt>
+<dt><tdef>Public Key</tdef></dt>
<dd>A cryptographic key that can be published and can be used to verify the possession of a private key. A public
key is always included in a <tref>WebID Certificate</tref>.</dd>
-<dt><tdef>WebID Profile</tdef></dt>
+<dt><tdef>WebID Profile</tdef> or <tdef>Profile Page</tdef></dt>
<dd>
-A structured document containing credentials for
-<tref>Bob</tref> expressed using the Resource Description
-Framework [[RDF-CONCEPTS]]. Either the XHTML+RDFa 1.1 [[!XHTML-RDFA]]
-serialization format or the RDF/XML [[!RDF-SYNTAX-GRAMMAR]] serialization
-format MUST be supported by the mechanism, e.g. a Web Service, providing the
-WebID Profile document. Alternate RDF serialization
-formats, such as N3 [[!N3]] or Turtle [[!TURTLE]], MAY be supported by the
-mechanism providing the WebID Profile document.
-<p class="issue">Whether or not RDF/XML, XHTML+RDFa 1.1, both or neither
-serialization of RDF should be required serialization formats in the
-specification is currently under heavy debate.</p>
+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 Document in one of a number of formats.
+The Server MUST publish the document in at least the XHTML+RDFa 1.1 [[!XHTML-RDFA]] serialization format or in RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
+The document may be published in a number of other RDF serialization formats, such as N3 [[!N3]] or Turtle [[!TURTLE]].
+Any serialisation 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>
</dl>
-
-
</section>