Use Cases and Requirements for Authorization in Solid

Editor’s Draft,

This version:
https://solid.github.io/authorization-panel/authorization-ucr/
Issue Tracking:
GitHub
Editor:
Solid Editorial Team

Abstract

Use Cases and Requirements for Authorization in Solid.

Status of this document

1. Introduction

The § 2 Use Cases in this document represent real-world scenarios that a Solid authorization system should support. The § 3 Functional Requirements in this document are derived from those use cases, and will inform and guide the contents of a subsequent specification proposal.

2. Use Cases

Unless stated otherwise, the use cases herein assume that named individuals (e.g., Alice, Bob, Carol, etc.) are already authenticated agents, and their corresponding identities are known by the resource controller when they are granted access.

2.1. Resource access

Alice has a private draft of her resume stored on her resource server at https://alice.example/resume. Alice is the resource controller for that resource.

Alice’s resume and recommendations resources at https://alice.example
Resource Type Description
resume Resource Alice’s curriculum vitae
recommendations Resource Recommendations for Alice

2.1.1. Change permissions

Alice asks Bob to help make her resume more presentable. Alice must give Bob permission to do this, because resume is not a public resource, and as the resource controller Alice is the only one who can manage permissions for it.

2.1.2. Read permissions

Jasmine is a recruiter that has been helping Alice with job placement. Alice gives Jasmine the ability to read the permissions on resume, so that she can see who else Alice has shared her resume with.

2.1.3. Read-write access

Alice gives Bob read access so that he can read the resume resource, and write access so that he can make changes to it, which he does.

2.1.4. Read-append access

2.1.4.1. Alice stores Danielle’s recommendation

Danielle agrees to give Alice a personal reference, which Alice will include in the references section of resume. Alice gives Danielle read access to resume for context, and append access so that she can only add new data to resume, and cannot change any existing data within it. Danielle adds a glowing reference for Alice to resume.

2.1.4.2. Danielle stores their own recommendation

Danielle agrees to give Alice a personal reference, which Alice will link to in the reference section of resume. Alice gives Danielle read access to resume for context, and append access so that she can add a link to the recommendation that she creates and hosts on her own resource server at https://danielle.example/recommendation. Danielle is the resource controller for that resource and gives it public read access.

2.1.5. Append-only access

Alice is interested in seeing whether any of her other contacts might provide good recommendations that she can include as additional references or a resume cover letter.

She creates a recommendations resource, and grants append access to the contacts authorization group, which represents every professional contact in her virtual rolodex. She sends a mass-mail to contacts, with a link to an app they can use to submit a recommendation, which will be appended to recommendations. Since they only have append access and not read access, they can add to recommendations but they cannot see recommendations that have already been added.

2.1.6. Removing access

Alice removes Bob and Danielle’s access to resume, since they’ve both finished contributing to it. They can no longer read or make changes to it.

2.1.7. Read-only access

Alice has a job interview with Carol. Alice gives Carol read access to resume ahead of the interview.

2.1.8. Group access

Alice has additional interest, and is now interviewing with people from multiple organizations, including Carol, Oscar, and Frank.

To make it easier to keep track of everyone, Alice creates an interviewing authorization group and adds Carol, Oscar, and Frank to it. She grants read access on resume to the interviewing authorization group.

Alice removes any individual permissions on resume that were granted to members of the interviewing authorization group since they are no longer necessary.

Now Alice can add new people she’s interviewing with to the interviewing authorization group, and remove them when the opportunity is no longer active. This is much more intuitive and easy for Alice.

2.1.9. Public access

Alice decides resume is ready to share with everyone, so she gives read access to the public (everyone), and shares a link to it on several job boards.

2.1.10. Logged in access

Alice runs an open online workshop for a few people she works with but also she sends an invitation to a public mailing list suggesting experts in her field should also come.

She sets the access to the materials so that anyone who has a solid ID can log in and access it. (They have read access to the agenda, and write access to the minutes, say).

She uses an app which accumulates the set of Ids of the people who have used this access as a group.

People who follow her link to the materials are prompted by the system to log in, or if necessary to make a new solid account and then log in.

After the workshop is over, she changes the access on the materials to explicitly be that group.

2.2. Collection access

Note: These use cases are focused on access to a collection itself. Use cases that focus on permissions related to resources included in that collection are covered in § 2.3 Collection resource inherited access.

Alice has a portfolio collection stored on her resource server at https://alice.example/portfolio/, which she is the resource controller for. She provides access to the portfolio to potential employers as she moves through a job interview process.

The portfolio collection includes resources representing individual deliverables she’s produced throughout her career, along with collections of deliverables from larger scale projects that she’s worked on.

