Use Cases and Requirements for Web Access Control

Editor’s Draft,

This version:
Issue Tracking:
Inline In Spec
Solid Editorial Team


Use Cases and Requirements for Web Access Control.

Status of this document

1. Introduction

The § 2 Use Cases in this document represent real-world scenarios that Web Access Control can and should support. The § 3 Requirements in this document are derived from those use cases, and inform the contents of the Web Access Control specification.

§ 4 Limitations of Legacy Web Access Control highlights the § 2 Use Cases that Legacy Web Access Control fails to satisfy.

2. Use Cases

For the purposes of simplicity, the use cases herein assume that named individuals (i.e. 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. Basic 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. Control access

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-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.3. Read-append access 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. 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.4. 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.5. 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.6. Read-only access

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

2.1.7. 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.8. 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.9. 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. Basic 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 Inheritance.

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 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.

Alice’s portfolio and opportunities collections at https://alice.example/
Resource Type Description
portfolio/ Collection 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 detail about the portfolio collection itself, along with a listing of its contents, but not the contents of the resources included in that collection just yet.

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

2.2.2. Read-write access to a Collection

Alice worked with Milo in the past, where they produced a deliverable (document1) that she has included in her portfolio collection.

Alice realized that she doesn’t have the most up-to-date version document1, and needs Milo to replace it. She gives Milo read access and write access to the portfolio collection itself, which allows him to see the listing of its contents, as well as add and remove items from the collection.

He cannot read the contents of any of the resources included in the collection, but this is fine, since he knows the name of the resource he’s replacing.

Milo updates the contents of document1 to the most recent version.

2.2.3. Read-append access to a Collection

Alice worked with Bob in the past on a project, and she has included the project deliverables she could find in the project1 collection. She’s sure that she’s missing some, and that Bob would have the missing items.

Alice grants Bob read access and append access to the project1 collection, which allows him to see the list of what is there, and add new resources to it.

He can’t see the contents of the resources, or remove anything in the list. That’s fine because he only needs to add the resources that aren’t included.

2.2.4. Read-append-write 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. Append-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 append 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. Control access to 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 control access to project1 so that he can help her invite other colleagues from the past to add resources to it.

2.3. Inheritance

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-analysis/ 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 of 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 inherited read access to the weekly-status collection, which means they can read specific details about the collection, see a listing of the resource included in it (e.g. Bob’s notes), and 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 grants inherited read access at the weekly-status collection, it will apply to everything already in the collection, as well as anything that will be added in the future.

2.3.2. Read-append 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 gives the research authorization group inherited append access to the daily-metrics collection. This allows anyone in the authorization group to see the contents of the collection, and add new readings. They cannot modify readings after they are recorded. This provides confidence that readings are not manipulated after the fact.

2.3.3. Read-write access to 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 gives the research authorization group inherited read access and write access to the daily-summaries collection. This allows anyone in the authorization group to see the contents of the collection and collaborate on a given day’s summary. They can update the contents together until they’re satisfied with the results.

2.3.4. Append-only 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 read access on the daily-metrics collection so it can access the list of resources inside, and inherited append access access to daily-metrics, which allows it to add to a daily-metric resource if it already exists, or create a new one if a member of the research authorization group hasn’t made one for that day yet.

2.3.5. Control access to collection resources

Bob realizes that he needs some help administering https://research.example. He provides Carol with inherited read access and control access to https://research.example/, allowing her to read and manage permissions for all of the resources and collections included within it.

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 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 of 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 inherited 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 and control 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.

Felicia has granted Erin inherited read access and write access to the measurements collection, which contains measurements for all trial participants, across all trials.

Felicia adds a time-based condition for Erin which states that her access to measurements 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 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 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.

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 control 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.1 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 Web Access Control 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 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. Requirements

Populate requirements based on established use cases.

3.1. Example Category

3.1.1. This is an example requirement

Assert: Related Use Cases: § 2.1 Basic resource access

4. Limitations of Legacy Web Access Control

Legacy Web Access Control does not satisfy the following use cases:

5. Definitions

All definitions as stated below should be considered in the context of Web Access Control, 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 resources.

Write access is an access mode that allows agents and/or applications the ability to create, update, or delete a resource.

Append access is an access mode that allows agents and/or applications to add data to a resource, but not modify any data that already exists.

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


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.


Terms defined by this specification


Normative References

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL:
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL:

Informative References

Drummond Reed; et al. Decentralized Identifiers (DIDs) v1.0. URL:
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL:
Tim Berners-Lee; Henry Story; Andrei Sambra. WebID 1.0. URL:

Issues Index

Populate requirements based on established use cases.