|
1 | 1 | <p> |
2 | | - Access Requests and Grants provide a mechanism for an agent to request access to |
3 | | - resources and for a <a>resource manager</a> to grant access with defined constraints. |
| 2 | + Access Requests and Grants provide a mechanism for an <a>agent</a> to request access to |
| 3 | + resources and for a <a>storage controller</a> to grant access with defined constraints. |
4 | 4 | The endpoints for requesting and granting access act as a type of specialized inbox. |
5 | 5 | </p> |
6 | 6 |
|
7 | 7 | <p> |
8 | | - An agent does not present an <a>access grant</a> to a server as an authorization token. |
| 8 | + An <a>agent</a> does not present an <a>access grant</a> to a server as an authorization token. |
9 | 9 | Rather, the <a>access grant</a> serves as a record of what was authorized, to whom, |
10 | 10 | and under what constraints. When an <a>access grant</a> is created or revoked (deleted), it |
11 | 11 | is the responsibility of the server to adjust any underlying access policy to account for the |
|
26 | 26 |
|
27 | 27 | <ul> |
28 | 28 | <li> |
29 | | - <dfn>Access Request</dfn> — a data object submitted by an agent, expressing a |
| 29 | + <dfn>Access Request</dfn> — a data object submitted by an <a>agent</a>, expressing a |
30 | 30 | request to perform specific actions on storage resources, including the desired scope |
31 | 31 | and constraints. |
32 | 32 | </li> |
33 | 33 | <li> |
34 | | - <dfn>Access Grant</dfn> — a data object created by a storage controller, expressing |
35 | | - an ability for an agent to perform specific actions on storage resources within certain |
| 34 | + <dfn>Access Grant</dfn> — a data object created by a <a>storage controller</a>, expressing |
| 35 | + an ability for an <a>agent</a> to perform specific actions on <a>storage</a> resources within certain |
36 | 36 | defined constraints. |
37 | 37 | </li> |
38 | 38 | <li> |
39 | 39 | <dfn data-lt="access profiles">Access Profile</dfn> — an access profile describes the |
40 | 40 | requirements for expressing a valid access policy. Every access profile is identified |
41 | 41 | with a URI, and a server indicates support for one or more access profiles by |
42 | 42 | referencing them in the <code>conformsTo</code> property of a service object in its |
43 | | - Storage Description resource. |
| 43 | + <a>storage description</a> resource. |
44 | 44 | </li> |
45 | 45 | </ul> |
46 | 46 | </div> |
@@ -197,10 +197,10 @@ <h4>Types</h4> |
197 | 197 |
|
198 | 198 | <ul> |
199 | 199 | <li> |
200 | | - <code>AccessRequest</code> — a request by an agent for access to resources. |
| 200 | + <code>AccessRequest</code> — a request by an <a>agent</a> for access to resources. |
201 | 201 | </li> |
202 | 202 | <li> |
203 | | - <code>AccessGrant</code> — an authorization by a storage controller granting |
| 203 | + <code>AccessGrant</code> — an authorization by a <a>storage controller</a> granting |
204 | 204 | access to resources. |
205 | 205 | </li> |
206 | 206 | </ul> |
@@ -322,7 +322,7 @@ <h4>Types</h4> |
322 | 322 | <h4>Actions</h4> |
323 | 323 |
|
324 | 324 | <p> |
325 | | - The <code>action</code> property describes the operations that the agent wishes to |
| 325 | + The <code>action</code> property describes the <a>operations</a> that the <a>agent</a> wishes to |
326 | 326 | perform (in the case of a request) or is authorized to perform (in the case of a grant). |
327 | 327 | </p> |
328 | 328 |
|
@@ -430,7 +430,7 @@ <h4>Targets</h4> |
430 | 430 | </li> |
431 | 431 | <li> |
432 | 432 | <code>https://www.w3.org/ns/lws#StorageResource</code> — matches |
433 | | - any resource managed by a storage. |
| 433 | + any resource managed by a <a>storage</a>. |
434 | 434 | </li> |
435 | 435 | </ul> |
436 | 436 |
|
@@ -769,8 +769,8 @@ <h3>Protocol</h3> |
769 | 769 | </p> |
770 | 770 |
|
771 | 771 | <p> |
772 | | - An agent creates an <a>access request</a> by submitting a <code>POST</code> request to the |
773 | | - <a>access request</a> endpoint. A storage controller creates an <a>access grant</a> by |
| 772 | + An <a>agent</a> creates an <a>access request</a> by submitting a <code>POST</code> request to the |
| 773 | + <a>access request</a> endpoint. A <a>storage controller</a> creates an <a>access grant</a> by |
774 | 774 | submitting a <code>POST</code> request to the <a>access grant</a> endpoint. |
775 | 775 | </p> |
776 | 776 |
|
@@ -810,7 +810,7 @@ <h3>Notifications</h3> |
810 | 810 | </p> |
811 | 811 |
|
812 | 812 | <p> |
813 | | - Notifications provide a mechanism for informing agents and storage controllers about changes to |
| 813 | + Notifications provide a mechanism for informing <a>agents</a> and <a>storage controllers</a> about changes to |
814 | 814 | <a>access requests</a> and <a>access grants</a>. When an <code>inbox</code> property is |
815 | 815 | present on an <a>access request</a> or <a>access grant</a>, the server SHOULD deliver |
816 | 816 | notifications to that endpoint, informing an |
@@ -844,11 +844,11 @@ <h4>Notification Events</h4> |
844 | 844 | <ul> |
845 | 845 | <li> |
846 | 846 | <strong>Access Request creation</strong>: When a new <a>access request</a> is |
847 | | - submitted, the storage controller SHOULD be notified. |
| 847 | + submitted, the <a>storage controller</a> SHOULD be notified. |
848 | 848 | </li> |
849 | 849 | <li> |
850 | 850 | <strong>Access Grant creation</strong>: When a new <a>access grant</a> is created, |
851 | | - the requesting agent SHOULD be notified at the <code>inbox</code> specified in |
| 851 | + the requesting <a>agent</a> SHOULD be notified at the <code>inbox</code> specified in |
852 | 852 | the associated <a>access request</a>. |
853 | 853 | </li> |
854 | 854 | </ul> |
|
0 commit comments