The portfolio resource itself includes summary information about the portfolio as a whole. For example, Alice details why she chose to include the items together as a representation of her work.

Alice’s portfolio and opportunities collections at https://alice.example/
Resource Type Description
portfolio/ Collection Resource includes summary information about the portfolio as a whole. Member resources include individual documents she’s produced, and collections of deliverables from projects she’s worked on.
-- document1 Resource Individual document
-- document2 Resource Individual document
-- project1/ Collection Individual document
---- documentA Resource Project document
---- MovieA Resource Project movie file
opportunities/ Collection Storage for descriptions of various different job opportunities Alice is interested in
comments/ Collection Storage of comments on Alice’s portfolio

2.2.1. Read-only access to a Collection

Alice has identified several companies that she’d like to work for, as well as the specific people (Carol, Oscar, and Frank) to contact at each one.

Alice sends individual e-mails to Carol, Oscar, and Frank with links to her resume and portfolio.

Alice has granted Carol, Oscar, and Frank read access to her resume which allows them to read its contents fully.

Alice has also granted them read access to the portfolio collection. She only wants them to see summary detail about the portfolio collection itself, along with a listing of its contents, but not the contents of the resources included in that collection.

Alice wants to know which of them are really interested based on who asks her for more access to the contents of the resources in portfolio.

2.2.2. Read-write access to a Collection

Alice is revising the summary description of her portfolio, which is stored in the resource for the portfolio collection.

Milo is Alice’s friend, and she enlists his help in reviewing and revising her summary.

Alice gives Milo read access and write access to the portfolio collection itself, which allows him read and modify the existing summary in the portfolio resource.

2.2.3. Read-create access to a Collection

Alice worked with Bob on a past project, and she has added a partial set of the final project deliverables to the project1 collection. She knows that Bob has the rest, and he agrees to provide them.

Alice grants Bob the following access on the project1 collection:

2.2.4. Read-create-delete access to a Collection

Note: Despite this section’s focus on permissions specific to the collection resource itself, this use case also incorporates inherited read access to better illustrate the scenario.

Over time Alice has asked her colleagues to leave comments on her portfolio, which are stored in the comments collection.

When she asks a colleague to leave a comment, she gives them the following permissions:

2.2.5. Create-only access to a Collection

Alice realizes it would be helpful if Carol, Oscar, and Frank could provide her with job opportunities that they think she would be a fit for at their respective organizations.

She provides them with create access to the opportunities collection. This allows each of them to add new resources to opportunities, without the ability to see the listing of other resources in the collection, or modify them. This means that they can each add opportunities, but none of the others will see them.

2.2.6. Manage permissions for a Collection

Bob reminds Alice that some of the other people who worked on project1 may also have materials they can add to the portfolio, but he needs to lookup their information.

Alice trusts Bob with the contents of the project1 collection, since it’s the output of their shared work. She gives him read permission access and write permission access to project1 so that he can help her invite other colleagues from the past to add resources to it.

2.3. Collection resource inherited access

Bob is leading a group of colleagues doing field research. This group includes Charles, Felicia, Juan, and Irene.

The group uses a resource server for storing their information at https://research.example/, which Bob administers as the resource controller.

Bob creates an authorization group called research, and adds Charles, Felicia, Juan, and Irene to it.

Contents of the research group’s data store at https://research.example/
Resource Type Description
weekly-status/ Collection Bob’s notes from weekly status meetings with colleagues
-- 12-23-2019.note Collection Text stored in collection resource, subordinate data and media included in collection
---- recording.mp4 Video Recorded audio/video of web conference meeting
-- 12-30-2019.note Collection Text stored in collection resource, subordinate data and media included in collection
---- img1.png Image Inline picture included in text of note
---- img2.png Image Inline picture included in text of note
---- recording.mp4 Video Recorded audio/video of web conference meeting
-- 01-06-2020.note Collection Text stored in collection resource, subordinate data and media included in collection
---- recording.mp4 Video Recorded audio/video of web conference meeting
daily-metrics/ Collection Daily device reading for group research
-- Jan-01-2020 Resource Daily reading
-- Jan-02-2020 Resource Daily reading
-- Jan-03-2020 Resource Daily reading
-- Jan-04-2020 Resource Daily reading
-- Jan-05-2020 Resource Daily reading
-- Jan-06-2020 Resource Daily reading
-- Jan-07-2020 Resource Daily reading
daily-summaries/ Collection Daily analysis for group research
-- Jan-01-2020 Resource Peer reviewed analysis for Jan 1
-- Jan-02-2020 Resource Peer reviewed analysis for Jan 2
-- Jan-03-2020 Resource Peer reviewed analysis for Jan 3

