You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit d053bdd
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: proposals/primer/authorization-agent.bs
+63-5Lines changed: 63 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,3 @@
1
-
2
1
<pre class='metadata'>
3
2
Title: Solid Application Interoperability - Authorization Agent Primer
4
3
Shortname: sai-authorization-agent-primer
@@ -14,7 +13,7 @@ Boilerplate: issues-index no
14
13
Local Boilerplate: logo yes
15
14
Markup Shorthands: markdown yes
16
15
Editor: elf Pavlik
17
-
!Version: 0.1
16
+
!Version: 0.2
18
17
Abstract: Primer for libraries intended to be used by authorization agents.
19
18
Boilerplate: omit conformance, omit abstract
20
19
</pre>
@@ -233,10 +232,14 @@ link to the user's messaging app. On the other side, the Authorization Agent of
233
232
Independent of the platform, Authorization Agents should always allow a simple copy of the link by the sender
234
233
(e.g., `navigator.clipboard.writeText`) and paste it by the recipient.
235
234
235
+
## Roles
236
+
237
+
[[SAI#role]] alows creating authorization can grant access to a team, a group of agents. Roles are only visible to to the agent who can access the Roles Registry and Authorization Registry. Roles can be also used to define a set of data owners, to whose data the authorization applies to. [[#generating-grants-from-authorizations]] describes that process in detail.
238
+
236
239
## Application Registration
237
240
238
241
Application Registrations are created by the End-user for applications they use.
239
-
Since applications do not own or share data, they will never have a [#reciprocal-registration].
242
+
Since applications do not own or share data, they will never have a [[#reciprocal-registration]].
<figcaption>Delegation request sent to Bob's Authorization Agent</figcaption>
397
+
</figure>
398
+
<figure>
399
+
<pre highlight=json>
400
+
[
401
+
"https://auth.bob.example/grants/9849ssd6",
402
+
"https://auth.bob.example/grants/sioa97dj"
403
+
]
404
+
</pre>
405
+
<figcaption>Delegation response received from Bob's Authorization Agent</figcaption>
406
+
</figure>
407
+
408
+
## Revoking Delegated Data Grants ## {#revoking-delegated-grants}
409
+
410
+
Agent who delegated the grant (`grantedBy`) can revoke them by simply making `DELETE` HTTP request targeting the URL that identifies a grant. Orphaned grant with `Inherited` scope provide no access and they should be revoked together with the parent grant. Agent who owns the data (`dataOwner`) can revoke delegated grants at any time, agent who delegates them (`grantedBy`) should have their Authorization Agent subscribed to notifications to remove links to revoked grants from agent registries (access grants).
411
+
353
412
<pre class="biblio">
354
413
{
355
414
"sai": {
@@ -386,8 +445,7 @@ Example of an implementation can be found in [[SAI-JS]] and [[SAI-JAVA]]
Copy file name to clipboardExpand all lines: proposals/specification/role.bs
+9-2Lines changed: 9 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -34,11 +34,18 @@ internal to the context of the [=Social Agent=] defining the Role.
34
34
</pre>
35
35
</figure>
36
36
37
-
When [=Authorization Agent=] generates [=Data Grants=] from a [=Data Authorization=]
38
-
* MUST generate a [=Data Grant=] for each member of that [=Role=] as `dataOwner` if a [=Role=] is used as `dataOwner`.
37
+
When [=Authorization Agent=] generates [=Data Grants=] from a [=Data Authorization=] it
38
+
* MUST generate a [=Data Grant=] for each member of that [=Role=] as `dataOwner` if a [=Role=] is used as `dataOwner`.
39
39
* MUST generate a [=Data Grant=] for each member of that [=Role=] as `grantee` if a [=Role=] is used as `grantee`.
40
40
* MUST generate a [=Data Grant=] for the cartesian product of the two [=Roles=], with each member as corresponding `dataOwner` or `grantee` if a [=Role=] is used as both `dataOwner` and `grantee`.
41
41
42
+
When a [=Role=] is modified, [=Authorization Agent=] managing it
43
+
* MUST generate corresponding [=Data Grants=], when a member is added to the [=Role=]
44
+
* MUST revoke corresponding [=Data Grants=], when a member is removed from the [=Role=]
45
+
* MUST revoke [=Data Authorizations=] where the role was used as a `dataOwner` or a `grantee`, when the [=Role=] is deleted.
46
+
47
+
Note: When [=Data Authorization=] is revoked, [=Data Grants=] that are derrived because of it also must be revoked.
48
+
42
49
## Role Registry ## {#datamodel-role-registry}
43
50
44
51
A <dfn>Role Registry</dfn> contains all the [=Roles=] defined by the [=Social Agent=] who owns the [=Role Registry=]
0 commit comments