diff --git a/README.md b/README.md
index 1768ad78..d138bc74 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,6 @@ to authorizing access to data in a Solid pod.
The Authorization Panel is undertaking the following initiatives,
in priority order:
-1. Document use cases and requirements for authorization - [Source](https://github.com/solid/authorization-panel/blob/master/proposals/wac-ucr/index.bs) - [Rendered](https://solid.github.io/authorization-panel/wac-ucr/)
-1. Produce normative draft text of the Web Access Control specification
+1. Document use cases and requirements for authorization - [Source](https://github.com/solid/authorization-panel/blob/master/proposals/authorization-ucr/index.bs) - [Rendered](https://solid.github.io/authorization-panel/authorization-ucr/)
+1. Produce an authorization system specification to satisfy [use cases and requirements](https://solid.github.io/authorization-panel/authorization-ucr/)
1. Produce and propose mechanism(s) for client constraints
diff --git a/proposals/wac-ucr/index.bs b/proposals/authorization-ucr/index.bs
similarity index 56%
rename from proposals/wac-ucr/index.bs
rename to proposals/authorization-ucr/index.bs
index ae9aa721..084cc987 100644
--- a/proposals/wac-ucr/index.bs
+++ b/proposals/authorization-ucr/index.bs
@@ -1,15 +1,15 @@
-Title: Use Cases and Requirements for Web Access Control
-Shortname: wac-ucr
+Title: Use Cases and Requirements for Authorization in Solid
+Shortname: authorization-ucr
Level: 1
-Max ToC Depth: 3
+Max ToC Depth: 2
Status: w3c/ED
Group: solid-cg
-URL: https://solid.github.io/authorization-panel/wac-ucr/
+URL: https://solid.github.io/authorization-panel/authorization-ucr/
Editor: Solid Editorial Team
Markup Shorthands: markdown yes
Abstract:
- Use Cases and Requirements for Web Access Control.
+ Use Cases and Requirements for Authorization in Solid.
@@ -42,6 +42,10 @@ Abstract:
color: #000000;
}
+ .assertion {
+ font-size: small;
+ }
+
@media (prefers-color-scheme: dark) {
a[data-link-type=dfn] {
color: #FFFFFF;
@@ -60,23 +64,22 @@ Introduction {#intro}
================================================================================
The [[#usecases]] in this document represent real-world scenarios that
-Web Access Control can and should support. The [[#requirements]] in this
-document are derived from those use cases, and inform the contents of the
-Web Access Control specification.
+a Solid authorization system should support. The [[#requirements]] in this
+document are derived from those use cases, and will inform and guide
+the contents of a subsequent specification proposal.
[[#limitations]] highlights the [[#usecases]] that
-[Legacy Web Access Control](https://github.com/solid/web-access-control-spec)
-fails to satisfy.
+the current authorization system fails to satisfy.
Use Cases {#usecases}
================================================================================
-For the purposes of simplicity, the use cases herein assume that named
-individuals (i.e. Alice, Bob, Carol, etc.) are already
+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.
-## Basic resource access ## {#uc-basic}
+## Resource access ## {#uc-basic}
Alice has a private draft of her resume stored on her [=resource server=] at
`https://alice.example/resume`. Alice is the [=resource controller=]
@@ -110,18 +113,46 @@ for that resource.
-### Control access ### {#basic-control}
+### Change permissions ### {#basic-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.
+
+
+### Read permissions ### {#basic-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.
+
+
+
### Read-write access ### {#basic-write}
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.
+
+
### Read-append access ### {#basic-readappend}
#### Alice stores Danielle's recommendation #### {#basic-readappend-single-storage}
@@ -132,6 +163,14 @@ in the references section of `resume`. Alice gives Danielle [=read access=] to
to `resume`, and cannot change any existing data within it. Danielle adds a
glowing reference for Alice to `resume`.
+
+
#### Danielle stores their own recommendation #### {#basic-readappend-multi-storage}
Danielle agrees to give Alice a personal reference, which Alice will link to
@@ -141,6 +180,14 @@ 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=].
+
+
### Append-only access ### {#basic-appendonly}
Alice is interested in seeing whether any of her other contacts might
@@ -151,20 +198,41 @@ 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
+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.
+
+
+* [[#req-agent-group]]
+* [[#req-append]]
+
+
+
### Removing access ### {#basic-removing}
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.
+
+
### Read-only access ### {#basic-readonly}
Alice has a job interview with Carol. Alice gives Carol [=read access=] to
`resume` ahead of the interview.
+
+
+* [[#req-agent-identity]]
+* [[#req-read]]
+
+
+
### Group access ### {#basic-group}
Alice has additional interest, and is now interviewing with people from
@@ -182,11 +250,25 @@ 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.
+
+
+* [[#req-agent-group]]
+* [[#req-read]]
+
+
+
### Public access ### {#basic-public}
-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.
+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.
+
+
+
+* [[#req-public]]
+* [[#req-read]]
+
+
### Logged in access ### {#basic-authenticated}
@@ -207,8 +289,16 @@ 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.
+
-## Basic collection access ## {#uc-collections}
+## Collection access ## {#uc-collections}
Note: These use cases are focused on access to a [=collection=] itself. Use
cases that focus on permissions related to [=resources=] included in that
@@ -219,10 +309,14 @@ Alice has a portfolio [=collection=] stored on her [=resource server=] at
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
+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/
@@ -241,8 +335,9 @@ https://alice.example/
`portfolio/`
[=Collection=]
-
Individual documents she's produced, and collections
- of deliverables from projects she's worked on.
+
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`
@@ -296,45 +391,65 @@ 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.
+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`.
+
+
-Alice wants know which of them are really interested based on who asks her for
-more access to the contents of `portfolio`.
+* [[#req-agent-identity]]
+* [[#req-read]]
+* [[#req-collection-read]]
+
+
### Read-write access to a Collection ### {#collection-readwrite}
-Alice worked with Milo in the past, where they produced a deliverable
-(`document1`) that she has included in her `portfolio` [=collection=].
+Alice is revising the summary description of her `portfolio`, which is
+stored in the [=resource=] for the `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=].
+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=].
+
+
-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.
+* [[#req-agent-identity]]
+* [[#req-collection-read]]
+* [[#req-collection-write]]
+
+
-Milo updates the contents of `document1` to the most recent version.
+### Read-create access to a Collection ### {#collection-readcreate}
-### Read-append access to a Collection ### {#collection-readappend}
+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 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 the following access on the `project1` [=collection=]:
-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.
+* [=Read access=] which allows him to see the summary detail of `project1`
+ stored in the `project` [=resource=] itself, as well as
+ a list of the [=resources=] in the [=collection=], which lets him confirm
+ whether his uploads are stored successfully.
+* [=Create access=] on `project1`, which allows him to 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.
+
-### Read-append-write access to a Collection ### {#collection-readappendwrite}
+* [[#req-agent-identity]]
+* [[#req-collection-read]]
+* [[#req-collection-create]]
+
+
+
+### Read-create-delete access to a Collection ### {#collection-readcreatedelete}
Note: Despite this section's focus on permissions specific to the collection
resource itself, this use case also incorporates inherited read access to
@@ -346,38 +461,66 @@ which are stored in the `comments` [=collection=].
When she asks a colleague to leave a comment, she gives them the following
permissions:
-* Inherited [=read access=] to the `comments` [=collection=]
- so they can list and read existing comments (including their own).
-* [=Append access=] to the `comments` [=collection=], which allows them to
- add their own comments, but not change anyone else's including their
- own after the comments have been submitted.
-* Ability to write (edit or delete) any resources in `comments` that they
- have created themselves, but none created by anyone else.
+* [=Read access=] to the `comments` [=collection=]
+ so they can list existing comments (including their own).
+* Inherited [=read access=] to the [=resources=] in the `comments` [=collection=],
+ so they can read the contents of existing comments (including their own).
+* [=Create access=] to the `comments` [=collection=], which allows them to
+ add new comments, but not change any that exist already.
+* Default permissions on new [=resources=] in `comments` that stipulate:
+ * [=Delete access=] for the creator of a [=resource=] - so they can delete
+ their own comments if they like, but no one else's.
+
+
-### Append-only access to a Collection ### {#collection-appendonly}
+### Create-only access to a Collection ### {#collection-createonly}
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`
+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.
-### Control access to a Collection ### {#collection-control}
+
+
+### Manage permissions for a Collection ### {#collection-control}
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.
+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.
-## Inheritance ## {#uc-inheritance}
+
+
+## Collection resource inherited access ## {#uc-inheritance}
Bob is leading a group of colleagues doing field research. This group
includes Charles, Felicia, Juan, and Irene.
@@ -493,7 +636,7 @@ https://research.example/
Daily reading
-
`daily-analysis/`
+
`daily-summaries/`
Collection
Daily analysis for group research
@@ -515,7 +658,7 @@ https://research.example/
-### Read-only access to collection of resources ### {#inheritance-readonly}
+### Read-only access to collection resources ### {#inheritance-readonly}
Bob has a weekly status meeting with the members of the `research`
[=authorization group=].
@@ -528,58 +671,138 @@ 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
+He grants the `research` [=authorization group=] [=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
+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 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.
+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.
+
+
-### Read-append access to collection resources ### {#inheritance-readappend}
+### Read-create access to collection resources ### {#inheritance-readcreate}
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.
+Bob sets the following permissions on the `daily-metrics` [=collection=] for
+the `research` [=authorization group=]:
-### Read-write access to collection resources ### {#inheritance-readwrite}
+* [=Read access=] so they can see the current list of [=resources=] in
+ the [=collection=].
+* Inherited [=read access=] so that they can read the contents of those
+ [=resources=].
+* [=Create access=] so that they can add new readings. They cannot modify
+ readings after they are recorded, because they do not have [=write access=],
+ and they cannot remove them, because they do not have [=delete access=].
+ This provides confidence that readings
+ are not manipulated after the fact.
+
+
+
+### Manage a hierarchy of collection resources ### {#inheritance-manage}
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.
+Bob sets the following permissions on the `daily-summaries` [=collection=]
+for the `research` [=authorization group=]:
+
+* [=Read access=] so they can see the current list of [=resources=] in
+ the `daily-summaries`.
+* [=Create access=] so they can add new summary [=resources=] to `daily-summaries`
+* [=Delete access=] so they can remove summary [=resources=] from `daily-summaries`
+* Inherited [=read access=] so they can read the
+ contents of the summaries in the [=collection=]
+* Inherited [=write access=] so they can modify their contents
+* Inherited [=create access=] so they can add [=resources=] to any [=collections=]
+ that might be added to `daily-summaries`
+* Inherited [=delete access=] so they can remove [=resources=] from any
+ [=collections=] that might be added to `daily-summaries`
+
+
+
+### Create-append access to collection resources ### {#inheritance-createappend}
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.
+Bob gives the new field device the following permissions on the
+`daily-metrics` [=collection=]:
+
+* [=Read access=] so it can access the list of resources in the collection
+* Inherited [=read access=] so it can read the contents of existing metric readings
+* [=Create access=] so it can create a new daily metric resource if a member of
+ the `research` [=authorization group=] hasn't made one for that day yet.
+* Inherited [=append access=] so it can add metric readings to daily-metric
+ resources that already exist.
-### Control access to collection resources ### {#inheritance-control}
+
+
+### Manage permissions for collection resources ### {#inheritance-control}
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.
+He provides Carol with the following permissions on the
+`https://research.example` collection:
+
+* [=Read access=] so she can see the current list of [=resources=] in
+ the [=collection=].
+* Inherited [=read access=] so she can read the
+ contents of the resources in the [=collection=]
+* [=Read permission access=] and [=write permission access=] allowing her
+ to read and manage permissions for all of the [=resources=] and
+ included within it.
+
+
### Default permissions on created resources ### {#inheritance-defaultcreated}
@@ -598,6 +821,12 @@ 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=].
+
+
+* [[#req-inheritance-default-permissions]]
+
+
+
### Default permissions for extended network ### {#inheritance-extended}
Alice has a blog and allows comments on her posts. Ideally, everyone's
@@ -608,6 +837,17 @@ 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.
+
+
+
### Adding new subjects to inherited permissions ### {#inheritance-adding}
Note: Adding a new subject means we are adding a new [=agent=],
@@ -622,7 +862,7 @@ to the `weekly-status` [=collection=] (detailed in [[#inheritance-readonly]]).
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
+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=],
@@ -634,6 +874,14 @@ 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.
+
+
### Modifying inherited permissions for existing subjects ### {#inheritance-modifying}
On the January 6th weekly status meeting, Bob and the `research`
@@ -656,6 +904,14 @@ 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.
+
+
### Forcing inherited permissions ### {#inheritance-forcing}
As the primary administrator and [=resource controller=] of
@@ -664,10 +920,22 @@ 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
+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.
+
+
## Conditional access ## {#uc-conditional}
Felicia works for an organization that conducts clinical trials, and leads a
@@ -763,15 +1031,27 @@ 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
+The `measurements` [=collection=] 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.
+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.
+
+
### Conditional access by tag ### {#conditional-tag}
As a research intern, Erin is responsible for processing all unprocessed
@@ -783,7 +1063,8 @@ measurements that have already been processed.
* All measurements for the `Acme` trial are tagged with `Acme`
* When a new measurement is processed, it is tagged as `processed`
-Felicia authorizes Erin to have inherited [=read access=] and [=write access=]
+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:
* **include** the `Acme` [=tag=]
@@ -793,6 +1074,16 @@ 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.
+
+
### Conditional access by relationship ### {#conditional-relationship}
Felicia is responsible for preparing and sharing internal reports for senior
@@ -808,7 +1099,8 @@ 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
+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.
@@ -816,6 +1108,14 @@ 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.
+
+
### Conditional access by filter ### {#conditional-filter}
Felicia has been able to limit the scope of the [=resources=] that Erin can
@@ -829,6 +1129,17 @@ 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.
+
+
### Conditional control boundaries ### {#conditional-control}
Megan works on Felicia's team. Felicia would like Megan to be responsible for
@@ -836,15 +1147,29 @@ 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
+Felicia grants Megan inherited [=read permission access=]
+and [=write permission access=] to `measurements`, with
conditions that stipulate:
-* she only has effective [=control access=] of [=resources=] that include
+* she only has effective [=read permission access=] and
+ [=write permission access=] of [=resources=] that include
the `Acme` [=tag=] within the `measurements` [=collection=].
* she can only create or change [=authorizations=]
targeting the `measurements` [=collection=] where
[=agents=] are included in the `interns` [=authorization group=].
-* she can't grant [=control access=] to anyone else.
+* she can't grant [=read permission access=] and/or [=write permission access=]
+ to anyone else.
+
+
### Conditional access by action ### {#conditional-action}
@@ -856,6 +1181,16 @@ 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.
+
+
### Conditional access by payment ### {#conditional-payment}
A musician would like to self publish her music to take advantage of a Solid
@@ -869,6 +1204,16 @@ 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.
+
+
## Permissioning Applications ## {#uc-applications}
### Limiting access to trusted applications ### {#uc-trusted-applications}
@@ -890,15 +1235,52 @@ For example, to constrain Oscar's access to `https://oscar.example` to only
cases where an application he trusts is involved:
* Oscar **with the** `trusted-applications` [=authorization group=] has
- [=read access=], [=write access=], and [=control access=] to
- `https://oscar.example`
+ the following permissions on `https://oscar.example`:
+ * [=Read access=] so that he can read summary data for the
+ `https://oscar.example` [=resource=], and list its contents. Inherited
+ [=read access=] to all member resources so he can read and/or list their
+ contents.
+ * [=Write access=] so that he can change summary data for the
+ `https://oscar.example` [=resource=]. Inherited [=write access=] to
+ all member [=resources=] so he can change their contents.
+ * [=read permission access=] and [=write permission access=] so that
+ he can read and manage permissions. Inherited [=read permission access=]
+ and [=write permission access=] so that he can manage permissions
+ for all member resources.
+ * [=Create access=] and [=Delete access=] so that
+ he can add and remove resources. Inherited [=create access=] and
+ [=delete access=] so that he can add resources to member [=collections=]
+ and delete resources from them.
Following that, per [[#inheritance-modifying]], he could extend this default
for the `health` [=collection=] to include `healthapp`:
* Oscar **with the** `trusted-applications` [=authorization group=] AND
- `healthapp` has [=read access=], [=write access=], and [=control access=]
- to the `health` [=collection=]
+ `healthapp` has [=read access=], [=write access=], [=create access=],
+ [=delete access=], [=read permission access=],
+ and [=write permission access=] to the `health` [=collection=], along
+ with corresponding inherited permissions for [=collection=] member
+ [=resources=].
+
+
### Limiting application access while not acting as resource controller ### {#uc-client-constraints}
@@ -910,6 +1292,17 @@ projects, she also has read-write access to many other projects. Since
write access. Alice grants *PerformChart* read only access to all the projects
that she can access.
+
### Application determining access privileges ### {#uc-client-determine-access-privileges}
@@ -925,6 +1318,15 @@ 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.
+
## Privacy ## {#uc-privacy}
@@ -939,6 +1341,14 @@ 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.
+
+
### Limiting access to other authorization conditions ### {#uc-historyofchanges}
As an extension of [[#uc-whopermitted]], it is also important to Alice that
@@ -950,6 +1360,13 @@ For example, if the data Carol and Oscar saw in the resume was
background, she wouldn't want them to know that they were only seeing a
filtered view.
+
+
### Minimal Credential Disclosure ### {#uc-minimalcredentials}
Following a link on a blog post, Alice comes to a resource that requires
@@ -962,6 +1379,13 @@ 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.
+
+
+* [[#req-vc]]
+* [[#req-vc-determine]]
+
+
+
### Limit information disclosure through URI ### {#uc-limituri}
A service with very high security and confidentiality requirements must
@@ -1029,7 +1453,6 @@ scheme.
-
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
@@ -1040,6 +1463,14 @@ 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.
+
+
+* [[#req-uripath]]
+
+
+
+
+
## Trust ## {#uc-trust}
### Only trust certain issuers of identity ### {#uc-trustedissuers}
@@ -1050,6 +1481,13 @@ Carol has a blog, and allows any [=authenticated agent=] (e.g. [[WEBID]],
Unfortunately, anyone can setup an identity provider, so Carol would like to
be able to recognize credentials issued from trustworthy identity providers.
+
+
### Block access to agents ### {#uc-blockagents}
A nonpartisan group provides a public annotation service, and allows any
@@ -1060,13 +1498,19 @@ 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.
+
+
+* [[#req-agent-identity]]
+
+
+
## Validation ## {#uc-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
+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.
@@ -1103,6 +1547,14 @@ 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.
+
+
### Possession of a link ### {#capabilities-link}
Bob is about to give a confidential presentation to a group of his colleagues.
@@ -1123,42 +1575,319 @@ specially generated link to access the document with [=read access=]. He sets
it to [[#conditional-time|expire]] in three hours. Bob gives the link to Anne
and the presentation goes off perfectly.
-Requirements {#requirements}
+* [[#req-vc]]
+* [[#req-read]]
+* [[#req-conditional-time]]
+
+Functional Requirements {#requirements}
================================================================================
-Issue: Populate requirements based on established use cases.
+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=].
+
+## Access by subject ## {#req-as}
+
+### The system shall allow access to be limited based on the [=identity=] of the [=agent=]. ### {#req-agent-identity}
+
+
+ Related use cases: [[#uc-basic]], [[#uc-collections]]
+
+
+### 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. ### {#req-trusted-identity}
+
+
+ Related use cases: [[#uc-trustedissuers]]
+
+
+### The system shall allow access to be limited to an [=agent=] based on the [=agent's=] membership in a certain group of [=agents=]. ### {#req-agent-group}
+
+
+ Related use cases: [[#basic-group]]
+
+
+### The system shall allow access to be limited to an [=agent=] based on the client [=application=] in use by the [=agent=]. ### {#req-application}
+
+
+ Related use cases: [[#uc-trusted-applications]]
+
+
+### 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. ### {#req-client-constrained}
+
+
+ Related use cases: [[#uc-client-constraints]]
+
+
+### The system shall allow access to be permitted for any unauthenticated or authenticated [=agent=]. ### {#req-public}
-## Example Category ## {#example-category}
+
+ Related use cases: [[#basic-public]]
+
+
+### The system shall allow access to be limited to any authenticated [=agent=]. ### {#req-authenticated}
+
+
+ Related use cases: [[#basic-authenticated]]
+
+
+## Access by capability ## {#req-capabilities}
-### This is an example requirement ### {#example-requirement}
+### The system shall allow access to be limited to an [=agent=] based on the [=agent's=] possession of a certain verifiable credential or capability. ### {#req-vc}
+
+
+ Related use cases: [[#capabilities-vc]], [[#capabilities-link]], [[#uc-minimalcredentials]]
+
+
+### The system shall ensure that there are practical and efficient mechanism available for the client to determine an appropriate credential to present for access to a given [=resource=]. ### {#req-vc-determine}
+
+
+ Related use cases: [[#capabilities-vc]], [[#uc-minimalcredentials]], [[#conditional-payment]]
+
+
+## Access to resources ## {#req-resources}
+
+### The system shall allow the ability to read the access permissions associated with a certain [=resource=] to be limited. ### {#req-read-permissions}
+
+
+ Related use cases: [[#basic-read-permissions]], [[#uc-whopermitted]], [[#uc-historyofchanges]]
+
+
+### The system shall allow the ability to change the access permissions associated with a certain [=resource=] to be limited. ### {#req-change-permissions}
+
+
+ Related use cases: [[#basic-change-permissions]]
+
+
+### 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. ### {#req-effective-modes}
+
+
+ Related use cases: [[#uc-client-determine-access-privileges]]
+
+
+### The system shall allow the ability to read a certain [=resource=] to be limited.### {#req-read}
+
+
+ Related use cases: [[#basic-readonly]], [[#basic-write]], [[#basic-readappend]]
+
+
+### The system shall allow the ability to change any of the existing contents of a certain [=resource=] to be limited.### {#req-write}
+
+
+ Related use cases: [[#basic-write]]
+
+
+### 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.### {#req-append}
+
+
+ Related use cases: [[#basic-appendonly]], [[#basic-readappend]]
+
+
+### The system shall limit the ability to delete a certain [=resource=]. ### {#req-delete}
+
+
+ Related use cases: [[#collection-readcreatedelete]]
+
+
+### The system shall allow for access to a [=resource=] or [=collection=] to be limited to the [=agent=] that created it. ### {#req-creator}
+
+
+ Related use cases: [[#collection-readcreatedelete]]
+
-Assert: Related Use Cases: [[#uc-basic]]
+### The system shall not rely on the URI path to identity [=resources=] or [=collections=] ### {#req-uripath}
-Limitations of Legacy Web Access Control {#limitations}
+
+ Related use cases: [[#uc-limituri]]
+
+
+## Access to collections ## {#req-collections}
+
+### 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. ### {#req-collection-read}
+
+
+ Related use cases: [[#collection-readonly]], [[#collection-readwrite]],
+ [[#collection-readcreate]], [[#collection-readcreatedelete]]
+
+
+### 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. ### {#req-collection-write}
+
+
+ Related use cases: [[#collection-readwrite]]
+
+
+### The system shall allow the ability to create a [=resource=] in a certain [=collection=] to be limited.### {#req-collection-create}
+
+
+ Related use cases: [[#collection-readwrite]], [[#collection-readcreate]],
+ [[#collection-readcreatedelete]], [[#collection-createonly]]
+
+
+### The system shall limit the ability to delete a [=resource=] in a certain [=collection=].### {#req-collection-delete}
+
+
+ Related use cases: [[#collection-readcreatedelete]]
+
+
+### The system shall allow for the creator of a [=resource=] in a certain [=collection=] to be automatically granted access to the created [=resource=].### {#req-collection-creator}
+
+
+ Related use cases: [[#collection-readcreatedelete]]
+
+
+### The system shall allow the ability to read the access permissions associated with a certain [=collection=] to be limited.### {#req-collection-read-permissions}
+
+
+ Related use cases: [[#collection-control]], [[#uc-whopermitted]],
+ [[#uc-historyofchanges]]
+
+
+### The system shall allow the ability to change the access permissions directly associated with a certain [=collection=] to be limited.### {#req-collection-change-permissions}
+
+
+ Related use cases: [[#collection-control]]
+
+
+## Inherited access to collection resources ## {#req-inherited}
+
+### The system shall allow for a certain [=collection=] to specify access permissions that are inherited by its members.### {#req-collection-inheritance}
+
+
+ Related use cases: [[#uc-inheritance]]
+
+
+### 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. ### {#req-inheritance-readonly}
+
+
+ Related use cases: [[#inheritance-readonly]]
+
+
+### 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. ### {#req-inheritance-change}
+
+
+ Related use cases: [[#inheritance-manage]]
+
+
+### 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. ### {#req-inheritance-appendonly}
+
+
+ Related use cases: [[#inheritance-createappend]]
+
+
+### 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. ### {#req-inheritance-create}
+
+
+ Related use cases: [[#inheritance-readcreate]]
+
+
+### 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. ### {#req-inheritance-delete}
+
+
+ Related use cases: [[#collection-readcreatedelete]]
+
+
+### The system shall allow for the members of a certain [=collection=] to extend or augment the permissions inherited from the parent [=collection=].### {#req-inheritance-modify}
+
+
+ Related use cases: [[#inheritance-adding]], [[#inheritance-modifying]]
+
+
+### The system shall allow for a certain [=collection=] to specify access permissions that are inherited by its members and cannot be augmented. ### {#req-inheritance-force}
+
+
+ Related use cases: [[#inheritance-forcing]]
+
+
+### 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. ### {#req-inheritance-default-permissions}
+
+
+ Related use cases: [[#inheritance-defaultcreated]], [[#inheritance-extended]]
+
+
+### 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. ### {#req-inheritance-read-permissions}
+
+
+ Related use cases: [[#inheritance-control]]
+
+
+### 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. ### {#req-inheritance-change-permissions}
+
+
+ Related use cases: [[#inheritance-control]]
+
+
+## Conditional access ## {#req-conditional}
+
+### The system shall allow the ability to limit access to a certain [=resource=] by a given start and/or end data and time.### {#req-conditional-time}
+
+
+ Related use cases: [[#conditional-time]]
+
+
+### The system shall allow the ability to limit access to a certain [=resource=] by a tag associated with that resource.### {#req-conditional-tag}
+
+
+ Related use cases: [[#conditional-tag]]
+
+
+### The system shall allow the ability to limit access to a certain [=resource=] based on the existence of a specific relationship with another [=resource=].### {#req-conditional-relationship}
+
+
+ Related use cases: [[#conditional-relationship]], [[#inheritance-extended]]
+
+
+### The system shall allow access to be limited to only a subset of data in a certain [=resource=] based on supplied filter criteria.### {#req-conditional-filter}
+
+
+ Related use cases: [[#conditional-filter]]
+
+
+### 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.### {#req-conditional-action}
+
+
+ Related use cases: [[#conditional-action]]
+
+
+### 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.### {#req-conditional-control}
+
+
+ Related use cases: [[#conditional-control]]
+
+
+### The system shall allow the ability to read, create, or change access permissions for [=resources=] associated with a particular tag to be limited.### {#req-conditional-control-tag}
+
+
+ Related use cases: [[#conditional-control]]
+
+
+Limitations of Web Access Control {#limitations}
================================================================================
-[Legacy Web Access Control](https://github.com/solid/web-access-control-spec)
+[Web Access Control](https://github.com/solid/web-access-control-spec)
does not satisfy the following use cases:
* [[#inheritance-adding]]
* [[#inheritance-modifying]]
* [[#inheritance-forcing]]
-* [[#collection-readappendwrite]]
+* [[#inheritance-extended]]
+* [[#collection-readcreatedelete]]
* [[#conditional-time]]
* [[#conditional-tag]]
* [[#conditional-filter]]
* [[#conditional-control]]
+* [[#conditional-payment]]
* [[#uc-applications]]
* [[#uc-trustedissuers]]
* [[#uc-validation]]
* [[#capabilities-vc]]
* [[#capabilities-link]]
+* [[#uc-minimalcredentials]]
+* [[#uc-limituri]]
Definitions {#definitions}
================================================================================
-All definitions as stated below should be considered in the context of Web
-Access Control, whether explicitly stated or not.
+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.
@@ -1205,18 +1934,37 @@ 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=].
+[=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 create, update, or delete a [=resource=].
+[=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 a resource, but not modify any data that
-already exists.
+[=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=].
-Control access is an [=access mode=] that allows [=agents=] and/or
-[=applications=] to view and modify [=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=].
{
diff --git a/proposals/wac-ucr/uc-survey.md b/proposals/authorization-ucr/uc-survey.md
similarity index 77%
rename from proposals/wac-ucr/uc-survey.md
rename to proposals/authorization-ucr/uc-survey.md
index a59b8c5f..eddf93cc 100644
--- a/proposals/wac-ucr/uc-survey.md
+++ b/proposals/authorization-ucr/uc-survey.md
@@ -22,8 +22,15 @@ Notes:
## Basic resource access
-### Control access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-control
+### Change permissions
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-change-permissions
+
+* +1 bblfish: public [si] [ai].
+
+### Read permissions (was basic control?)
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-read-permissions
+
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-control
* +1 justinwb: to the ability to read and write permissions on resources. public [ai]. private [ai].
* +1 elf-pavlik:
@@ -35,8 +42,9 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-control
* +1 dmitrizagidulin: public [si].
* +1 bblfish: public [si] [ai].
+
### Read-write access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-write
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-write
* +1 justinwb:
* +1 elf-pavlik:
@@ -48,8 +56,9 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-write
* +1 dmitrizagidulin:
* +1 bblfish: public [si] [ai] (note: the resume example implies a PATCH mechanism for HTML, which needs to be identified, and taken on elsewhere. PATCH for RDF is specified and quite implementable (it involves SPARQL UPDATE)).
+
### Read-append access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-readappend
* +3 timbl:
* +1 justinwb:
@@ -62,7 +71,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend
#### Alice stores Danielle's recommendation
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend-single-storage
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-readappend-single-storage
* +1 justinwb:
* +1 elf-pavlik:
@@ -74,11 +83,11 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend-singl
* +1 bblfish: public [si] [ai]. (note: again assumes RDF based Resumé)
#### Danielle stores their own recommendation
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend-multi-storage
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-readappend-multi-storage
* +1 justinwb:
* +1 elf-pavlik:
-* +1 csarven: [d] such that agent A sends a notification about the recommendation to agent B's inbox ie. #collection-readappend , instead of updating a resource that references it.
+* +1 csarven: [d] such that agent A sends a notification about the recommendation to agent B's inbox ie. #collection-readcreate , instead of updating a resource that references it.
* +1 jaxoncreed:
* +1 KaiGilb: graphMetrix
* +1 hindia:
@@ -86,7 +95,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend-multi
* +1 bblfish: public [si] [ai]. (note: for RDF based Resumes this make sense, not for HTML)
### Append-only access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-appendonly
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-appendonly
* +1 justinwb:
* +1 elf-pavlik:
@@ -101,7 +110,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-appendonly
* +1 bblfish: public [si] [ai] )(note: resumé examples make sense for RDF based resumes. Or for append to a container (in which case the RDF can be signed). For RDF based resumes, append makes sense if the resumé is in Quad format, as that allows subgraphs to be signed. Otherwise linking makes more sense)
### Removing access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-removing
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-removing
* +1 justinwb:
* +1 elf-pavlik:
@@ -115,7 +124,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-removing
### Read-only access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readonly
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-readonly
* +1 justinwb:
* +1 elf-pavlik:
@@ -128,7 +137,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readonly
* +1 bblfish: public [si] [ai].
### Group access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-group
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-group
* +1 justinwb:
* +1 elf-pavlik:
@@ -141,7 +150,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-group
* +1 bblfish: public [si] [ai].
### Public access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-public
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-public
* +1 justinwb:
* +1 csarven: Wide use. Required for [ap]. [d].
@@ -153,7 +162,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-public
* +1 bblfish: public [si] [ai].
### Logged in access
-URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-authenticated
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#basic-authenticated
* +0 justinwb: There's controversy over whether this can be valuable given
the ability for anyone to spin up their own identity in a decentralized
@@ -177,10 +186,11 @@ This is an important aspect of onboarding and the growth os Solid.
"Grant access only if the user consents to be added to a list for future contacting etc".
* +1 bblfish: public [si] [ai].
-## Basic collection access
+## Collection access
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-collection
### Read-only access to a Collection
-URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readonly
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#collection-readonly
* +1 justinwb:
* +1 elf-pavlik:
@@ -190,10 +200,11 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readonly
* +1 KaiGilb: graphMetrix
* +1 hindia:
* +3 dmitrizagidulin:
-* +1 bblfish: public [si] [ai]. (proviso: if the ldp:Container only contains ldp:contains links, and no other descriptive info, it would be difficult for people to know what the contents are to make up their minds about what they are interested in. See the Tor example where it would make no sense. Perhaps one needs to add that the container shows the title of the contents, and summary, and links to requests to see the contents. This would require something like an solid:InformativeContainer which shows such information and acts like an RSS Feed.)
+* +1 bblfish: public [si] [ai]. (changes with PR 166 ok)
+
### Read-write access to a Collection
-URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readwrite
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#collection-readwrite
* +1 justinwb:
* +1 elf-pavlik:
@@ -203,10 +214,10 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readwrite
* +1 KaiGilb: graphMetrix
* +1 hindia:
* +1 dmitrizagidulin: (though I agree with @jaxoncreed that clarification is needed.)
-* +0 bblfish: public [si] [ai]. (agree with jaxon. I also think one needs to distinguish between ability to add new resources the Container, and changes to the container itself. You may be happy to allow people to add to an ldp:Container but not to change the nature of the container, say from an ldp:BasicContainer to an ldp:IndirectContainer, as the latter container has speech act implications beyond the creation of the content. See my [chapter 2 of my 2nd year report](https://co-operating.systems/2019/04/01/). Yes, delete without read seems dubious and dangerous - in [RelBAC](https://github.com/solid/authorization-panel/issues/150) I think delete is a subproperty of write.).
+* +0 bblfish: public [si] [ai]. (changes with PR 166 ok)
-### Read-append access to a Collection
-URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readappend
+### Read-create access to a Collection
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#collection-readcreate
* +1 justinwb:
* +1 elf-pavlik:
@@ -216,16 +227,16 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readappend
* +1 hindia:
* +0 dmitrizagidulin: The usefulness of this UC, as written, depends on resource
names (filenames) being human-readable.
-* +1 bblfish: public [si] [ai] (agree with Dmitry though I one could also allow new types of containers that act as RSS feeds, giving title and summaries of the contents therein).
+* +1 bblfish: public [si] [ai] (changes with PR 166 ok)
-### Read-append-write access to a Collection
-URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readappendwrite
+### Read-create-delete access to a Collection
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#collection-readcreatedelete
* +1 justinwb: Being able to designate the creator of a resource with specific
privileges in an append scenario on a container is extremely important to
a number of collaborative scenarios.
* +1 elf-pavlik:
-* 0 csarven: Seems like duplicate of #collection-readwrite and #collection-readappend
+* 0 csarven: Seems like duplicate of #collection-readwrite and #collection-readcreate
* +1 jaxoncreed:
* +3 timbl:
* +1 KaiGilb: graphMetrix
@@ -236,22 +247,22 @@ a number of collaborative scenarios.
* +2 bblfish: public [si] [ai]
-### Append-only access to a Collection
-URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-appendonly
+### Create-only access to a Collection
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#collection-createonly
* +1 justinwb:
* +1 elf-pavlik:
* +1 csarven: Wide use. Required for [ap] eg. creating annotations or notifications. [d].
* +1 jaxoncreed:
-* +3 timbl: Append-only access allows you to implement the semantics of message passing. That is a crcuial building blcok for many systems,
+* +3 timbl: Append-only access allows you to implement the semantics of message passing. That is a crucial building block for many systems,
technical and social. We may been extra functionality to in some cases giuve people read-write access to a thing they have posted using append-only access.
* +1 KaiGilb: graphMetrix
* +1 hindia:
* +3 dmitrizagidulin:
* +2 bblfish: public [si] [ai]
-### Control access to a Collection
-URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-control
+### Manage permissions for a Collection
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#collection-control
* +1 justinwb:
* +1 elf-pavlik:
@@ -263,10 +274,10 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-control
* +3 dmitrizagidulin:
* +1 bblfish: public [si] [ai]
-## Inheritance
+## Collection resource inherited access
### Read-only access to collection of resources
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readonly
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-readonly
* +1 justinwb:
* +1 elf-pavlik:
@@ -276,12 +287,10 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readonly
* +1 KaiGilb: graphMetrix
* +1 hindia:
* +3 dmitrizagidulin:
-* +1 bblfish: public [si] [ai] (note: I find the phrase "research authorization group" unwieldy. Why should
- one distinguish an authorization group, from any other group of agents? Any access control rule can
- authorize any group to access resources)
+* +1 bblfish: public [si] [ai]
-### Read-append access to collection resources
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readappend
+### Read-create access to collection resources
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-readcreate
* +1 justinwb:
* +1 elf-pavlik:
@@ -293,12 +302,12 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readappend
* +1 dmitrizagidulin:
* +1 bblfish: public [si] [ai]
-### Read-write access to collection resources
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readwrite
+### Manage a hierarchy of collection resources
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-manage
* +1 justinwb:
* +1 elf-pavlik:
-* +1 csarven: Wide use. Required for [ap] - similar to #inheritance-readappend. [d].
+* +1 csarven: Wide use. Required for [ap] - similar to #inheritance-readcreate. [d].
* 0 jaxoncreed: I think this needs more clarification on what happens to nested collections.
* +3 timbl:
* +1 KaiGilb: graphMetrix
@@ -306,8 +315,8 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readwrite
* +3 dmitrizagidulin:
* +1 bblfish: public [si] [ai]
-### Append-only access to collection resources
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-appendonly
+### Create-append access to collection resources
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-createappend
* +1 justinwb:
* +1 elf-pavlik:
@@ -319,8 +328,8 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-appendonly
* +3 dmitrizagidulin:
* +1 bblfish: public [si] [ai]
-### Control access to collection resources
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-control
+### Manage permissions for collection resources
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-control
* +1 justinwb:
* +1 elf-pavlik:
@@ -333,7 +342,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-control
* +1 bblfish: public [si] [ai]
### Default permissions on created resources
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-defaultcreated
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-defaultcreated
* +1 justinwb:
* +1 elf-pavlik:
@@ -346,7 +355,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-defaultcre
* +1 bblfish: public [si] [ai]
### Default permissions for extended network
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-extended
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-extended
* +1 justinwb:
* +1 elf-pavlik:
@@ -355,10 +364,10 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-extended
* +1 KaiGilb: graphMetrix
* +1 hindia:
* +1 dmitrizagidulin:
-* +1 bblfish: public [si] [ai] (note: I don't understand the last paragraph: what is a "granular fashion"?)
+* +1 bblfish: public [si] [ai]
### Adding new subjects to inherited permissions
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-adding
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-adding
* +1 justinwb: Without an extensible inheritance system, it is near impossible
to do any permission management that doesn't require managing permissions
@@ -373,7 +382,7 @@ above.
* +1 bblfish: public [si] [ai]
### Modifying inherited permissions for existing subjects
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-modifying
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-modifying
* +1 justinwb: Without an extensible inheritance system, it is near impossible
to do any permission management that doesn't require managing permissions
@@ -388,7 +397,7 @@ above.
* +1 bblfish: public [si] [ai] (note: could be tricky to do right)
### Forcing inherited permissions
-URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-forcing
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#inheritance-forcing
* +1 justinwb: Some permissions shouldn't be contradicted. For example,
the administrator with full control access of a given storage (i.e. pod)
@@ -406,7 +415,7 @@ inside.
## Conditional access
### Conditional access by time
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-time
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-time
* +1 justinwb: Setting timeouts can really come in handy, and is a good
way to ensure that permissions meant to be short-lived don't hang around
@@ -421,7 +430,7 @@ invitiation flows.
* +1 bblfish: public [si] [ai]
### Conditional access by tag
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-tag
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-tag
* +1 justinwb: Noting that we haven't specified a tag-based system for data
yet in solid, the ability to tag individual resources, or collections of
@@ -439,7 +448,7 @@ photo albums in my media library to colleagues.
* +1 bblfish: public [si] [ai] - agree with dmitri and justin
### Conditional access by relationship
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-relationship
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-relationship
* +1 justinwb: Cannot underscore how important this use case is to doing
intuitive authorization on more complex data objects. We cannot rely on
@@ -456,10 +465,10 @@ case addresses that.
* +1 KaiGilb: graphMetrix. This seems very important. Like only give certain doctor relations access to records.
* +1 hindia:
* +1 dmitrizagidulin:
-* +1 bblfish: public [si] [ai] - agree with dmitri and justin
+* +1 bblfish: public [si] [ai] - agree with justin
### Conditional access by filter
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-filter
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-filter
* +0 justinwb: This is important, but I think we can hit it in the next cycle.
Ultimately, we need the manage access to data within the resource. There are
@@ -473,7 +482,7 @@ some rational ways to do this using machinery we already have.
* +0 bblfish: public [si] [ai] - agree with justinwb, there is already a lot on the plate.
### Conditional control boundaries
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-control
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-control
* +0 justinwb:
* +1 elf-pavlik:
@@ -485,7 +494,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-control
* +0 bblfish: public [si] [ai] - this may be something for the next version, requires reasoning to do well
### Conditional access by action
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-action
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-action
* 0 justinwb:
* +1 elf-pavlik:
@@ -497,18 +506,18 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-action
* +0 bblfish: public [si] [ai] - very nice feature, but may be for next version
### Conditional access by payment
-URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-payment
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#conditional-payment
* +0 csarven: Generally useful for [ap] in that it can handle server's response to client error eg. prompt user with "Payment Required". May [d].
* +0 Kai Gilb: graphMetrix. Sounds cool, but maybe it could be handled by other means integrating with pay wall etc.
* +1 hindia:
-* +0 dmitrizagidulin: The proof of payment could be handled by https://solid.github.io/authorization-panel/wac-ucr/#capabilities-vc
+* +0 dmitrizagidulin: The proof of payment could be handled by https://solid.github.io/authorization-panel/authorization-ucr/#capabilities-vc
* +0 bblfish: public [si] [ai] - may be able to research this, depending on funding.
## Permissioning Applications
### Limiting access to trusted applications
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-trusted-applications
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-trusted-applications
* +1 justinwb: Limiting access to only specific applications, identified
by AppID, with the caveat that the effectiveness is specifically when
@@ -522,16 +531,16 @@ piloted scenarios)
* -1 bblfish: This should be possible, but on the whole it would be better if this happned on the client side, by something like what was called [the launcher app](https://github.com/solid/authorization-panel/issues/45). The reason is that this works ok for the Oscar's own server, but not that well for every other server. A better use case would be one involving Oscar discovering that an App is badly written, and is creating havock, and wanting to limit it for that reason. This would also allow one to subscribe to some security service that would test apps and publish blacklists.
### Limiting application access while not acting as resource controller
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-client-constraints
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-client-constraints
* 0 csarven: A bit of a low-level server-side plumbing. Unclear how an application (like [ap]) may want/need to set a policy as such.
* KaiGilb: im a little unclear on this case
* +1 hindia:
* +1 dmitrizagidulin:
-* -1 bblfish: this is better done on the client, where such information can be written out once, without needing to have control access to every resource on the web that the app could have access to.
+* +1 bblfish: this needs to be done on the client, where such information can be written out once, without needing to have control access to every resource on the web that the app could have access to. I described this better in [Interop Panel Meeting 2021-02-02](https://github.com/solid/data-interoperability-panel/blob/master/meetings/2021-02-02.md).
### Application determining access privileges
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-client-determine-access-privileges
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-client-determine-access-privileges
* +1 csarven: Required for [ap]. [d].
* +1 hindia:
@@ -541,7 +550,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-client-determine-ac
## Privacy
### Limiting access to who else is permitted
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-whopermitted
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-whopermitted
* +1 justinwb: Privacy in this context in paramount, unless the controller
specifically wants the information to be divulged.
@@ -554,7 +563,7 @@ specifically wants the information to be divulged.
* +1 bblfish: public [si] [ai]
### Limiting access to other authorization conditions
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-historyofchanges
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-historyofchanges
* +1 justinwb: Privacy in this context in paramount, unless the controller
specifically wants the information to be divulged.
@@ -567,7 +576,7 @@ specifically wants the information to be divulged.
* 0 bblfish: A bit too vague. This may just be a case of making the filtering rules invisible to either user. Filtering is orthogonal to access control, and filters can themselves be access controlled.
### Minimal Credential Disclosure
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-minimalcredentials
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-minimalcredentials
* +0 justinwb: This scenario is legitimate though I believe we'll likely
get to VC in the next cycle.
@@ -578,10 +587,11 @@ get to VC in the next cycle.
in a wallet spec or implementation guide.
* +3 bblfish: public [si] [ai]: this is very much a requirement on the server not the client. Without it we cannot secure privacy for the client across pods, as clients would constantly have to present for each remote resource every ID it has, even when none are valid.
* +0 csarven: "minimal" is unclear. Client to present only one credential? Least "sensitive" - what criteria? Exact/Close match (schema) of what's allowed? Good UC to support. Not essential for [ap]. I don't plan to implement it.
+* +2 bblfish: [si] [ac] re: csarven, reasoning about credentials is difficult I agree, so there should be a library that does all that type of work. That is what the [Launcher App](https://github.com/solid/authorization-panel/blob/master/proposals/LauncherApp.md) or something like it is meant to do.
### Limit information disclosure through URI
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-limituri
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-limituri
* 0 justinwb: I'm not positive this is a use case for the authorization
system as much as how the resource server itself organizes and/or
@@ -593,12 +603,12 @@ represents data.
* +1 hindia:
* +0 dmitrizagidulin: Doesn't belong in authorization, this should be in the
server spec security/privacy considerations section.
-* +3 bblfish: [si] [ai] This is essential to make sure that authorization is completely based on follow your nose principles, not on pattern matching URLs or other implicit assumptions. Having a Tor based Solid Server should make for excellent demos at security conferences, ie conferences where the audience we need to convince go. Putting a Solid Server behind Tor should not be a lot of work, neither should creating a UUID to Resource mapping.
+* +3 bblfish: [si] [ai] This is essential to make sure that authorization is completely based on follow your nose principles, not on pattern matching URLs or other implicit assumptions. Having a Tor based Solid Server should make for excellent demos at security conferences, ie conferences where the audience we need to convince go. Putting a Solid Server behind Tor should not be a lot of work, neither should creating a UUID to Resource mapping. Note that I also defend the idea of [full use of relative URLs in Solid](https://github.com/solid/specification/issues/194) which I believe is compatible with this.
## Trust
### Only trust certain issuers of identity
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-trustedissuers
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-trustedissuers
* +0 justinwb: Makes the authenticated agent use case more reasonable to me
* +1 elf-pavlik:
@@ -608,17 +618,17 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-trustedissuers
* +1 hindia:
* -0 dmitrizagidulin: Seems like a very specific use case (a special case of
allowing access by group).
-* +0 bblfish: agree with dmitri, but still useful. Door should be left open to it, and perhaps wait until the situation arises where people demand it.
+* +0 bblfish: agree with dmitri, but still useful. This is actually a case of restrictions on issuers, which is the (nearly) the only thing TLS client certificate negotition allows.
### Block access to agents
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-blockagents
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-blockagents
* +1 dmitrizagidulin: Seems reasonable.
* +1 csarven: Wide use re: support healthy community and debate. Useful for [ap]. May [d].
* +1 bblfish: public [si] [ai]
## Validation
-URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-validation
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#uc-validation
* +1 justinwb: This just seems like good engineering practice to me
* 0 csarven: Not sure why this UC is here or what's expected of it other than making sure server only processes valid authorization policies and in its absence all access is denied.
@@ -629,12 +639,13 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-validation
## Capabilities
### Possession of a group membership verifiable credential
-URL: https://solid.github.io/authorization-panel/wac-ucr/#group-membership-vc
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#group-membership-vc
* 0 csarven: Some use but not essential for [ap]. I don't plan to implement it.
+* +1 bblfish: This is actually quite advanced, but I think it can be done elegantly summarized in the meetings notes for [2021-01-27](https://github.com/solid/authorization-panel/blob/master/meetings/2021-01-27.md).
### Possession of a verifiable credential
-URL: https://solid.github.io/authorization-panel/wac-ucr/#capabilities-vc
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#capabilities-vc
* +0 justinwb: Definitely seems to be a key part of the future of access
control for us.
@@ -649,7 +660,7 @@ control for us.
* +1 bblfish: very important to keep in mind. May not be possible to get this through the first version, though I would like to try.
### Possession of a link
-URL: https://solid.github.io/authorization-panel/wac-ucr/#capabilities-link
+URL: https://solid.github.io/authorization-panel/authorization-ucr/#capabilities-link
* +0 justinwb: Can be extremely beneficial in scenarios like invitation
flows or one-time shares.
@@ -659,4 +670,4 @@ flows or one-time shares.
* +1 KaiGilb: graphMetrix (maybe +1)
* +1 hindia: love this too
* +1 dmitrizagidulin: Essential for shares.
-* +0 bblfish: interesting use case. This could be just that the resource is read/write to everyone? (+if needed making the URL obscure). Or is the server meant to detect a redirect?
+* +0 bblfish: interesting use case. This could be just that the resource is read/write to everyone? (+if needed making the URL obscure). Or is the server meant to detect a redirect? If it requires the user to go through a user interface as done on Google according to Dmitri, then this may not be scalable. So it needs to be tied in with some machine readable system where the client auth app can automate some tasks when authorized by a users' policy.
diff --git a/proposals/wac-ucr/.on-save.json b/proposals/wac-ucr/.on-save.json
new file mode 100644
index 00000000..4656cc31
--- /dev/null
+++ b/proposals/wac-ucr/.on-save.json
@@ -0,0 +1,10 @@
+[
+ {
+ "srcDir": ".",
+ "destDir": ".",
+ "showOutput": "true",
+ "showError": "true",
+ "files": "index.bs",
+ "command": "bikeshed spec index.bs"
+ }
+]