2.3.1. Read-only access to collection resources

Bob has a weekly status meeting with the members of the research authorization group.

Bob is a diligent notetaker, which his colleagues appreciate. He’s happy to act as the scribe and post notes after the meeting for sharing with his colleagues. However, he doesn’t want the overhead of granting them permissions every week to each newly created note.

Bob stores his notes from the weekly status meeting in the weekly-status collection.

He grants the research authorization group read access to the weekly-status collection, which means they can read specific details about the collection and see a listing of the resources included in it (e.g., Bob’s notes). He also grants them inherited read access to the members of the collection, which allows them to read the contents of each note.

This is especially important because in this case each of Bob’s notes are actually a collection themselves, capable of storing inline data or attachments, like pictures or videos.

Because Bob sets inherited read access at the weekly-status collection, it applies to all of the members already in the collection, as well as any that are added in the future.

2.3.2. Read-create access to collection resources

Every day, someone in the group is responsible for recording data from devices in the field, and storing those metrics in daily-metrics.

Bob sets the following permissions on the daily-metrics collection for the research authorization group:

2.3.3. Manage a hierarchy of collection resources

The members of the research authorization group collaborate on a daily summary, where they analyze the day’s field readings stored in daily-summaries, detailing any new, validated, or invalidated hypotheses.

Bob sets the following permissions on the daily-summaries collection for the research authorization group:

2.3.4. Create-append access to collection resources

Bob purchases a new field device that is able to automatically push daily metric readings in daily-metrics.

Bob gives the new field device the following permissions on the daily-metrics collection:

2.3.5. Manage permissions for collection resources

Bob realizes that he needs some help administering https://research.example. He provides Carol with the following permissions on the https://research.example collection:

2.3.6. Default permissions on created resources

Bob is granting inherited permissions to the research authorization group at the collection level for daily-summaries and daily-metrics that include the ability to add resources (write access / append access).

It’s important that the resources they create have the correct permissions assigned automatically, and he needs to be able to ensure this when he sets up their access. Otherwise, how can he be sure that the files aren’t created with access that is too liberal (e.g., public access), or too narrow to be usable within their context?

Bob prefers to specify in granular fashion the default permissions of created resources that should be assigned to any authorizations with write access or append access on a given collection.

2.3.7. Default permissions for extended network

Alice has a blog and allows comments on her posts. Ideally, everyone’s comments would be immediately visible, but she has previously been overwhelmed by spammers. So now she would like to try a compromise: allow the posts from her extended social network (friend of her friends, colleagues and family) to be immediately visible. Other posts should only be visible and editable to those who wrote them. They can then be viewable to the world when they get reviewed.

2.3.8. Adding new subjects to inherited permissions

Note: Adding a new subject means we are adding a new agent, authorization group, and/or application to the collection that isn’t already part of an inherited authorization. Modifying permissions for those that exist in inherited authorizations is covered in § 2.3.9 Modifying inherited permissions for existing subjects.

Bob has given the research authorization group inherited read access to the weekly-status collection (detailed in § 2.3.1 Read-only access to collection resources).

Celeste isn’t a regular member of the research authorization group, but happened to attend the weekly status meeting on December 30th, 2019.

Bob would like to give Celeste read access to only the note for the meeting she attended (12-30-2019.note), without affecting the access that he’s given to the research authorization group. research has inherited read access on everything in the weekly-status collection, and anything that is added to it.

Effective access to 12-30-2019.note should be that Celeste and the members of the research authorization group have inherited read access. Celeste has no other access to other resources in the weekly-status collection, nor any that will be created later. The access for the research authorization group doesn’t change.

2.3.9. Modifying inherited permissions for existing subjects

On the January 6th weekly status meeting, Bob and the research authorization group covered a research topic related to a commercial endeavor that Felicia is involved in. When Felicia saw this on the agenda, she informed Bob that it would be a conflict of interest for her to participate in the discussion.

To ensure that there would be no semblance of conflict or impropriety, Bob and Felicia agreed that he would remove her access to the meeting note for that session - 01-06-2020.note, which is included in the weekly-status collection.

Effective access to 01-06-2020.note then becomes the inherited read access to the research authorization group (which Felicia is part of), minus Felicia.

Felicia continues to have inherited read access to all other existing resources included in the weekly-status collection, and any new resources added to it. Inherited read access for others in the research authorization group is unchanged.

2.3.10. Forcing inherited permissions

As the primary administrator and resource controller of https://resource.example, Bob wants to ensure that he maintains ultimate control over the data inside.

