Feat/access requests#46
Conversation
…ea in documentation
…related code) to OdrlController
…e selected controller in the store
| Future implementations should aim to make the swapping of controllers as easily configurable as possible. | ||
| A single `configuration` object that is tailored to the needs of each controller should be sufficient. | ||
| The current implementation simply passes the URL of the authorization server for the `ODRLController`. |
There was a problem hiding this comment.
Future work should actually have this discoverable.
In the sense that there should be a document tied to the identity of the user (speaking WebID terms, the WEbid Profile Document).
In that document the URLs of different authorization servers + mechanism should be elaborated (or the mechanisms of authorization should be mentioned through the /.well-known/ route.
| Please provide your own WebID for authorization: | ||
| What do you want to name your policy? | ||
| Please enter the URL to the resource: | ||
| Please provide the WebID for the assignee: | ||
| Enter actions to associate (comma separated). Options: read, write, append, create, control: read |
There was a problem hiding this comment.
could you fill in the variables from the policy to make it clear?
| for (const action of actions) { | ||
| const rule = getRandomName(); | ||
|
|
||
| rules.push(` | ||
| ex:${rule} a odrl:Permission ; | ||
| odrl:action odrl:${action} ; | ||
| odrl:target <${target}> ; | ||
| odrl:assignee <${assignee}> ; | ||
| odrl:assigner <${webid}> .`); | ||
|
|
||
| ruleRefs.push(`ex:${rule}`); | ||
| } | ||
|
|
||
| const body = ` | ||
| @prefix ex: <http://example.org/>. | ||
| @prefix odrl: <http://www.w3.org/ns/odrl/2/> . | ||
| @prefix dct: <http://purl.org/dc/terms/>. | ||
|
|
||
| ex:${policy} a odrl:Agreement ; | ||
| ${ruleRefs.map(r => `odrl:permission ${r} ;`).join("\n ")} | ||
| odrl:uid ex:${policy} . | ||
| ${rules.join("\n")} | ||
| `; |
There was a problem hiding this comment.
I think at this point, using N3 store and writer would make it easier than doing the manual writing of turtle.
Co-authored-by: Wout Slabbinck <wout.slabbinck@gmail.com>
Co-authored-by: Wout Slabbinck <wout.slabbinck@gmail.com>
Co-authored-by: Wout Slabbinck <wout.slabbinck@gmail.com>
|
|
||
| ## Use Case | ||
|
|
||
| We'll be looking into the use case of getting permission such that later we can access the resource using the UMA protocol. |
There was a problem hiding this comment.
| We'll be looking into the use case of getting permission such that later we can access the resource using the UMA protocol. | |
| We'll be looking into the use case of requesting access such that later we can access the resource using the UMA protocol. |
| We'll be looking into the use case of getting permission such that later we can access the resource using the UMA protocol. | ||
| This resource is managed by a Resource Server (RS). | ||
| The Resource Owner (RO) can alter the policies on their resources via the Authorization Server (AS). | ||
| The AS enforces the policies set by the RO when the RP interacts with the RS (possibly through a Client). |
There was a problem hiding this comment.
| The AS enforces the policies set by the RO when the RP interacts with the RS (possibly through a Client). | |
| The AS enforces the policies set by the RO when the RP interacts with the RS using a UMA compliant Client. |
woutslabbinck
left a comment
There was a problem hiding this comment.
I've added some extra comments to the documentation.
| <!-- TODO: this visualization is not completely correct and should be updated --> | ||
|
|
||
|  |
There was a problem hiding this comment.
Could you update the figure?
| This **PATCH** should include a body of format `application/sparql-update`, which uses a **DELETE/INSERT** statement to update the request's status to either `req:accepted` or `req:denied`. | ||
| In our use case, this message should look like this: |
There was a problem hiding this comment.
Highlight that these are the only triples that can be updated
|
|
||
| ## Data Space Contract Negotiation Protocol flow | ||
|
|
||
| This section explains the message flow for the second option: using the [Data Space Contract Negotiation Procotol](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-RC4/#negotiation-protocol). Important to note is that this document is not an official W3C Membership consensus. |
There was a problem hiding this comment.
| This section explains the message flow for the second option: using the [Data Space Contract Negotiation Procotol](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-RC4/#negotiation-protocol). Important to note is that this document is not an official W3C Membership consensus. | |
| This section explains the message flow for the second option: using the [Data Space Contract Negotiation Procotol](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-RC4/#negotiation-protocol) (DSCNP). Important to note is that this document is not an official W3C Membership consensus. |
No description provided.