This primer is intended to accompany [SAI]. It is focused on providing a friendly introduction for developers of libraries intended for solid applications.
This document was developed alongside the open-source TypeScript implementation [SAI-JS]
We will follow example of an application called Projectron, which manages projects and tasks. End user, named Alice, collaborates on projects with other Individuals and Organizations.
2. Shape Tree
Shape Trees [SHAPETREES] allow for the definition and validation of data hierarchies including which shapes [SHEX] should be used to validate data. In our examples, we are going to use the following Shapes and Shape Trees.
Reference shape path documentation
In this primer we will consider the use-case of a project management application
https://projectron.example/#app Every application has public WebID Document providing information about it.
Access Needs explain what kind of data application works with. They use combination of § 2 Shape Tree and access modes to convey how the application can work with data.
Details can change based on experience from implementing Authorization Agent role
4. Authorization Flow
User always needs to authenticate first. For the rest of this primer we’ll be assuming that user has already authenticated, and that applicaction know WebID of the authenticated user.
4.1. Authorization Agent Discovery
Every user has an Authorization Agent which can be discovered from
their WebID Document via
Here we see that Alice designates
https://auth.alice.example/ as their Authorization Agent.
4.2. Application Registration Discovery
Application can discover Application Registration created for it by the user,
GET request on IRI denoting
user’s Authorization Agent. Response will include HTTP Link header relating
Application Registration to the application making the request using
http://www.w3.org/ns/solid/interop#registeredAgent as link relation.
Details in 7. Data Authorization ([SAI])
4.3. User Consent
In cases where an application hasn’t been registered yet, it needs to initiate the flow with the Authorization Agent.
After successful flow, the application will be able to discover its registration.
|1||Alice finds an Application called Projectron that she’d like to use to manage her Projects and Tasks.|
|2||Alice authenticates to Projectron with her WebID.|
|3||Projectron dereferences her WebID and retrieves Authorization Agent from her WebID Profile Document.|
|4||Projectron asks Alice’s Authorization Agent whether Alice already has an Application Registration for Projectron.|
|5||Alice’s Authorization Agent checks the Agent Registry in Alice’s Pod for a Projectron Application Registration.|
|6||No Application Registration for Projectron is found. Projectron now knows that Alice hasn’t given it permission to access her data, so it must ask.|
|7||Projectron redirects Alice to her Authorization Agent, supplying its identifier for context.|
|8||Alice’s Authorization Agent dereferences the supplied Projectron identifier, retrieving Projectron’s
Application profile graph and corresponding Access Need Groups from the WebID Profile Document,
as well as |
|9||Alice’s Authorization Agent presents the Access Need Groups from Projectron’s Application profile graph, so that Alice understands what kind of data is being requested, and why.|
|10||Alice’s chooses the scope of access that Projectron will receive, to the data to which it has asked for access via the presented Access Needs.|
|11-13||Alice’s Authorization Agent records her decision as an Access Authorization in Alice’s Authorization Registry. An Application Registration is created for Projectron in Alice’s Agent Registry. An Access Grant and corresponding Data Grants are generated from the Access Authorization and stored in the Projectron Application Registration.|
|14||Alice’s Authorization Agent redirects her back to Projectron, now that the appropriate access has been granted.|
|15||Projectron again asks Alice’s Authorization Agent for a Projectron Application Registration.|
|16||Alice’s Authorization Agent finds the newly created Projectron Application Registration in the Agent Registry in Alice’s Pod.|
|17||Alice’s Authorization Agent provides the URI of the Application Registration to Projectron.|
|18||Projectron learns what access it received through the Access Grant in Alice’s Projectron Application Registration.|
|19||Projectron may now function as intended, within the scope of authorization it was given by Alice.|
4.4. Resource Indication
When the application has already been registered, and the user wants to initiate a sharing-specific § 6.1 Data Instance, an authorization flow with resource indication is available.
|1||Alice’s is authenticated with Projectron.|
|2||Alice has already authorized Projectron.|
|3||Projectron has read its Access Grant and displayed projects.|
|4||Alice initiates sharing of a specific project.|
|5||Projectron redirects Alice to her Authorization Agent, indicating the selected project.|
|6-8||Alice’s Authorization Agent fetches the indicated project and checks who already has access to it. It also fetches list of all registered social agents to present it to Alice.|
|9||Alice chooses all the social agents with which she wants to share the selected project, as well as modes of access for all selected agents. If the shape tree has references (e.g., tasks) she can also select modes of access for each inherited shape tree.|
|10-11||Alice’s Authorization Agent records new access authorizations for all the selected agents and regenerates access grants provided in their agent registrations.|
|12||Alice’s Authorization Agent dereferences the supplied Projectron WebID, retrieving Projection’s
Application profile graph from the WebID Profile Document,
to discover the |
|13||Alice’s Authorization Agent redirects her back to Projectron, now that the project has been shared.|
|14||Alice continues using Projectron.|
5. Application Registration
Application Registration can be considered an entry point to all the data
that the user authorized it to access. The next step in the discovery of that data
is the Access Grant linked via
5.1. Access Grant
Access Grant links to all the Data Grants issued to the application
5.2. Data Grant
Each Data grant represents access granted by specific Social Agent, to all or selected Data Instances in specific Data Registration.
A Data Grant is immutable, it never gets updated, instead it can be only replaced with a newer Data Grant.
Data Grant can be consider as the most important data structure, it provides following information:
Social Agent who owns the data
Shape Tree used by related Data Registration
Data Registration that this Data Grant applies to. As well as
iriPrefixof that Data Registration (see § 6 Data Registration)
List of access modes defining what application can do with the data
Defines which instances can be accessed (see § 5.2.1 Scopes)
If grant has
InheritInstancesscope, it will be the Data Grant for Data Registraion with parent Data Instances (see § 5.2.2 Inheritance)
If grant has
SelectedInstancesscope, it will be all the Data Instances that application can access in the Data Registration
If Data Grant is issued by Social Agent other than data owner, it will be the original Data Grant issued by the data owner (see § 5.2.3 Delegation)
Data Grant can have one of three scopes:
All the Data Instances in the Data Registration. Application will be able to access the Data Registration and see the list of all contained instances (see § 6 Data Registration)
Only specific Data Instances in the Data Registration. Application will not be able to access the Data Registration, so it will not see the list al all contained instances. Instad list of selected Data Instances is available via
Only those Data Instances in the Data Registration, which are related to parent kData Instances in Data Registration of the Data Grant referenced with
inheritsFromGrant(see § 5.2.2 Inheritance)
InheritInstances Data Grant doesn’t provide access to the Data Registration, so
application can’t get the list of all the Data Instances. Neither it provides a list of specific
Data Instances in the Data Registration.
To find Data Instances from that Data Registration, application first needs to access parent
Data Instances from Data Registration which Data Grant referenced by
inheritsFromGrant makes accessible. Based on shape tree definition, each parent Data Instance will reference all its
child Data Instances.
Both parent and child Data Registrations have to be in the same Data Registry. Since only one Data Registration for specific shape tree can be created in any given Data Registry. All parent Data Instances are from one Data Registration and all child Data Instances are from one Data Registration.
Application doesn’t need to handle delegated Data Grants in any special way.
To know if Data Grant was issued by currently logged in user or someone else,
application should rely on
dataOwner information in the Data Grant.
6. Data Registration
Shape Tree used by this Data Registration
String that should be used as base for creating IRIs for new Data Instances in this registration, by appending a unique string to the
6.1. Data Instance
Data Instances are domain specific data records. They don’t use
instead they use some domain specific vocabularies.
As we discussed in § 5.2.2 Inheritance a Shape Tree will specify how parent data instances
relate to child data instances. For Project shape three the predicate is
links to child Task data instances.
When creating or updating data instance with HTTP PUT method. Application should include
link header linking Data Instance to Data Registration using link relation
Update should include
If-Match HTTP header with value of ETag from
HTTP response when the representation was retreived.
When creating new data instance client should also include
If-None-Match: * header in HTTP request.