Even though he’s given Carol permission to help him administer the resource server, he wants to ensure that she’s not able to cut out his access. He wants to always maintain a minimum of read access, read permission access, and write permission access to all of the resources in https://resource.example. This allows him to have visibility into everything, and change their permissions as needed.

2.4. Conditional access

Felicia works for an organization that conducts clinical trials, and leads a team that processes and synthesizes incoming data from trial participants, including participants in the Acme trial.

The organization uses a resource server at https://trials.example as a data repository for all of their clinical trial data. Felicia is the resource controller of https://trials.example, managing authorized access to it for her colleagues, and a group of research interns.

Contents of /measurements collection
Resource Type Description
/measurements/ Collection Measurements for all trial participants across all trials
-- meas-123-03052020 Resource Individual measurement
-- meas-431-03052020 Resource Individual measurement
-- meas-974-03052020 Resource Individual measurement
-- meas-153-03052020 Resource Individual measurement
-- meas-755-03052020 Resource Individual measurement
-- meas-644-03052020 Resource Individual measurement
-- meas-031-03052020 Resource Individual measurement
-- meas-858-03052020 Resource Individual measurement
-- ... - Collection includes thousands of measurements
/reports/ Collection Reports prepared for senior team members
-- report-1 Resource Individual report prepared for senior team members

2.4.1. Conditional access by time

Erin is a research intern that will be assisting Felicia’s team in processing and synthesizing data for the Acme trial. She will remain on the team until the end of her current academic term on June 30th, 2020.

The measurements collection contains measurements for all trial participants, across all trials.

Felicia has granted Erin read access to the measurements collection, and inherited read access and write access to the resources in the measurements collection. Felicia adds a time-based condition for Erin which states that this access is only valid through June 30th, 2020.

Erin will have no access to measurements after June 30th, 2020.

2.4.2. Conditional access by tag

As a research intern, Erin is responsible for processing all unprocessed measurements for the Acme trial in measurements. However, there are measurements for other trials in the measurements collection, as well as measurements that have already been processed.

Felicia authorizes Erin to have read access to the measurements collection, and inherited read access and write access to measurements, with a condition that the resources must:

This allows Erin to work with new measurements for the Acme trial without being exposed to measurements from other trials, or already processed measurements from the Acme trial.

2.4.3. Conditional access by relationship

Felicia is responsible for preparing and sharing internal reports for senior research team members. These reports include direct links to source data, including individual measurement resources in the measurements collection.

Senior research team members do not have regular access to measurements. They only access individual resources in measurements that are linked through these reports. Each report only links to a small subset of individual measurements. Reports are often amended to reference additional measurements over time.

When Felicia prepares a new report /reports/report-1, she authorizes only the senior research team members receiving the report to have inherited read access to resources in measurements, with a condition that a given measurement must be related to /reports/report-1 by an ex:hasMeasurement predicate for that access to be permitted.

This ensures that the senior research team members will be able to read measurements referenced by /reports/report-1, or any references added to it later, but no others.

There may be different ways to describe the relationships which propagate access rules, for example:

2.4.4. Conditional access by filter

Felicia has been able to limit the scope of the resources that Erin can access to unprocessed entries for the Acme trial, which is all that she needs to perform her duties. However, each measurement resource also contains personally identifiable information (PII) for the trial participant associated with the measurement. Felicia needs to ensure that Erin cannot access that PII.

Felicia authorizes Erin to access a reduced set of fields within the measurement resources. When Erin retrieves a measurement, the response will exclude the fields containing PII.

2.4.5. Conditional control boundaries

Megan works on Felicia’s team. Felicia would like Megan to be responsible for managing access to trial data for the research interns assigned to the Acme project. Felicia doesn’t want to give Megan more permission than she needs to do that work.

Felicia grants Megan inherited read permission access and write permission access to measurements, with conditions that stipulate:

2.4.6. Conditional access by action

The University has a widely used blog for discussion with research teams across the world. Researchers who post comments often want to correct errors after publication. But this feature can lead to misunderstandings if edited after someone else has commented on the comment. They institute the following policy: their authors can edit comments for a minimum of 5 minutes and only until these are themselves commented. After that point, the post will be in read-only access mode.

2.4.7. Conditional access by payment

A musician would like to self publish her music to take advantage of a Solid music App. She does this by making the song metadata available openly so that fans can follow her new releases, specialised music search engines can index it, and music apps can display the song’s metadata in their users' preferred language. To earn a living, she sets an access control rule on the resource, allowing access on proof of payment. Payment methods need to be flexible and allow for smooth integration with any music app, even enabling automatic payment for small enough sums. Users of the Solid Music App would thus have one more song to choose from amongst the large number made available by musicians worldwide.

2.5. Permissioning Applications

