From 48f530df8f0f105c062325a34904c86193cff642 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Thu, 9 Jul 2020 13:10:29 -0400 Subject: [PATCH 01/19] add initial definitions --- proposals/wac-ucr/index.bs | 88 +++++++++++++++++++++++++++++++++++++- 1 file changed, 86 insertions(+), 2 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 31ade131..d86d3b81 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -42,5 +42,89 @@ This is where we explain the use case. Definitions {#definitions} ===================== -A Definition can be defined here and then referenced throughout -the rest of the document. +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 can prove 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=]. + +An application identity is used to uniquely identify a given +[=application=], represented by a unique [[URI]]. + +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 networked system that provides an +interface to make [=resources=] available to [=agents=] and [=applications=], +with the ability to secure access to those [=resources=] +through associated [=acl resources=]. + +A resource is a set of data identified via a [[URI]]. + +A collection is a [=resource=] that is representative of a set +of other [=resources=], which may include other [=collections=]. + +An acl resource is a [=resource=] that includes one or more +[=authorization statements=] applied to one or more [=resources=]. + +An authorization statement is an expression included in +an [=acl resource=] that identfies permitted [=access modes=] to +[=authorization targets=] by [=authorization subjects=]. + +An authorization subject identifies the [=agent=] and/or +[=application=] that a given [=authorization statement=] applies to. + +An authorization target identifies the resources that a given +[=authorization statement=] applies to. + +An authorization group is a [=resource=] including +any combination of discrete [=authorization subjects=] and +[=authorization groups=], which can be included in an +[=authorization statement=] as an [=authorization subject=]. + +An access mode denotes a class of operations that an +[=authorization subject=] can perform on an [=authorization target=] in an +[=authorization statement=]. + +
+{
+  "wac": {
+    "href": "https://solid.github.io/specification/wac/",
+    "title": "Web Access Control"
+  },
+  "webid": {
+    "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
+    "title": "WebID 1.0",
+    "authors": [
+      "Tim Berners-Lee",
+      "Henry Story",
+      "Andrei Sambra"
+    ]
+  },
+  "did": {
+    "href": "https://www.w3.org/TR/did-core/",
+    "title": "Decentralized Identifiers (DIDs) v1.0",
+    "authors": [
+      "Drummond Reed",
+      "Manu Sporney",
+      "Dave Longley",
+      "Christopher Allen",
+      "Ryan Grant",
+      "Markus Sabadello"
+    ]
+  }
+}
+
From 07fe56c985c4a0227761ce8bd01604886fa92251 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Thu, 9 Jul 2020 13:13:08 -0400 Subject: [PATCH 02/19] remove stale reference --- proposals/wac-ucr/index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index d86d3b81..16640aad 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -19,7 +19,7 @@ MIT License Copyright 2019 - 2020 W3C Solid Community Group Introduction {#intro} ===================== -Introduction here, with an example of a [=Definition=]. +Introduction here. Requirements {#requirements} ===================== From 61c1ea2fbe3b3b7747448521aaba09d443079175 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Thu, 9 Jul 2020 13:35:58 -0400 Subject: [PATCH 03/19] add access mode definitions --- proposals/wac-ucr/index.bs | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 16640aad..cd1c4edc 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -99,6 +99,23 @@ An access mode denotes a class of operations that an [=authorization subject=] can perform on an [=authorization target=] in an [=authorization statement=]. +Read access is an [=access mode=] that allows the +[=authorization subject=] to the ability to read, but not modify, the +[=authorization target=]. + +Write access is an [=access mode=] that allows the +[=authorization subject=] to the ability to create, update, or delete the +[=authorization target=]. + +Append access is an [=access mode=] that allows the +[=authorization subject=] to add data to a resource, but not modify any +data that already exists. +[=authorization target=]. + +Control access is an [=access mode=] that allows the +[=authorization subject=] to view and modify [=acl resources=] associated +with an [=authorization target=]. + 
 {
   "wac": {

From d89013a658479cff2c2f05f1a837b76dc6f518b7 Mon Sep 17 00:00:00 2001
From: Justin Bingham 
Date: Thu, 9 Jul 2020 16:00:28 -0400
Subject: [PATCH 04/19] add authorization condition

---
 proposals/wac-ucr/index.bs | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs
index cd1c4edc..e9e32147 100644
--- a/proposals/wac-ucr/index.bs
+++ b/proposals/wac-ucr/index.bs
@@ -95,6 +95,11 @@ any combination of discrete [=authorization subjects=] and
 [=authorization groups=], which can be included in an
 [=authorization statement=] as an [=authorization subject=].
 
+An authorization condition provides additional criteria
+to be used in the evaluation of an [=authorization statement=], beyond
+the [=authorization subject=], [=authorization target=], and [=access modes=].
+
+
 An access mode denotes a class of operations that an
 [=authorization subject=] can perform on an [=authorization target=] in an
 [=authorization statement=].

From ccc047b647dc67c613248e9713c35bbbf20c826f Mon Sep 17 00:00:00 2001
From: Justin Bingham 
Date: Thu, 9 Jul 2020 16:51:48 -0400
Subject: [PATCH 05/19] link to RFC 7231

---
 proposals/wac-ucr/index.bs | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs
index e9e32147..f5455d59 100644
--- a/proposals/wac-ucr/index.bs
+++ b/proposals/wac-ucr/index.bs
@@ -72,7 +72,8 @@ interface to make [=resources=] available to [=agents=] and [=applications=],
 with the ability to secure access to those [=resources=]
 through associated [=acl resources=].
 
-A resource is a set of data identified via a [[URI]].
+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=].

From fc235e9469fabed347158df05328bec8ba7fbfb1 Mon Sep 17 00:00:00 2001
From: Justin Bingham 
Date: Mon, 13 Jul 2020 16:31:04 -0400
Subject: [PATCH 06/19] add basic resource, collection, inheritance,
 conditional ucs

---
 proposals/wac-ucr/index.bs | 720 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 712 insertions(+), 8 deletions(-)

diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs
index 31ade131..282602d5 100644
--- a/proposals/wac-ucr/index.bs
+++ b/proposals/wac-ucr/index.bs
@@ -2,7 +2,7 @@
 Title: Use Cases and Requirements for Web Access Control
 Shortname: wac-ucr
 Level: 1
-Max ToC Depth: 2
+Max ToC Depth: 3
 Status: w3c/ED
 Group: solid-cg
 URL: https://solid.github.io/authorization-panel/wac-ucr/
@@ -12,17 +12,41 @@ Abstract:
   Use Cases and Requirements for Web Access Control.
+ + +
MIT License Copyright 2019 - 2020 W3C Solid Community Group
Introduction {#intro} -===================== +================================================================================ Introduction here, with an example of a [=Definition=]. Requirements {#requirements} -===================== +================================================================================ ## Example Category ## {#example-category} @@ -30,17 +54,697 @@ Requirements {#requirements} Some detail on the example requirement. -Assert: Related Use Cases: [[#example-usecase]] +Assert: Related Use Cases: [[#uc-basic]] Use Cases {#usecases} -===================== +================================================================================ + +For the purposes of simplicity, the use cases herein assume that named +individuals (i.e. Alice, Bob, Carol, etc.) are authenticated and know +each other's identities, unless explicitly stated otherwise. + +## Basic resource access ## {#uc-basic} + +Alice has a private draft of her resume stored on the Web at +`https://alice.example/resume`. + +
+
Alice's resume at https://alice.example/resume
+ + + + + + + + + + + + + + + + + + + + + + + +
ResourceTypeDescription
`/resume`Single ResourceAlice's curriculum vitae
`/recommendations`Single ResourceRecommendations for Alice
+
+ +### Control access ### {#basic-control} + +Alice asks Bob to help make her resume more presentable. Alice must give +Bob access to do this, because it is private, and Alice is the only one who +can manage permissions for it. + +### Read-write access ### {#basic-write} + +Alice gives Bob permission to read and make changes to her resume, +which he does. + +### Read-append access ### {#basic-readappend} + +Danielle agrees to give Alice a reference to include on her resume. +Alice gives Danielle permission to read and add new data to the resume document, +without the ability to change anything that already exists within it. +Danielle adds a glowing reference to Alice's resume document. + +### Append-only access ### {#basic-appendonly} + +Alice has a widget on her resume that allows someone to "recommend" her. The +user have an authenticated identity, which is added to the `/recommendations` +resource. + +Alice has set the permissions on `/recommendations` so that anyone in her +group of known contacts has append-only access. Alice plans to make these +publicly readable later along with her resume. + +### Removing access ### {#basic-removing} + +Alice removes Bob and Danielle's access, since they've both finished +contributing. + +### Read only access ### {#basic-readonly} + +Alice has a job interview with Carol. Alice gives Carol read-only access +to her resume ahead of the interview. + +### Group access ### {#basic-group} + +Alice is now interviewing with people from multiple companies, including +Carol, Oscar, and Frank. + +To make it easier to keep track of them all, +Alice creates a group called `interviewing` and adds Carol, Oscar, and +Frank to the group. + +Alice removes their individual permissions from +her resume document, and replaces it with the `interviewing` group. + +Now she can add new interviewers to this group, and remove them when the +opportunity is no longer active, which is much more intuitive. + +### Public access ### {#basic-public} + +Alice decides her resume is ready to share with everyone, so she gives +read-only access to the public, and posts a link to it on several +job boards. + +## Basic collection access ## {#uc-collections} + +Note: These use cases are focused on access to the collection itself. Use +cases that focus on permissions related to resouces within the collection +are covered in [[#uc-inheritance]]. + +Alice has a project portfolio stored on the Web at +`https://alice.example/portfolio` +that she is able to furnish materials from as needed as she moves +through a job interview process. + +Her portfolio includes individual documents that she's produced, and +collections of deliverables from projects that she's worked on. + +
+
Contents of Alice's Project Portfolio at +https://alice.example/portfolio
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ResourceTypeDescription
`/portfolio/`CollectionIndividual documents she's produced, and collections + of deliverables from projects she's worked on.
`-- document1`Single ResourceIndividual document
`-- document2`Single ResourceIndividual document
`-- project1/`CollectionIndividual document
`---- documentA`Single ResourceProject document
`---- MovieA`Single ResourceProject movie file
`/opportunities/`CollectionStorage for descriptions of various different job opportunities + Alice is interested in
+
+ +### Read-only access to a Collection ### {#collection-readonly} + +Alice has identified a select group of companies that she'd like to +interview with for a new job. + +Alice has identified several companies that she'd like to work for, +as well as the specific people to contact at each one; Carol, Oscar, +and Frank. + +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 resource, which +is a collection. She only wants them to see detail about the portfolio +collection itself, and a listing of its contents, but not the contents of +the resources within it yet. + +She wants to know which of them are really interested based on who +asks her for more access to the portfolio contents. + +### Read-write access to a Collection ### {#collection-readwrite} + +Alice worked in the past with Milo, and they produced a document +which she has included in her portfolio; `/portfolio/document1`. + +Alice realized that she doesn't have the most up-to-date version of the +document, and needs Milo to replace it. She gives Milo read access and +write access to her portfolio collection itself, which allows him to +see the listing of its contents, as well as add and remove items from it. +He cannot read the contents of any of the resources in the collection, +but this is fine, since he knows the name of the resource he's replacing. + +Milo deletes `/portfolio/document1`, and replaces it with an updated +version at `/portfolio/document1`. + +### Read-append access to a Collection ### {#collection-readappend} + +Alice worked with Bob in the past on a project, and she stored the +resulting deliverables she had in the `/portfolio/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 items to it. +He can't see the contents of the items, or remove anything in the list. +That's fine because he only needs to add the items that aren't included. + +### Append-only access to a Collection ### {#collection-appendonly} + +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, without the ability to see +the listing of other resources in the collection, or modify them. This means +that they can each add descriptions, but none of the others will see them. + +### Control access to 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 her portfolio, but needs to +lookup their information. + +Alice trusts Bob with the contents of the `project1` collection, since its +the output of their shared work. She gives him `control` permission +so that he can help her invite some of their other past colleagues to +add resources to it. + +## Inheritance ## {#uc-inheritance} + +Bob is leading a group of colleagues doing field research. The group +includes Charles, Felicia, Juan, and Irene. + +The group uses a data library for storing their information at +`https://research.example/library`, which Bob administers. Bob has full +control over data authorizations. + +Bob created an authorization group called `research`, and added Charles, +Felicia, Juan, and Irene. + +
+
Contents of the research group's data library at +https://research.example/library
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ResourceTypeDescription
`/data/`CollectionBob's data library related to his research work
`-- weekly-status/`CollectionBob's notes from weekly status meetings with colleagues
`---- 12-23-2019.note`CollectionText stored in collection resource, subordinate data + and media included in collection
`------ recording.mp4`Audio/VideoRecorded audio/video of web conference meeting
`---- 12-30-2019.note`CollectionText stored in collection resource, subordinate data + and media included in collection
`------ img1.png`ImageInline picture included in text of note
`------ img2.png`ImageInline picture included in text of note
`------ recording.mp4`Audio/VideoRecorded audio/video of web conference meeting
`---- 01-06-2020.note`CollectionText stored in collection resource, subordinate data + and media included in collection
`------ recording.mp4`Audio/VideoRecorded audio/video of web conference meeting
`-- daily-metrics/`CollectionDaily device reading for group research
`---- Jan-01-2020`Single ResourceDaily reading
`---- Jan-02-2020`Single ResourceDaily reading
`---- Jan-03-2020`Single ResourceDaily reading
`---- Jan-04-2020`Single ResourceDaily reading
`---- Jan-05-2020`Single ResourceDaily reading
`---- Jan-06-2020`Single ResourceDaily reading
`---- Jan-07-2020`Single ResourceDaily reading
`-- daily-analysis/`CollectionDaily analysis for group research
`---- Jan-01-2020`Single ResourcePeer reviewed analysis for Jan 1
`---- Jan-02-2020`Single ResourcePeer reviewed analysis for Jan 2
`---- Jan-03-2020`Single ResourcePeer reviewed analysis for Jan 3
+
+ +### Read-only access to collection of resources ### {#inheritance-readonly} + +Bob has a weekly status meeting with the `research` group. + +Bob is a diligent notetaker, which his colleagues appreciate. He's happy +to share his notes with them, but 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 +`/data/weekly-status` collection. + +He grants the `research` group inherited read access +to the `/data/weekly-status` collection, which means they can read specific +details about the collection, see a listing of it contents +(e.g. Bob's notes), and read the contents of each note. This is especially +important because each Note is actually a collection, capable of storing +inline data or attachments like pictures and audio/video media. + +Because the read access is set at the collection and inherited, it will apply +to everything already in the collection, as well as anything that will be +added in the future. + +### Read-append access to collection resources ### {#inheritance-readappend} + +Every day, someone in the group is responsible for recording data from +devices in the field, and storing those metrics in `/data/daily-metrics`. + +Bob gives the `research` authorization group inherited append access to the +`/data/daily-metrics` collection. This allows anyone in the group to +see the contents of the collection, and add readings. They cannot modify +readings after they are recorded to provide confidence that +readings are not manipulated after the fact. + +### Read-write access to collection resources ### {#inheritance-readwrite} + +The members of the `research` group work together on a daily summary where +they analyze the field readings stored in `/data/daily-summaries`, and +detail any new, validated, or invalidated hypotheses. + +Bob gives the `research` group inherited read access and write access to the +`/data/daily-summaries` collection. This allows anyone in the group to +see the contents of the collection and collaborate on a given day's summary, +updating the contents together until they're satisfied with the results. + +### Append-only access to collection resources ### {#inheritance-appendonly} + +Bob purchases a new field device that is able to automatically push data +into daily metric readings in `/data/daily-metrics`. + +Bob gives the field device read access on the `/data/daily-metrics` so it +can access the list of resources inside, and inherited append access to +`/data/daily-metrics`, which allows it to add to a daily-metric resource if it +already exists, or create a new one if the `research` group hasn't made +one for the day yet. + +### Control access to collection resources ### {#inheritance-control} + +Bob realizes that he needs some help administering the data library. He +provides Carol with inherited control access to the research data library +at `/data`, allowing her to manage permissions for all of the resources +and collections included within it. + +### Default permissions on created resources ### {#inheritance-defaultcreated} + +Since Bob is granting inherited permissions to the `research` group at +the collection level for `/data/daily-summaries` and `/data/daily-metrics` +that include the ability to add resources (write / append), 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 that any resources created echo the permissions that whoever +created that resource had, but in certain circumstances, he'd like to be +able to specify this in more granular fashion. + +### Adding new subjects to inherited permissions ### {#inheritance-adding} + +Note: Adding a new authorization subject means we are adding a new person / +group / application to the collection that isn't already part of an +inherited rule. Modifying permissions for these kinds of subjects is +covered in [[#inheritance-modifying]]. + +Bob has given inherited read-access to the weekly-status collection, +to the `research` group, outlined in [[#inheritance-readonly]]. + +Celeste isn't a regular member of the `research` group but happened +to join a weekly status meeting on December 30th, 2019. + +Bob would like to give Celesete 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` group, +who have inherited read access on everything in `/data/weekly-status`, and +anything that is added to it. + +Effective access to `12-30-2019.note` should be that `Celeste` and the +members of the `research` 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` group doesn't change. + +### Modifying inherited permissions for existing subjects ### {#inheritance-modifying} + +On the January 6th weekly status meeting, the Bob and the `research` 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 meetings +notes for that session at `/data/weekly-status/01-06-2020.note`. + +Effective access to `/data/weekly-status/01-06-2020.note` then becomes +the inherited read access to the `research group` (which Felicia is part of), +minus Felicia. Felicia continues to have inherited read access to all other +existing resources in the `/data/weekly-status` collection, and any new +resources added to it. Access for others in the `research` group (inherited +read access) is unchanged. + +### Forcing inherited permissions ### {#inheritance-forcing} + +As the primary administrator of the data library, 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 system, he wants to ensure +that she's not able to cut out his access, and that he's always in a position +to maintain a minimum of read access and control access to all of the resources +in the data library. This allows him to have visibility into +ever resource, and change their permissions as needed. + +## Conditional access ## {#uc-conditional} + +Felicia works for an organization that conducts clinical trials, and +leads a team that processes and synthesizes incoming data from +trial participants of the `Acme` trial. + +Felicia administers the +data repository for the `Acme` trial as part of her responsibilities, +which includes managing authorized access to that data repository for +her colleagues, and a group of research interns. + +
+
Contents of `/measurements` collection
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ResourceTypeDescription
`/measurements/`CollectionMeasurements for all trial participants across all trials
`-- meas-123-03052020`Single ResourceIndividual measurement
`-- meas-431-03052020`Single ResourceIndividual measurement
`-- meas-974-03052020`Single ResourceIndividual measurement
`-- meas-153-03052020`Single ResourceIndividual measurement
`-- meas-755-03052020`Single ResourceIndividual measurement
`-- meas-644-03052020`Single ResourceIndividual measurement
`-- meas-031-03052020`Single ResourceIndividual measurement
`-- meas-858-03052020`Single ResourceIndividual measurement
`-- ...`-Collection includes thousands of measurements
+
+ +### 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 an expiration condition to all of Erin's authorization grants +on the to allows them to remain valid only through June 30th, 2020. + +### 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 that collection, as well as measurements +that have already been processed. + +* Each measurement in `measurements` is tagged with the trial it belongs to +* 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 to +`/measurements`, with the condition that the resources must: + +* **include** the `Acme` tag +* **exclude** the `processed` tag + +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 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 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 record, the +response will exclude the fields containing PII. + + +## Permissioning Applications ## {#uc-applications} + +Issue: write section for permissioning applications. + +## Privacy ## {#uc-privacy} + +Issue: complete section on privacy + +### Limiting access to who else is permitted ### {#uc-whopermitted} + +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 its important they don't know who she has shared +her resume with, or see the history of changes made by other parties +that would similarly expose Carol and Oscar. + +### Limiting access to historic metadata ### {#uc-historyofchanges} + +TBD + +### Limiting access to permission conditions ### {#uc-permconditions} + +EXAMPLE - Alice doesn't want Bob to know that he only have access to the +safe for work stuff in her portfolio (i.e. without the nsfw tag) + +## Trust ## {#uc-trust} + +### Only trust certain issuers of identity ### {#uc-trustedissuers} + +Issue: Write cases where the resource controller must trust certain other +parties like identity providers, or people and the apps they use + +## Validation ## {#uc-validation} + +Issue: Write section on validation - poorly formed access control rules, +or illogical access control rules. + +## Capabilities ## {#uc-capabilities} + +Issue: Add use case on verifiable credentials -## Example Use Case ## {#example-usecase} +Issue: Add use case on arriving with a link -This is where we explain the use case. Definitions {#definitions} -===================== +================================================================================ A Definition can be defined here and then referenced throughout the rest of the document. From ea9ac8206451ad3d08988a181bbd8c1a49f72824 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Mon, 13 Jul 2020 22:43:21 -0400 Subject: [PATCH 07/19] add apps, privacy, trust, validation, and capabilities --- proposals/wac-ucr/index.bs | 169 +++++++++++++++++++++++++++++++------ 1 file changed, 144 insertions(+), 25 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 282602d5..81e2808d 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -647,7 +647,7 @@ her colleagues, and a group of research interns. -### Conditional access by time +### Conditional access by time ### {#conditional-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 @@ -660,7 +660,7 @@ participants across all trials. Felicia adds an expiration condition to all of Erin's authorization grants on the to allows them to remain valid only through June 30th, 2020. -### Conditional access by tag +### Conditional access by tag ### {#conditional-tag} As a research intern, Erin is responsible for processing all unprocessed measurements for the `Acme` trial in `/measurements`. However, there @@ -681,7 +681,7 @@ 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 filter +### Conditional access by filter ### {#conditional-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 @@ -696,55 +696,174 @@ response will exclude the fields containing PII. ## Permissioning Applications ## {#uc-applications} -Issue: write section for permissioning applications. +Oscar has financial data and health data stored at `https://oscar.example/`. -## Privacy ## {#uc-privacy} +* Oscar uses `FinanceApp` to manage his financial data. +* Oscar uses `HealthApp` to manage his health data. + +
+
Contents of Oscar's data store
+ + + + + + + + + + + + + + + + + + + + + + + +
ResourceTypeDescription
`/financial/`CollectionOscar's financial data
`/health/`CollectionOscar's financial data
+
-Issue: complete section on privacy +Notwithstanding his trusted applications that help him manage his data +and access to it, Oscar wants to explicitly specify that only `FinanceApp` +can be used with his credentials to access his financial data, and only +`HealthApp` can be used to access his health data. -### Limiting access to who else is permitted ### {#uc-whopermitted} +## Privacy ## {#uc-privacy} -Alice is interviewing for a job with Carol +### Limiting access to who else is permitted ### {#uc-whopermitted} -Alice is also interviewing for a job with Oscar, Carol's direct competitor. +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 its important they don't know who she has shared -her resume with, or see the history of changes made by other parties -that would similarly expose Carol and Oscar. - -### Limiting access to historic metadata ### {#uc-historyofchanges} - -TBD +with both of them, so it's important neither Carol or Oscar know who +Alice has shared her resume with, despite having read access to it. -### Limiting access to permission conditions ### {#uc-permconditions} +### Limiting access to other authorization conditions ### {#uc-historyofchanges} -EXAMPLE - Alice doesn't want Bob to know that he only have access to the -safe for work stuff in her portfolio (i.e. without the nsfw tag) +As an extension of [[#uc-whopermitted]], it is also important to Alice that +that neither Carol nor Oscar be able to discern other characteristics of +the authorization rules or conditions associated with them. For example, +if the data Carol and Oscar saw in the resume was +[[#conditional-filter|filtered]] to only show a certain subset of her +background, she wouldn't want them to know that. ## Trust ## {#uc-trust} ### Only trust certain issuers of identity ### {#uc-trustedissuers} -Issue: Write cases where the resource controller must trust certain other -parties like identity providers, or people and the apps they use +Carol has a blog, and allows anyone with an authenticated web identity +(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. ## Validation ## {#uc-validation} -Issue: Write section on validation - poorly formed access control rules, -or illogical access control rules. +Juan likes to manage his authorization statements manually. Every +once in a while, Juan makes a typo, or accidentally saves the resource +in an incomplete state. + +When this happens to Juan on systems where the Web Access Control +implementation doesn't have proper validation, he often runs into trouble, +most often by getting locked out of the resource and required administrator +assistance to recover. ## Capabilities ## {#uc-capabilities} -Issue: Add use case on verifiable credentials +### Possession of a verifiable credential ### {#capabilities-vc} + +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 authorization 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. -Issue: Add use case on arriving with a link +### Possession of a link ### {#capabilities-link} +Bob is about to give a confidential presentation to a group of his +colleagues. His presentation is stored on his private 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 +xauthorization. Luckily, his authorization system supports a link-based +authorization capability. + +Bob quickly creates an authorization rule for `https://bob.example/presentation` +that allows anyone in possession of a specially generated link to access +the document with read-only permissions. He sets it to +[[#conditional-time|expire]] in three hours. Bob gives the link to Anne +and the presentation goes off perfectly. + +Conventional WAC Limitations {#limitations} +================================================================================ + +Conventional Web Access Control does not satisfy the following use cases: + +* [[#inheritance-adding]] +* [[#inheritance-modifying]] +* [[#inheritance-forcing]] +* [[#conditional-time]] +* [[#conditional-tag]] +* [[#conditional-filter]] +* [[#uc-applications]] +* [[#uc-trustedissuers]] +* [[#uc-validation]] +* [[#capabilities-vc]] +* [[#capabilities-link]] Definitions {#definitions} ================================================================================ A Definition can be defined here and then referenced throughout the rest of the document. + +
+{
+  "webid": {
+    "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
+    "title": "WebID 1.0",
+    "authors": [
+      "Tim Berners-Lee",
+      "Henry Story",
+      "Andrei Sambra"
+    ]
+  },
+  "did": {
+    "href": "https://www.w3.org/TR/did-core/",
+    "title": "Decentralized Identifiers (DIDs) v1.0",
+    "authors": [
+      "Drummond Reed",
+      "Manu Sporney",
+      "Dave Longley",
+      "Christopher Allen",
+      "Ryan Grant",
+      "Markus Sabadello"
+    ]
+  }
+}
+
From 172eb2bcc4b89d8cfffd73852ac5aa568cff449a Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Mon, 13 Jul 2020 23:08:24 -0400 Subject: [PATCH 08/19] fix incorrect annotation --- proposals/wac-ucr/index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 81e2808d..5f9ce362 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -723,7 +723,7 @@ Oscar has financial data and health data stored at `https://oscar.example/`. `/health/` Collection - Oscar's financial data + Oscar's health data From e3a6504351fb54becf02a2aca08b0e7c9b94353e Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Tue, 14 Jul 2020 16:54:47 -0400 Subject: [PATCH 09/19] add introduction --- proposals/wac-ucr/index.bs | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 5f9ce362..28521948 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -2,7 +2,7 @@ Title: Use Cases and Requirements for Web Access Control Shortname: wac-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/ @@ -43,30 +43,35 @@ MIT License Copyright 2019 - 2020 W3C Solid Community Group Introduction {#intro} ================================================================================ -Introduction here, with an example of a [=Definition=]. +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. Requirements {#requirements} ================================================================================ +Issue: Populate requirements based on established use cases. + ## Example Category ## {#example-category} ### This is an example requirement ### {#example-requirement} -Some detail on the example requirement. - Assert: Related Use Cases: [[#uc-basic]] Use Cases {#usecases} ================================================================================ For the purposes of simplicity, the use cases herein assume that named -individuals (i.e. Alice, Bob, Carol, etc.) are authenticated and know -each other's identities, unless explicitly stated otherwise. +individuals (i.e. Alice, Bob, Carol, etc.) are already authenticated, and +their corresponding identities are known by the resource controller when +they are granted access. ## Basic resource access ## {#uc-basic} -Alice has a private draft of her resume stored on the Web at -`https://alice.example/resume`. +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 document.
Alice's resume at https://alice.example/resume
From c7b2f5be3d0f13c13602c5378dc70dafb391a80c Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Tue, 14 Jul 2020 22:19:59 -0400 Subject: [PATCH 10/19] cleanup basic resource access --- proposals/wac-ucr/index.bs | 91 ++++++++++++++++++++++---------------- 1 file changed, 53 insertions(+), 38 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 78a4a3cc..8141b874 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -2,7 +2,7 @@ Title: Use Cases and Requirements for Web Access Control Shortname: wac-ucr Level: 1 -Max ToC Depth: 2 +Max ToC Depth: 3 Status: w3c/ED Group: solid-cg URL: https://solid.github.io/authorization-panel/wac-ucr/ @@ -32,6 +32,10 @@ Abstract: text-align: left; } + a[data-link-type=dfn] { + color: #000000; + } + } @@ -63,18 +67,18 @@ Use Cases {#usecases} ================================================================================ For the purposes of simplicity, the use cases herein assume that named -individuals (i.e. Alice, Bob, Carol, etc.) are already authenticated, and -their corresponding identities are known by the resource controller when -they are granted access. +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. ## 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 -for that document. +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 at https://alice.example/resume
+
Alice's resume and recommendations resources at https://alice.example
@@ -104,60 +108,71 @@ for that document. ### Control access ### {#basic-control} Alice asks Bob to help make her resume more presentable. Alice must give -Bob access to do this, because it is private, and Alice is the only one who -can manage permissions for it. +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-write access ### {#basic-write} -Alice gives Bob permission to read and make changes to her resume, -which he does. +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} -Danielle agrees to give Alice a reference to include on her resume. -Alice gives Danielle permission to read and add new data to the resume document, -without the ability to change anything that already exists within it. -Danielle adds a glowing reference to Alice's resume document. +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`. ### Append-only access ### {#basic-appendonly} -Alice has a widget on her resume that allows someone to "recommend" her. The -user have an authenticated identity, which is added to the `/recommendations` -resource. +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. -Alice has set the permissions on `/recommendations` so that anyone in her -group of known contacts has append-only access. Alice plans to make these -publicly readable later along with her resume. +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 no [=read access=], they can only add to that `recommendations`, they +cannot see recommendations that have already been added. ### Removing access ### {#basic-removing} -Alice removes Bob and Danielle's access, since they've both finished -contributing. +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-only access -to her resume ahead of the interview. +Alice has a job interview with Carol. Alice gives Carol [=read access=] +to `resume` ahead of the interview. ### Group access ### {#basic-group} -Alice is now interviewing with people from multiple companies, including -Carol, Oscar, and Frank. +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 them all, -Alice creates a group called `interviewing` and adds Carol, Oscar, and -Frank to the group. +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 their individual permissions from -her resume document, and replaces it with the `interviewing` 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 she can add new interviewers to this group, and remove them when the -opportunity is no longer active, which is much more intuitive. +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. ### Public access ### {#basic-public} -Alice decides her resume is ready to share with everyone, so she gives -read-only access to the public, and posts a link to it on several +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. ## Basic collection access ## {#uc-collections} @@ -869,7 +884,7 @@ 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 networked system that provides an +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 [=acl resources=]. From 8d1a3ad9127a6376c2eeba9d9372b270d9e12d48 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Tue, 14 Jul 2020 23:00:27 -0400 Subject: [PATCH 11/19] cleanup basic collection access --- proposals/wac-ucr/index.bs | 130 +++++++++++++++++++------------------ 1 file changed, 67 insertions(+), 63 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 8141b874..58bba62d 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -92,13 +92,13 @@ for that resource. - - + + - - + + @@ -145,7 +145,7 @@ cannot see recommendations that have already been added. 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} +### Read-only access ### {#basic-readonly} Alice has a job interview with Carol. Alice gives Carol [=read access=] to `resume` ahead of the interview. @@ -177,21 +177,22 @@ job boards. ## Basic collection access ## {#uc-collections} -Note: These use cases are focused on access to the collection itself. Use -cases that focus on permissions related to resouces within the collection -are covered in [[#uc-inheritance]]. +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 [[#uc-inheritance]]. -Alice has a project portfolio stored on the Web at -`https://alice.example/portfolio` -that she is able to furnish materials from as needed as she moves -through a job interview process. +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. -Her portfolio includes individual documents that she's produced, and -collections of deliverables from projects that she's worked on. +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.
-
Contents of Alice's Project Portfolio at -https://alice.example/portfolio
+
Alice's portfolio and opportunities [=collections=] at +https://alice.example/
`/resume`Single Resource`resume`[=Resource=] Alice's curriculum vitae
`/recommendations`Single Resource`recommendations`[=Resource=] Recommendations for Alice
@@ -205,39 +206,39 @@ https://alice.example/portfolio - - + + - + - + - + - + - + - - + + @@ -247,53 +248,55 @@ https://alice.example/portfolio ### Read-only access to a Collection ### {#collection-readonly} -Alice has identified a select group of companies that she'd like to -interview with for a new job. - Alice has identified several companies that she'd like to work for, -as well as the specific people to contact at each one; Carol, Oscar, -and Frank. +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. +`resume` and `portfolio`. -Alice has granted Carol, Oscar, and Frank read access to her resume which +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 resource, which -is a collection. She only wants them to see detail about the portfolio -collection itself, and a listing of its contents, but not the contents of -the resources within it yet. +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 wants to know which of them are really interested based on who -asks her for more access to the portfolio contents. +Alice wants know which of them are really interested based on who +asks her for more access to the contents of `portfolio`. ### Read-write access to a Collection ### {#collection-readwrite} -Alice worked in the past with Milo, and they produced a document -which she has included in her portfolio; `/portfolio/document1`. +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=]. -Alice realized that she doesn't have the most up-to-date version of the -document, and needs Milo to replace it. She gives Milo read access and -write access to her portfolio collection itself, which allows him to -see the listing of its contents, as well as add and remove items from it. -He cannot read the contents of any of the resources in the collection, -but this is fine, since he knows the name of the resource he's replacing. +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 deletes `/portfolio/document1`, and replaces it with an updated -version at `/portfolio/document1`. +Milo updates the contents of `document1` to the most recent version. ### Read-append access to a Collection ### {#collection-readappend} -Alice worked with Bob in the past on a project, and she stored the -resulting deliverables she had in the `/portfolio/project1` 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 items to it. -He can't see the contents of the items, or remove anything in the list. -That's fine because he only needs to add the items that aren't included. +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. ### Append-only access to a Collection ### {#collection-appendonly} @@ -301,21 +304,22 @@ 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, without the ability to see -the listing of other resources in the collection, or modify them. This means -that they can each add descriptions, but none of the others will see them. +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. ### Control access to 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 her portfolio, but needs to +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 its -the output of their shared work. She gives him `control` permission -so that he can help her invite some of their other past colleagues to -add resources to it. +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. ## Inheritance ## {#uc-inheritance} From fa0b53ebad3e6e053852cb21d864b30605d1cea2 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Tue, 14 Jul 2020 23:55:24 -0400 Subject: [PATCH 12/19] cleanup inheritance --- proposals/wac-ucr/index.bs | 270 +++++++++++++++++++------------------ 1 file changed, 142 insertions(+), 128 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 58bba62d..85f1849c 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -323,19 +323,19 @@ add [=resources=] to it. ## Inheritance ## {#uc-inheritance} -Bob is leading a group of colleagues doing field research. The group +Bob is leading a group of colleagues doing field research. This group includes Charles, Felicia, Juan, and Irene. -The group uses a data library for storing their information at -`https://research.example/library`, which Bob administers. Bob has full -control over data authorizations. +The group uses a [=resource server=] for storing their information at +`https://research.example/`, which Bob administers as the +[=resource controller=]. -Bob created an authorization group called `research`, and added Charles, -Felicia, Juan, and Irene. +Bob creates an [=authorization group=] called `research`, and adds Charles, +Felicia, Juan, and Irene to it.
-
Contents of the research group's data library at -https://research.example/library
+
Contents of the research group's data store at +https://research.example/
`/portfolio/`Collection`portfolio/`[=Collection=] Individual documents she's produced, and collections of deliverables from projects she's worked on.
`-- document1`Single Resource[=Resource=] Individual document
`-- document2`Single Resource[=Resource=] Individual document
`-- project1/`Collection[=Collection=] Individual document
`---- documentA`Single Resource[=Resource=] Project document
`---- MovieA`Single Resource[=Resource=] Project movie file
`/opportunities/`Collection`opportunities/`[=Collection=] Storage for descriptions of various different job opportunities Alice is interested in
@@ -349,116 +349,111 @@ https://research.example/library - - - - - - - + + - - + + - - + + - - + + - + - + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - + - - + + - - + + - - + +
`/data/`CollectionBob's data library related to his research work
`-- weekly-status/`Collection`weekly-status/`[=Collection=] Bob's notes from weekly status meetings with colleagues
`---- 12-23-2019.note`Collection`-- 12-23-2019.note`[=Collection=] Text stored in collection resource, subordinate data and media included in collection
`------ recording.mp4`Audio/Video`---- recording.mp4`Video Recorded audio/video of web conference meeting
`---- 12-30-2019.note`Collection`-- 12-30-2019.note`[=Collection=] Text stored in collection resource, subordinate data and media included in collection
`------ img1.png``---- img1.png` Image Inline picture included in text of note
`------ img2.png``---- img2.png` Image Inline picture included in text of note
`------ recording.mp4`Audio/Video`---- recording.mp4`Video Recorded audio/video of web conference meeting
`---- 01-06-2020.note`Collection`-- 01-06-2020.note`[=Collection=] Text stored in collection resource, subordinate data and media included in collection
`------ recording.mp4`Audio/Video`---- recording.mp4`Video Recorded audio/video of web conference meeting
`-- daily-metrics/`Collection`daily-metrics/`[=Collection=] Daily device reading for group research
`---- Jan-01-2020`Single Resource`-- Jan-01-2020`[=Resource=] Daily reading
`---- Jan-02-2020`Single Resource`-- Jan-02-2020`[=Resource=] Daily reading
`---- Jan-03-2020`Single Resource`-- Jan-03-2020`[=Resource=] Daily reading
`---- Jan-04-2020`Single Resource`-- Jan-04-2020`[=Resource=] Daily reading
`---- Jan-05-2020`Single Resource`-- Jan-05-2020`[=Resource=] Daily reading
`---- Jan-06-2020`Single Resource`-- Jan-06-2020`[=Resource=] Daily reading
`---- Jan-07-2020`Single Resource`-- Jan-07-2020`[=Resource=] Daily reading
`-- daily-analysis/``daily-analysis/` Collection Daily analysis for group research
`---- Jan-01-2020`Single Resource`-- Jan-01-2020`[=Resource=] Peer reviewed analysis for Jan 1
`---- Jan-02-2020`Single Resource`-- Jan-02-2020`[=Resource=] Peer reviewed analysis for Jan 2
`---- Jan-03-2020`Single Resource`-- Jan-03-2020`[=Resource=] Peer reviewed analysis for Jan 3
@@ -466,131 +461,150 @@ https://research.example/library ### Read-only access to collection of resources ### {#inheritance-readonly} -Bob has a weekly status meeting with the `research` group. +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 share his notes with them, but doesn't want the overhead of granting +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 -`/data/weekly-status` collection. +`weekly-status` [=collection=]. -He grants the `research` group inherited read access -to the `/data/weekly-status` collection, which means they can read specific -details about the collection, see a listing of it contents -(e.g. Bob's notes), and read the contents of each note. This is especially -important because each Note is actually a collection, capable of storing -inline data or attachments like pictures and audio/video media. +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 the read access is set at the collection and inherited, it will apply -to everything already in the collection, as well as anything that will be -added in the future. +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. ### Read-append access to collection resources ### {#inheritance-readappend} Every day, someone in the group is responsible for recording data from -devices in the field, and storing those metrics in `/data/daily-metrics`. +devices in the field, and storing those metrics in `daily-metrics`. -Bob gives the `research` authorization group inherited append access to the -`/data/daily-metrics` collection. This allows anyone in the group to -see the contents of the collection, and add readings. They cannot modify -readings after they are recorded to provide confidence that -readings are not manipulated after the fact. +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. ### Read-write access to collection resources ### {#inheritance-readwrite} -The members of the `research` group work together on a daily summary where -they analyze the field readings stored in `/data/daily-summaries`, and -detail any new, validated, or invalidated hypotheses. +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` group inherited read access and write access to the -`/data/daily-summaries` collection. This allows anyone in the group to -see the contents of the collection and collaborate on a given day's summary, -updating the contents together until they're satisfied with the results. +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. ### Append-only access to collection resources ### {#inheritance-appendonly} -Bob purchases a new field device that is able to automatically push data -into daily metric readings in `/data/daily-metrics`. +Bob purchases a new field device that is able to automatically push daily +metric readings in `daily-metrics`. -Bob gives the field device read access on the `/data/daily-metrics` so it -can access the list of resources inside, and inherited append access to -`/data/daily-metrics`, which allows it to add to a daily-metric resource if it -already exists, or create a new one if the `research` group hasn't made -one for the day yet. +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 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. ### Control access to collection resources ### {#inheritance-control} -Bob realizes that he needs some help administering the data library. He -provides Carol with inherited control access to the research data library -at `/data`, allowing her to manage permissions for all of the resources -and collections included within it. +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. ### Default permissions on created resources ### {#inheritance-defaultcreated} -Since Bob is granting inherited permissions to the `research` group at -the collection level for `/data/daily-summaries` and `/data/daily-metrics` -that include the ability to add resources (write / append), it's important +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 that any resources created echo the permissions that whoever -created that resource had, but in certain circumstances, he'd like to be -able to specify this in more granular fashion. +Bob prefers to specify in granular fashion the default permissions of +created resources that should be assigned to any [=authorization statements=] +with [=write access=] or [=append access=] on a given [=collection=]. ### Adding new subjects to inherited permissions ### {#inheritance-adding} -Note: Adding a new authorization subject means we are adding a new person / +Note: Adding a new [=authorization subject=] means we are adding a new person / group / application to the collection that isn't already part of an -inherited rule. Modifying permissions for these kinds of subjects is -covered in [[#inheritance-modifying]]. +inherited [=authorization statement=]. Modifying permissions for these +kinds of [=authorization subjects=] is covered in [[#inheritance-modifying]]. -Bob has given inherited read-access to the weekly-status collection, -to the `research` group, outlined in [[#inheritance-readonly]]. +Bob has given the `research` [=authorization group=] inherited [=read access=] +to the `weekly-status` [=collection=] (detailed in [[#inheritance-readonly]]). -Celeste isn't a regular member of the `research` group but happened -to join a weekly status meeting on December 30th, 2019. +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 Celesete 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` group, -who have inherited read access on everything in `/data/weekly-status`, and -anything that is added to it. +Bob would like to give Celesete 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` 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` group doesn't change. +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. ### Modifying inherited permissions for existing subjects ### {#inheritance-modifying} -On the January 6th weekly status meeting, the Bob and the `research` 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. +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 meetings -notes for that session at `/data/weekly-status/01-06-2020.note`. +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 `/data/weekly-status/01-06-2020.note` then becomes -the inherited read access to the `research group` (which Felicia is part of), -minus Felicia. Felicia continues to have inherited read access to all other -existing resources in the `/data/weekly-status` collection, and any new -resources added to it. Access for others in the `research` group (inherited -read access) is unchanged. +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. ### Forcing inherited permissions ### {#inheritance-forcing} -As the primary administrator of the data library, 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 system, he wants to ensure -that she's not able to cut out his access, and that he's always in a position -to maintain a minimum of read access and control access to all of the resources -in the data library. This allows him to have visibility into -ever resource, and change their permissions as needed. +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. ## Conditional access ## {#uc-conditional} From aa7984f25f101920d0db05d2ad2816c6293355b8 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Wed, 15 Jul 2020 14:18:37 -0400 Subject: [PATCH 13/19] adjust authenticated agent definition --- proposals/wac-ucr/index.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 85f1849c..f38025e3 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -857,6 +857,7 @@ the document with read-only permissions. He sets it to [[#conditional-time|expire]] in three hours. Bob gives the link to Anne and the presentation goes off perfectly. + Conventional WAC Limitations {#limitations} ================================================================================ @@ -874,6 +875,7 @@ Conventional Web Access Control does not satisfy the following use cases: * [[#capabilities-vc]] * [[#capabilities-link]] + Definitions {#definitions} ================================================================================ @@ -887,7 +889,7 @@ 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 can prove control +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 From c3c3e628d798038fa8f271f1a2e3eced85852d12 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Wed, 15 Jul 2020 14:26:27 -0400 Subject: [PATCH 14/19] change conventional to legacy wac --- proposals/wac-ucr/index.bs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index f38025e3..d1decbe7 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -52,6 +52,10 @@ 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. +[[#limitations]] highlights the [[#usecases]] that +[Legacy Web Access Control](https://github.com/solid/web-access-control-spec) +fails to satisfy. + Requirements {#requirements} ================================================================================ @@ -858,10 +862,11 @@ the document with read-only permissions. He sets it to and the presentation goes off perfectly. -Conventional WAC Limitations {#limitations} +Limitations of Legacy Web Access Control {#limitations} ================================================================================ -Conventional Web Access Control does not satisfy the following use cases: +[Legacy Web Access Control](https://github.com/solid/web-access-control-spec) +does not satisfy the following use cases: * [[#inheritance-adding]] * [[#inheritance-modifying]] From b40126d29284473688c9c302d5e7eea08609d5e6 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Wed, 15 Jul 2020 15:43:24 -0400 Subject: [PATCH 15/19] cleanup conditions, privact, trust, validation, capabilities --- proposals/wac-ucr/index.bs | 126 +++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 54 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index d1decbe7..7b52f7de 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -568,9 +568,9 @@ without affecting the access that he's given to the `research` 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 +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 +[=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. @@ -614,12 +614,13 @@ visibility into everything, and change their permissions as needed. Felicia works for an organization that conducts clinical trials, and leads a team that processes and synthesizes incoming data from -trial participants of the `Acme` trial. +trial participants, including participants in the `Acme` trial. -Felicia administers the -data repository for the `Acme` trial as part of her responsibilities, -which includes managing authorized access to that data repository for -her colleagues, and a group of research interns. +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
@@ -637,47 +638,47 @@ her colleagues, and a group of research interns. `/measurements/` - Collection + [=Collection=] Measurements for all trial participants across all trials `-- meas-123-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-431-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-974-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-153-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-755-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-644-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-031-03052020` - Single Resource + [=Resource=] Individual measurement `-- meas-858-03052020` - Single Resource + [=Resource=] Individual measurement @@ -695,29 +696,32 @@ 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 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 an expiration condition to all of Erin's authorization grants -on the to allows them to remain valid only through June 30th, 2020. +Felicia adds a time-based [=authorization 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. ### Conditional access by tag ### {#conditional-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 that collection, as well as measurements -that have already been processed. +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. * Each measurement in `measurements` is tagged with the trial it belongs to * 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 to -`/measurements`, with the condition that the resources must: +Felicia authorizes Erin to have inherited [=read access=] and [=write access=] +to `measurements`, with an [=authorization condition=] that the [=resources=] +must: -* **include** the `Acme` tag -* **exclude** the `processed` tag +* **include** the `Acme` [=tag=] +* **exclude** the `processed` [=tag=] This allows Erin to work with new measurements for the `Acme` trial without being exposed to measurements from other trials, or already processed @@ -725,14 +729,15 @@ measurements from the `Acme` trial. ### Conditional access by filter ### {#conditional-filter} -Felicia has been able to limit the scope of the resources that Erin +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 PII for the trial participant associated with the measurement. -Felicia needs to ensure that Erin cannot access that PII. +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 record, the +measurement [=resources=]. When Erin retrieves a measurement, the response will exclude the fields containing PII. @@ -783,26 +788,30 @@ can be used with his credentials to access his financial data, and only 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. +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 -Alice has shared her resume with, despite having read access to it. +with both of them, so it's important neither Carol or Oscar know any of the +[=authorization subjects=] 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 that neither Carol nor Oscar be able to discern other characteristics of -the authorization rules or conditions associated with them. For example, -if the data Carol and Oscar saw in the resume was +the [=authorization statements=] or [=authorization conditions=] associated +with Alice's `resume`. + +For example, if the data Carol and Oscar saw in the resume was [[#conditional-filter|filtered]] to only show a certain subset of her -background, she wouldn't want them to know that. +background, she wouldn't want them to know that they were only seeing +a filtered view. ## Trust ## {#uc-trust} ### Only trust certain issuers of identity ### {#uc-trustedissuers} -Carol has a blog, and allows anyone with an authenticated web 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 @@ -811,14 +820,14 @@ identity providers. ## Validation ## {#uc-validation} -Juan likes to manage his authorization statements manually. Every -once in a while, Juan makes a typo, or accidentally saves the resource +Juan likes to manage his [=authorization statements=] manually. Every +once in a while, Juan makes a typo, or accidentally saves the [=acl resource=] in an incomplete state. -When this happens to Juan on systems where the Web Access Control -implementation doesn't have proper validation, he often runs into trouble, -most often by getting locked out of the resource and required administrator -assistance to recover. +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. ## Capabilities ## {#uc-capabilities} @@ -834,30 +843,31 @@ 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 authorization capability. +verifiable credential [=authorization 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 +[=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. His presentation is stored on his private server at +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 -xauthorization. Luckily, his authorization system supports a link-based -authorization capability. +Unfortunately, Anne doesn't have an [=identity=] ready to go that he can +authorize. Luckily, his authorization system supports a link-based +[=authorization capability=]. -Bob quickly creates an authorization rule for `https://bob.example/presentation` +Bob quickly creates an [=authorization statement=] for +`https://bob.example/presentation` that allows anyone in possession of a specially generated link to access -the document with read-only permissions. He sets it to +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. @@ -920,6 +930,9 @@ 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 acl resource is a [=resource=] that includes one or more [=authorization statements=] applied to one or more [=resources=]. @@ -930,6 +943,11 @@ an [=acl resource=] that identfies permitted [=access modes=] to An authorization subject identifies the [=agent=] and/or [=application=] that a given [=authorization statement=] applies to. +An authorization capability can be used in place of an +[=authorization subject=] in an [=authorization statement=]. It denotes +an object the [=agent=] must be in possesion of to satisfy the +[=authorization statement=]. + An authorization target identifies the resources that a given [=authorization statement=] applies to. From f94b65c3c2cc3d53f4fd96988c091f9a7a61e71d Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Wed, 15 Jul 2020 22:29:11 -0400 Subject: [PATCH 16/19] add control boundaries, update applications --- proposals/wac-ucr/index.bs | 77 +++++++++++++++++++++----------------- 1 file changed, 42 insertions(+), 35 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 7b52f7de..e1c17ff6 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -740,46 +740,52 @@ 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} -## Permissioning Applications ## {#uc-applications} +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. -Oscar has financial data and health data stored at `https://oscar.example/`. +Felicia grants Megan inherited [=control access=] to `measurements`, +with [=authorization conditions=] that stipulate: -* Oscar uses `FinanceApp` to manage his financial data. -* Oscar uses `HealthApp` to manage his health data. +* she only has effective [=control access=] of [=resources=] that include + the `Acme` [=tag=] within the `measurements` [=collection=]. +* she can only create or change [=authorization statements=] where + [=authorization subjects=] are in the `interns` [=authorization group=] + within the `measurements` [=collection=]. -
-
Contents of Oscar's data store
- - - - - - - - - - - - - - - - - - - - - - - -
ResourceTypeDescription
`/financial/`CollectionOscar's financial data
`/health/`CollectionOscar's health data
-
+## Permissioning Applications ## {#uc-applications} + +Oscar stores all of his data in a private [=resource server=] at +`https://oscar.example`, which he is the [=resource controller=] of. + +He stores a wide spectrum of things, from personal financial data to +collaborative projects that he works on with his friends and colleagues. + +Regardless of the use case, 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 has on `https://oscar.example`. + +It is important to Oscar that he can include [=applications=] +in the [=authorization subjects=] of his [=authorization statements=]. + +For example, to constrain Oscar's access to `https://oscar.example` to +only cases where an application he trusts is involved: + +* Oscar has [=read access=], [=write access=], and [=control access=] to + the `https://oscar.example` **with the** `trusted-applications` + [=authorization group=]. + +Following that, per [[#inheritance-modifying]], he could extend this default +for the `health` [=collection=] to include `healthapp`: + +* Oscar has [=read access=], [=write access=], and [=control access=] to + the `health` [=collection=] **with the** `trusted-applications` + [=authorization group=] AND `healthapp`. -Notwithstanding his trusted applications that help him manage his data -and access to it, Oscar wants to explicitly specify that only `FinanceApp` -can be used with his credentials to access his financial data, and only -`HealthApp` can be used to access his health data. ## Privacy ## {#uc-privacy} @@ -884,6 +890,7 @@ does not satisfy the following use cases: * [[#conditional-time]] * [[#conditional-tag]] * [[#conditional-filter]] +* [[#conditional-control]] * [[#uc-applications]] * [[#uc-trustedissuers]] * [[#uc-validation]] From d195aee7de94a3bb8c6f0402cadad02aaedc384a Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Wed, 15 Jul 2020 22:41:19 -0400 Subject: [PATCH 17/19] cleanup control boundaries and permissioning applications --- proposals/wac-ucr/index.bs | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index e1c17ff6..a8d937b3 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -752,39 +752,41 @@ with [=authorization conditions=] that stipulate: * she only has effective [=control access=] of [=resources=] that include the `Acme` [=tag=] within the `measurements` [=collection=]. -* she can only create or change [=authorization statements=] where - [=authorization subjects=] are in the `interns` [=authorization group=] - within the `measurements` [=collection=]. +* she can only create or change [=authorization statements=] + targeting the `measurements` [=collection=] where + [=authorization subjects=] are [=agents=] included in the `interns` + [=authorization group=]. ## Permissioning Applications ## {#uc-applications} Oscar stores all of his data in a private [=resource server=] at -`https://oscar.example`, which he is the [=resource controller=] of. +`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. -Regardless of the use case, as the [=resource controller=] for +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 has on `https://oscar.example`. +the same unfettered access that Oscar enjoys. It is important to Oscar that he can include [=applications=] -in the [=authorization subjects=] of his [=authorization statements=]. +in the [=authorization subjects=] of his [=authorization statements=] 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: -* Oscar has [=read access=], [=write access=], and [=control access=] to - the `https://oscar.example` **with the** `trusted-applications` - [=authorization group=]. +* Oscar **with the** `trusted-applications` [=authorization group=] has + [=read access=], [=write access=], and [=control access=] to + `https://oscar.example` Following that, per [[#inheritance-modifying]], he could extend this default for the `health` [=collection=] to include `healthapp`: -* Oscar has [=read access=], [=write access=], and [=control access=] to - the `health` [=collection=] **with the** `trusted-applications` - [=authorization group=] AND `healthapp`. +* Oscar **with the** `trusted-applications` [=authorization group=] AND + `healthapp` has [=read access=], [=write access=], and [=control access=] + to the `health` [=collection=] ## Privacy ## {#uc-privacy} From b7cd84e0496f85284981e2418f3a527ae4738472 Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Thu, 16 Jul 2020 10:21:01 -0400 Subject: [PATCH 18/19] move requirements after use cases --- proposals/wac-ucr/index.bs | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index a8d937b3..235d2c9e 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -56,17 +56,6 @@ Web Access Control specification. [Legacy Web Access Control](https://github.com/solid/web-access-control-spec) fails to satisfy. -Requirements {#requirements} -================================================================================ - -Issue: Populate requirements based on established use cases. - -## Example Category ## {#example-category} - -### This is an example requirement ### {#example-requirement} - -Assert: Related Use Cases: [[#uc-basic]] - Use Cases {#usecases} ================================================================================ @@ -879,6 +868,16 @@ 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} +================================================================================ + +Issue: Populate requirements based on established use cases. + +## Example Category ## {#example-category} + +### This is an example requirement ### {#example-requirement} + +Assert: Related Use Cases: [[#uc-basic]] Limitations of Legacy Web Access Control {#limitations} ================================================================================ @@ -899,7 +898,6 @@ does not satisfy the following use cases: * [[#capabilities-vc]] * [[#capabilities-link]] - Definitions {#definitions} ================================================================================ From 146c3c1b7987e86cd0592ca1e5b8f2cc495ed4dd Mon Sep 17 00:00:00 2001 From: Justin Bingham Date: Thu, 16 Jul 2020 22:26:02 -0400 Subject: [PATCH 19/19] remove excess structure from definitions --- proposals/wac-ucr/index.bs | 110 ++++++++++++++----------------------- 1 file changed, 42 insertions(+), 68 deletions(-) diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index 235d2c9e..6d08ab9f 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -507,7 +507,7 @@ 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 to `daily-metrics`, which allows it to add +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. @@ -534,15 +534,16 @@ 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 [=authorization statements=] +created resources that should be assigned to any [=authorizations=] with [=write access=] or [=append access=] on a given [=collection=]. ### Adding new subjects to inherited permissions ### {#inheritance-adding} -Note: Adding a new [=authorization subject=] means we are adding a new person / -group / application to the collection that isn't already part of an -inherited [=authorization statement=]. Modifying permissions for these -kinds of [=authorization subjects=] is covered in [[#inheritance-modifying]]. +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 [[#inheritance-modifying]]. Bob has given the `research` [=authorization group=] inherited [=read access=] to the `weekly-status` [=collection=] (detailed in [[#inheritance-readonly]]). @@ -550,7 +551,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 Celesete inherited [=read access=] to **only** the +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 @@ -689,7 +690,7 @@ 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 [=authorization condition=] for Erin which +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. @@ -706,7 +707,7 @@ as well as measurements that have already been processed. * When a new measurement is processed, it is tagged as `processed` Felicia authorizes Erin to have inherited [=read access=] and [=write access=] -to `measurements`, with an [=authorization condition=] that the [=resources=] +to `measurements`, with a condition that the [=resources=] must: * **include** the `Acme` [=tag=] @@ -737,14 +738,13 @@ 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 [=authorization conditions=] that stipulate: +with conditions that stipulate: * she only has effective [=control access=] of [=resources=] that include the `Acme` [=tag=] within the `measurements` [=collection=]. -* she can only create or change [=authorization statements=] +* she can only create or change [=authorizations=] targeting the `measurements` [=collection=] where - [=authorization subjects=] are [=agents=] included in the `interns` - [=authorization group=]. + [=agents=] are included in the `interns` [=authorization group=]. ## Permissioning Applications ## {#uc-applications} @@ -760,8 +760,7 @@ 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 the [=authorization subjects=] of his [=authorization statements=] to limit -this unfettered access. +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: @@ -788,15 +787,14 @@ 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 any of the -[=authorization subjects=] Alice has shared her `resume` with, -despite having [=read access=] to it. +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 that neither Carol nor Oscar be able to discern other characteristics of -the [=authorization statements=] or [=authorization conditions=] associated +the [=authorizations=] or conditions associated with Alice's `resume`. For example, if the data Carol and Oscar saw in the resume was @@ -817,8 +815,8 @@ identity providers. ## Validation ## {#uc-validation} -Juan likes to manage his [=authorization statements=] manually. Every -once in a while, Juan makes a typo, or accidentally saves the [=acl resource=] +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 @@ -840,7 +838,7 @@ 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 [=authorization capability=]. +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 @@ -859,9 +857,9 @@ 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 -[=authorization capability=]. +[=capability=]. -Bob quickly creates an [=authorization statement=] for +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 @@ -919,9 +917,6 @@ An application is a piece of software that interfaces with a [=authenticated agent=], or in piloted-fashion by another [=authenticated agent=]. -An application identity is used to uniquely identify a given -[=application=], represented by a unique [[URI]]. - 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. @@ -929,7 +924,7 @@ access and control over one or more [=resources=] residing on a 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 [=acl resources=]. +through associated [=authorizations=]. A resource is the target of an HTTP request identified by a [[URI]], as defined in [[!RFC7231]]. @@ -940,54 +935,33 @@ of other [=resources=], which may include other [=collections=]. A tag is a type of metadata associated with a [=resource=] for classification or identification. -An acl resource is a [=resource=] that includes one or more -[=authorization statements=] applied to one or more [=resources=]. - -An authorization statement is an expression included in -an [=acl resource=] that identfies permitted [=access modes=] to -[=authorization targets=] by [=authorization subjects=]. - -An authorization subject identifies the [=agent=] and/or -[=application=] that a given [=authorization statement=] applies to. - -An authorization capability can be used in place of an -[=authorization subject=] in an [=authorization statement=]. It denotes -an object the [=agent=] must be in possesion of to satisfy the -[=authorization statement=]. - -An authorization target identifies the resources that a given -[=authorization statement=] applies to. - -An authorization group is a [=resource=] including -any combination of discrete [=authorization subjects=] and -[=authorization groups=], which can be included in an -[=authorization statement=] as an [=authorization subject=]. +An authorization is a [=resource=] that controls access to +one or more [=resources=]. -An authorization condition provides additional criteria -to be used in the evaluation of an [=authorization statement=], beyond -the [=authorization subject=], [=authorization target=], and [=access modes=]. +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 -[=authorization subject=] can perform on an [=authorization target=] in an -[=authorization statement=]. +[=agent=] and/or [=application=] can perform on one or more [=resources=]. -Read access is an [=access mode=] that allows the -[=authorization subject=] to the ability to read, but not modify, the -[=authorization target=]. +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 the -[=authorization subject=] to the ability to create, update, or delete the -[=authorization target=]. +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 the -[=authorization subject=] to add data to a resource, but not modify any -data that already exists. -[=authorization target=]. +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 the -[=authorization subject=] to view and modify [=acl resources=] associated -with an [=authorization target=]. +Control access is an [=access mode=] that allows +[=agents=] and/or [=applications=] to view and modify [=authorizations=] +associated with a [=resource=]. 
 {