diff --git a/README.md b/README.md
index bf2253a..260dcf3 100644
--- a/README.md
+++ b/README.md
@@ -17,45 +17,20 @@ Now you can use your browser to see the PoC;
 * Start in the client on http://localhost:3001
 * You will be redirected to the auth server on http://localhost:3002
 * The auth server gets a standard OAuth request from one of its registered client, but without `requested_scope`
-* TODO: indicate explicitly at this point that scope is to be negotiated interactively
 * The user selects a scope selection server from a list. Unlike the auth server, these scope selection servers are tightly coupled to specific resource servers and their offerings.
 * The user's browser is redirected to the resource server (or more precisely, the scope selection server) on http://localhost:3003, at this point only with a randomly
 generated `ticket` which acts as a transaction identifier and a `redirect_uri` pointing the way back to the auth server.
-* TODO: rename `ticket` to `transaction`?
 * The user can provide credentials and interactively select the resource details to be offered in this transaction.
 * The user is redirected back to the auth server, with the transaction ID and in the query or fragment.
 * The auth server knows how to discover transaction details from the resource server, and does so.
 * The auth server displays human-readable info and allows the user to take a yes/no decision
 * The user is redirected back to the client's `redirect_uri` with a refresh token in the query string.
 * The client knows how to contact the auth server to exchange this refresh token for an access token
-* TODO: The client now needs to discover access instructions.
-  * OPTION 1: the client can ask the auth server for this
-  * OPTION 2: the client directly asks the resource server for this
-* TODO: should the transaction ID between client and auth server be different from the one between auth server and resources server?
-  * Pro: makes it easier since the client will eventually end up talking directly to the resource server anyway.
-  * Con: might leak some traceability of users across services
-  * Con: might make it harder if multiple resource servers are involved in a single transaction
-
-Client should maybe request types of resources it can handle
-It then gets the refresh token from the auth server and the API details from the resource server.
-
-Part 1: resource access description
-This is for client to deal with dynamic API discovery
-It can maybe be done together with OCM?
-In its basic form it's a WebDAV URL
-
-
-Part 2: resource selection
-Most of this can be done with tickets between auth server and resource server.
-Except that the auth server should have a way to retrieve human-readable transaction details.
-
-The resource scope description is what the resource server gives to the auth server, to help the decision
-The resource access description is what the resource server gives to the client, to help the access
-They describe the same resource so it makes sense to join them into one, right? That's also very SemWeb. :)
-The scope is identified by a dereferenceable URL
-
-
-
+* The client now needs to discover access instructions. The client directly asks the resource server for this
+### How is this different?
+* the client sends 'a-webdav-folder' as the scope, and gets back a URL for a structured scope
+* this scope was chosen by the user at the resource server's scope selection interface, the auth server doesn't understand it, except for the `humanReadable` field which it can display.
+* the client can deference the scope to discover the protocol version, resource URL, etc.
 
 ## JWT in ownCloud PoC
 ### Development
diff --git a/phase-2/poc/resource.js b/phase-2/poc/resource.js
index 660c8d8..5098c13 100644
--- a/phase-2/poc/resource.js
+++ b/phase-2/poc/resource.js
@@ -28,8 +28,7 @@ const data = {
     "protocols": {
         "webdav": {
             "url": "https://dav.rd123.surf.nl:4523/pietjepuk/files/photos/2023/January",
-            "protocol-version": "8.6n",
-            "token": "rtgrvsfgdrtewg3qd4g"
+            "protocol-version": "8.6n"
         }
     }
 };
@@ -44,7 +43,7 @@ http.createServer((req, res) => {
         res.end(dialogpart1 + query.state + dialogpart2 + query.state + dialogpart3);
     } else {
         res.writeHead(200, {'Content-Type': 'application/json'});
-        res.end(JSON.stringify(data));
+        res.end(JSON.stringify(data, null, 2));
     }
 }).listen(3003);
 console.log("Resource is running on port 3003");
\ No newline at end of file