2.5.1. Limiting access to trusted applications

Oscar stores all of his data in a private resource server at https://oscar.example, where he is the resource controller.

He stores a wide spectrum of things, from personal financial data to collaborative projects that he works on with his friends and colleagues.

As the resource controller for https://oscar.example, any application that operates with or on behalf of Oscar’s identity would operate with the same unfettered access that Oscar enjoys.

It is important to Oscar that he can include applications in his authorizations to limit this unfettered access.

For example, to constrain Oscar’s access to https://oscar.example to only cases where an application he trusts is involved:

Following that, per § 2.3.9 Modifying inherited permissions for existing subjects, he could extend this default for the health collection to include healthapp:

2.5.2. Limiting application access while not acting as resource controller

Alice uses application PerformChart to visualize her work performance across various projects. She works on projects across various organizations, including ACME and Omni. While she has controller access to some of the projects, she also has read-write access to many other projects. Since PerformChart only provides analysis and visualization it doesn’t need any write access. Alice grants PerformChart read only access to all the projects that she can access.

2.5.3. Application determining access privileges

Guinan uses an application to author and publish documents. The application adapts its user interface to distinguish between allowed (actionable) and disallowed features based on access information that the resource server reveals, for example, permissions that are granted to the application, to the public (everyone), or to a group.

For example, for user level permission, if the application is not granted write access on the resource that Guinan is currently editing, the user interface can disable the "Save" button in the menu. Guinan also wants to know if the public is granted read access on the content they are updating, and thus if it can be, for example, liked, bookmarked, archived by everyone.

2.6. Privacy

2.6.1. Limiting access to who else is permitted

Alice is interviewing for a job with Carol. Alice is also interviewing for a job with Oscar, Carol’s direct competitor.

Alice has given Carol and Oscar read access to her resume.

Neither Carol or Oscar would appreciate knowing that Alice is interviewing with both of them, so it’s important neither Carol or Oscar know who else Alice has shared her resume with, despite having read access to it.

2.6.2. Limiting access to other authorization conditions

As an extension of § 2.6.1 Limiting access to who else is permitted, it is also important to Alice that that neither Carol nor Oscar be able to discern other characteristics of the authorizations or conditions associated with Alice’s resume.

For example, if the data Carol and Oscar saw in the resume was filtered to only show a certain subset of her background, she wouldn’t want them to know that they were only seeing a filtered view.

2.6.3. Minimal Credential Disclosure

Following a link on a blog post, Alice comes to a resource that requires authentication. She could present one of many verifiable credentials (as per § 2.9.2 Possession of a verifiable credential): three self-signed WebID credentials, four bank accounts, a drivers licence, two passports, a proof that she is over 18, a credential for her college and her university diploma, three club memberships as well as her FBI credential. The resource only requires proof of being over 18. Her client’s credential manager should see this and select the credential revealing the least amount of information needed to access the resource.

2.6.4. Limit information disclosure through URI

A service with very high security and confidentiality requirements must publish resources without the URL for any resource leaking information about it’s content. This service publishes all these resources using the Tor protocol, so that the location of the servers can remain secret. All resources on this Solid server are named by the root container using a UUID naming scheme.

Contents under https://ciadotgov4sjwlzihbbgxnqg3xiyrg7so2r2o3lt5wz5ypk4sxyjstad.onion/
Resource Type Description
4fcffa1b-3cc2-4ace-be65-2b0cf8045550 Collection Collection for online meeting on 24 July 2025
aa91d049-9997-48c8-b115-2217c3c9c0d5 Resource Agent Alice’s notes for the meeting stored in above collection
6b063d07-9f25-4692-ba3d-dff02f200028 Video Recorded audio/video of web conference meeting stored in above collection
4376ed72-37d8-4432-8dce-7a796f4bdd66 Collection Collection for 14 September 2025 online meeting
796d8d67-3e88-483f-b1c1-d4eba63827e3 Video Recorded audio/video of web conference meeting
b7123ed7-3861-4b37-9b53-cf9bd730fafe Collection Subcollection of 14 Sept Collection for data dumps
2d97f889-8f7d-43fb-83f8-1437b05896ba Resource Agent Smith’s data stored in in b7123ed7-3861-4b37-9b53-cf9bd730fafe collection
17a63d0f-b99f-4268-929d-5a5fe5f5dd56 Resource Agent Alice’s data stored in the same Collection as Agent Smith’s

Some of the UUID resources represent collections and others various types of content. Collections can contain other collections as usual, but this cannot be deduced from the name. Only clients that are authorized can tell from the returned descriptions what the type of the resource is or what a container contains.

