updates following up on Kingsley's discussion. Improved clarity on how graphs cached and fetched from the web.
--- a/spec/index-respec.html Tue Jan 10 22:54:02 2012 +0100
+++ b/spec/index-respec.html Tue Jan 10 23:03:15 2012 +0100
@@ -850,13 +850,22 @@
However that is done, a <tref>Claimed WebID</tref> can only be considered verified if the following steps have been accomplished successfully:
</li>
<ol>
- <li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme.
- For an <code>https://...</code> WebID this would be done using the [[!HTTP-TLS]] protocol.
+ <li>The WebID Verifier must get access to an up to date version of the WebID Profile Graph.
+ <ol>
+ <li>If the WebID Verifier has an up to date version of the graph in its graph cache then it can return it.</li>
+ <li>Otherwise the <tref>WebID verifier</tref> MUST fetch an up to date version of the WebID Profile representation
+ 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 .
+ This graph may be then be cached to speed up future requests.
+ </li>
+ </ol>
</li>
- <li>The returned representation is then transformed into an RDF graph as specified in <a href="#processing-the-webid-profile">Processing the WebID Profile</a>
- </li>
- <li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>.
+ <li>The graph returned in the previous step is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>.
If the query is answered positively, then that WebID is verified.
+ If the query fails and the graph was not up to date, then the Verifier MAY start again at point 5.1.2 by making
+ a request to an up to date graph.
</li>
</ol>
<li>With the set of verified WebIDs the Guard can then check its access control rules using information from the web and other information available to it, to verify if the referent of the WebID is indeed allowed access to the protected resource.