The service would like to be able to use the same applications on those resources as it does on its public facing Solid Web site, where it uses humanly readable and memorable names for its resources.

2.7. Trust

2.7.1. Only trust certain issuers of identity

Carol has a blog, and allows any authenticated agent (e.g., [WEBID], [DID]) to comment on her blog posts.

Unfortunately, anyone can setup an identity provider, so Carol would like to be able to recognize credentials issued from trustworthy identity providers.

2.7.2. Block access to agents

A nonpartisan group provides a public annotation service, and allows any authenticated agent to share fact-checked information.

Unfortunately, there are bad actors that seek to expose misinformation and disinformation through the annotation service. The trusted moderators of the service would like to be able to block bad actors from sharing content in the future.

2.8. Validation

Juan likes to manage his authorizations manually. Every once in a while, Juan makes a typo, or accidentally saves the authorization in an incomplete state.

Juan runs into trouble on systems where the authorization system implementation doesn’t properly validate, most often resulting in Juan getting locked out of the resource and needing administrator assistance to recover.

2.9. Capabilities

2.9.1. Possession of a group membership verifiable credential

Omni Corp granted Acme Corp read-write access to three of their projects: A, B, and C. This grant allows all Acme Corp employees to have that access as long as they can present a membership credential issued by Acme Corp. At the time of the grant, Omni Corp notifies Acme Corp, detailing pertinent access details, including the membership credential requirement for Acme Corp employees. Acme Corp doesn’t maintain a public list of their employees, so Omni Corp cannot know who is employed by Acme Corp unless that person presents a verifiable credential. Alice works for Acme Corp, and can now access the Omni Corp projects A, B, and C, using her membership credential issued by Acme Corp.

2.9.2. Possession of a verifiable credential

Oscar has a medical condition that causes random and very serious seizures several times per year. Wherever Oscar is, he needs to be rushed immediately to the closest hospital in an ambulance.

Oscar’s government has recently rolled out a digital credential system for health care professionals, which is like a digital id card for doctors and care facilities that can be cryptographically verified.

Oscar has an emergency care record at https://oscar.example/emergency, and Oscar’s authorization system at https://oscar.example supports a verifiable credential capability.

Oscar has set permissions on https://oscar.example/emergency that grants someone in possession of a verifiable medical credential to have inherited read access to the contents. This gives them just enough background on his condition to treat him properly.

Bob is about to give a confidential presentation to a group of his colleagues. His presentation is stored on his personal resource server at https://bob.example/presentation.

Bob is having trouble hooking his laptop up to the projector, and needs to present in just a few minutes. Anne presented before Bob, and offers to bring the presentation up for him on her system.

Unfortunately, Anne doesn’t have an identity ready to go that he can authorize. Luckily, his authorization system supports a link-based capability.

Bob quickly creates an authorization for https://bob.example/presentation that allows anyone in possession of a specially generated link to access the document with read access. He sets it to expire in three hours. Bob gives the link to Anne and the presentation goes off perfectly.

3. Functional Requirements

Note: Unless otherwise specified, allowing or limiting access in the subsequent requirements should be interpreted in the context of allowing or limiting access to a resource or collection by an agent.

3.1. Access by subject

3.1.1. The system shall allow access to be limited based on the identity of the agent.

Related use cases: § 2.1 Resource access, § 2.2 Collection access

3.1.2. The system shall allow access to be limited based on the identity of the agent, only when that identity is issued by a trusted identity provider.

Related use cases: § 2.7.1 Only trust certain issuers of identity

3.1.3. The system shall allow access to be limited to an agent based on the agent’s membership in a certain group of agents.

Related use cases: § 2.1.8 Group access

3.1.4. The system shall allow access to be limited to an agent based on the client application in use by the agent.

Related use cases: § 2.5.1 Limiting access to trusted applications

3.1.5. The system shall allow an agent to limit modes and/or conditions of access for a given client application in their use for a resource or collection that they have been granted access to.

Related use cases: § 2.5.2 Limiting application access while not acting as resource controller

3.1.6. The system shall allow access to be permitted for any unauthenticated or authenticated agent.

Related use cases: § 2.1.9 Public access

3.1.7. The system shall allow access to be limited to any authenticated agent.

Related use cases: § 2.1.10 Logged in access

3.2. Access by capability

3.2.1. The system shall allow access to be limited to an agent based on the agent’s possession of a certain verifiable credential or capability.

Related use cases: § 2.9.2 Possession of a verifiable credential, § 2.9.3 Possession of a link, § 2.6.3 Minimal Credential Disclosure

3.2.2. The system shall ensure that there are practical and efficient mechanisms available for the client to determine an appropriate credential to present for access to a given resource.

Related use cases: § 2.9.2 Possession of a verifiable credential, § 2.6.3 Minimal Credential Disclosure, § 2.4.7 Conditional access by payment

3.3. Access to resources

3.3.1. The system shall allow the ability to read the access permissions associated with a certain resource to be limited.

Related use cases: § 2.1.2 Read permissions, § 2.6.1 Limiting access to who else is permitted, § 2.6.2 Limiting access to other authorization conditions

3.3.2. The system shall allow the ability to change the access permissions associated with a certain resource to be limited.

Related use cases: § 2.1.1 Change permissions

3.3.3. The system shall provide the effective access permissions on a certain resource or collection as they relate to the agent making the request, in the request response.

Related use cases: § 2.5.3 Application determining access privileges

3.3.4. The system shall allow the ability to read a certain resource to be limited.

Related use cases: § 2.1.7 Read-only access, § 2.1.3 Read-write access, § 2.1.4 Read-append access

3.3.5. The system shall allow the ability to change any of the existing contents of a certain resource to be limited.

Related use cases: § 2.1.3 Read-write access

3.3.6. The system shall allow the ability to change existing data in a certain resource to be limited, such that only new data can be added to it.

Related use cases: § 2.1.5 Append-only access, § 2.1.4 Read-append access

3.3.7. The system shall limit the ability to delete a certain resource.

Related use cases: § 2.2.4 Read-create-delete access to a Collection

3.3.8. The system shall allow for access to a resource or collection to be limited to the agent that created it.

Related use cases: § 2.2.4 Read-create-delete access to a Collection

3.3.9. The system shall not rely on the URI structure to infer semantics about the type of resources.

Related use cases: § 2.6.4 Limit information disclosure through URI

3.4. Access to collections

3.4.1. The system shall allow the ability to read a certain collection to be limited, exposing only the data from the collection resource itself, and a listing of its members, and excluding the contents of its members, or any metadata about them.

Related use cases: § 2.2.1 Read-only access to a Collection, § 2.2.2 Read-write access to a Collection, § 2.2.3 Read-create access to a Collection, § 2.2.4 Read-create-delete access to a Collection

3.4.2. The system shall allow the ability to change data specific to a certain collection to be limited, including only the data from the collection resource itself, and excluding any additions or subtractions from its list of members.

Related use cases: § 2.2.2 Read-write access to a Collection

3.4.3. The system shall allow the ability to create a resource in a certain collection to be limited.

Related use cases: § 2.2.2 Read-write access to a Collection, § 2.2.3 Read-create access to a Collection, § 2.2.4 Read-create-delete access to a Collection, § 2.2.5 Create-only access to a Collection

3.4.4. The system shall limit the ability to delete a resource in a certain collection.

Related use cases: § 2.2.4 Read-create-delete access to a Collection

3.4.5. The system shall allow for the creator of a resource in a certain collection to be automatically granted access to the created resource.

Related use cases: § 2.2.4 Read-create-delete access to a Collection

3.4.6. The system shall allow the ability to read the access permissions associated with a certain collection to be limited.

Related use cases: § 2.2.6 Manage permissions for a Collection, § 2.6.1 Limiting access to who else is permitted, § 2.6.2 Limiting access to other authorization conditions

3.4.7. The system shall allow the ability to change the access permissions directly associated with a certain collection to be limited.

Related use cases: § 2.2.6 Manage permissions for a Collection

3.5. Inherited access to collection resources

3.5.1. The system shall allow for a certain collection to specify access permissions that are inherited by its members.

Related use cases: § 2.3 Collection resource inherited access

3.5.2. The system shall allow for a certain resource to be read if the agent has inherited read access from the parent collection the resource is a member of.

Related use cases: § 2.3.1 Read-only access to collection resources

3.5.3. The system shall allow for a resource to be changed if the agent has inherited write access from the parent collection the resource is a member of.

Related use cases: § 2.3.3 Manage a hierarchy of collection resources

3.5.4. The system shall allow for new data to be added to a resource, without being able to change existing data in that resource, if the agent has inherited append access from the parent collection the resource is a member of.

Related use cases: § 2.3.4 Create-append access to collection resources

3.5.5. The system shall allow for new resources to be added to a given collection if the agent has inherited create access from the parent collection that the given collection is a member of.

Related use cases: § 2.3.2 Read-create access to collection resources

3.5.6. The system shall allow for resources to be deleted from a given collection if the agent has inherited delete access from the parent collection that the given collection is a member of.

Related use cases: § 2.2.4 Read-create-delete access to a Collection

3.5.7. The system shall allow for the members of a certain collection to extend or augment the permissions inherited from the parent collection.

Related use cases: § 2.3.8 Adding new subjects to inherited permissions, § 2.3.9 Modifying inherited permissions for existing subjects

3.5.8. The system shall allow for a certain collection to specify access permissions that are inherited by its members and cannot be augmented.

Related use cases: § 2.3.10 Forcing inherited permissions

3.5.9. The system shall allow for the default permissions of a newly created resource to be inherited from the parent collection the resource is a member of.

Related use cases: § 2.3.6 Default permissions on created resources, § 2.3.7 Default permissions for extended network

3.5.10. The system shall allow for the access permissions directly associated with a certain resource to be read if the agent has inherited read permission access from the parent collection the resource is a member of.

Related use cases: § 2.3.5 Manage permissions for collection resources

3.5.11. The system shall allow for the access permissions directly associated with a certain resource to be changed if the agent has inherited write permission access from the parent collection the resource is a member of.

Related use cases: § 2.3.5 Manage permissions for collection resources

3.6. Conditional access

3.6.1. The system shall allow the ability to limit access to a certain resource by a given start and/or end date and time.

Related use cases: § 2.4.1 Conditional access by time

3.6.2. The system shall allow the ability to limit access to a certain resource by a tag associated with that resource.

Related use cases: § 2.4.2 Conditional access by tag

3.6.3. The system shall allow the ability to limit access to a certain resource based on the existence of a specific relationship with another resource.

Related use cases: § 2.4.3 Conditional access by relationship, § 2.3.7 Default permissions for extended network

3.6.4. The system shall allow access to be limited to only a subset of data in a certain resource based on supplied filter criteria.

Related use cases: § 2.4.4 Conditional access by filter

3.6.5. The system shall allow the access modes and/or conditions of a given access permission for a certain resource or collection to change after other specified conditions have been satisfied.

Related use cases: § 2.4.6 Conditional access by action

3.6.6. The system shall allow the ability to read, create, or change only those access permissions for a given resource or collection that apply to a specified group of agents to be limited.

Related use cases: § 2.4.5 Conditional control boundaries

3.6.7. The system shall allow the ability to read, create, or change access permissions for resources associated with a particular tag to be limited.

Related use cases: § 2.4.5 Conditional control boundaries

4. Definitions

All definitions as stated below should be considered in the context of an authorization system in Solid, whether explicitly stated or not.

An agent is a distinct individual, group, organization, or piece of software with an identity that can be strongly authenticated.

An identity is used to uniquely identify a given agent, represented by a unique [URI]. Examples of compatible identity systems include [WEBID] and [DID].

An authenticated agent is an agent that has proven control of a given identity.

An application is a piece of software that interfaces with a resource server, which may operate autonomously as an authenticated agent, or in piloted-fashion by another authenticated agent.

A resource controller is an agent with fully permissioned access and control over one or more resources residing on a resource server on the Web.

A resource server is a web server that provides an interface to make resources available to agents and applications, with the ability to secure access to those resources through associated authorizations.

A resource is the target of an HTTP request identified by a [URI], as defined in [RFC7231].

A collection is a resource that is representative of a set of other resources, which may include other collections.

A tag is a type of metadata associated with a resource for classification or identification.

An authorization is a resource that controls access to one or more resources.

An authorization group is a resource that represents some combination of agents, applications, and authorization groups.

A capability is an object an agent must possess to be permitted to access a resource.

An access mode denotes a class of operations that an agent and/or application can perform on one or more resources.

Read access is an access mode that allows agents and/or applications the ability to read, but not modify a resource. When the resource is a collection, this includes access to the list of resources in that collection, but does not include access to their contents, or any metadata about them.

Write access is an access mode that allows agents and/or applications the ability to modify the contents of a resource. When the resource is a collection, the contents of the collection resource itself can be modified, but create access and delete access are required to create or delete resources from the collection.

Append access is an access mode that allows agents and/or applications to add data to the contents of a resource, but not modify any of the existing contents. When the resource is a collection, the contents of the collection resource itself can be added to, but create access is required to add new resources to the collection.

Create access is an access mode that allows agents and/or applications to add new resources to a given collection.

Delete access is an access mode that allows agents and/or applications to delete a resource. If the resource is a collection, it includes the ability to delete resources in that collection.

Read permission access is an access mode that allows agents and/or applications to view authorizations associated with a resource.

Write permission access is an access mode that allows agents and/or applications to modify authorizations associated with a resource.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html

Informative References

[DID]
Drummond Reed; et al. Decentralized Identifiers (DIDs) v1.0. URL: https://www.w3.org/TR/did-core/
[URI]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
[WEBID]
Tim Berners-Lee; Henry Story; Andrei Sambra. WebID 1.0. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/