diff --git a/proposals/wac-ucr/index.bs b/proposals/wac-ucr/index.bs index f3e9ec92..69ccb359 100644 --- a/proposals/wac-ucr/index.bs +++ b/proposals/wac-ucr/index.bs @@ -75,7 +75,7 @@ fails to satisfy. Use Cases {#usecases} ================================================================================ -For the purposes of simplicity, the use cases herein assume that named +Unless stated otherwise, the use cases herein assume that named individuals (i.e. Alice, Bob, Carol, etc.) are already [=authenticated agents=], and their corresponding [=identities=] are known by the [=resource controller=] when they are granted access. @@ -310,10 +310,14 @@ Alice has a portfolio [=collection=] stored on her [=resource server=] at for. She provides access to the `portfolio` to potential employers as she moves through a job interview process. -The `portfolio` includes [=resources=] representing individual deliverables -she's produced throughout her career, along with [=collections=] of +The `portfolio` [=collection=] includes [=resources=] representing individual +deliverables she's produced throughout her career, along with [=collections=] of deliverables from larger scale projects that she's worked on. +The `portfolio` [=resource=] itself includes summary information about the +portfolio as a whole. For example, Alice details why she chose to include +the items together as a representation of her work. +
Alice's portfolio and opportunities [=collections=] at https://alice.example/
@@ -332,8 +336,9 @@ https://alice.example/ `portfolio/` [=Collection=] - Individual documents she's produced, and collections - of deliverables from projects she's worked on. + Resource includes summary information about the portfolio as a + whole. Member [=resources=] include individual documents she's produced, + and collections of deliverables from projects she's worked on. `-- document1` @@ -387,8 +392,8 @@ Alice has granted Carol, Oscar, and Frank [=read access=] to her `resume` which allows them to read its contents fully. Alice has also granted them [=read access=] to the `portfolio` [=collection=]. -She only wants them to see detail about the `portfolio` [=collection=] itself, -along with a listing of its contents, but not the contents of the +She only wants them to see summary detail about the `portfolio` [=collection=] +itself, along with a listing of its contents, but not the contents of the [=resources=] included in that [=collection=]. Alice wants to know which of them are really interested based on who asks her for @@ -404,22 +409,16 @@ more access to the contents of the resources in `portfolio`. ### Read-write access to a Collection ### {#collection-readwrite} -Alice worked with Milo in the past, where they produced a deliverable -(`document1`) that she has included in her `portfolio` [=collection=]. - -Alice realized that she doesn't have the most up-to-date version of `document1`, -and needs Milo to replace it. She gives Milo [=read access=] and -[=write access=] to the `portfolio` [=collection=] itself, which allows him -to see the -listing of its contents, as well as add and remove items from the -[=collection=]. - -He cannot read the contents of any of the [=resources=] included in the -[=collection=], but this is fine, since he knows the name of the [=resource=] -he's replacing. +Alice is revising the summary description of her `portfolio`, which is +stored in the [=resource=] for the `portfolio` [=collection=]. -Milo updates the contents of `document1` to the most recent version. +Milo is Alice's friend, and she enlists his help in reviewing and revising +her summary. +Alice gives Milo [=read access=] and [=write access=] to the `portfolio` +[=collection=] itself, which allows him read and modify the existing summary +in the `portfolio` [=resource=]. +
* [[#req-agent-identity]] @@ -428,19 +427,21 @@ Milo updates the contents of `document1` to the most recent version.
-### Read-append access to a Collection ### {#collection-readappend} +### Read-create access to a Collection ### {#collection-readcreate} -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 worked with Bob in the past on a project, and she has added a +partial set of the final project deliverables into the `project1` +[=collection=]. She knows that Bob has the rest, and he agrees to provide +them. -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. +Alice grants Bob the following access on the `project1` [=collection=]: -He can't see the contents of the [=resources=], or remove anything in the -list. That's fine because he only needs to add the [=resources=] that aren't -included. +* [=Read access=] which allows him to see the summary detail of `project1` + stored in the `project` [=resource=] itself, as well as + a list of the [=resources=] in the [=collection=], which lets him confirm + whether his uploads are stored successfully. +* [=Create access=] on `project1`, which allows him to add new [=resources=] + to it.
@@ -450,7 +451,7 @@ included.
-### Read-append-write access to a Collection ### {#collection-readappendwrite} +### Read-create-delete access to a Collection ### {#collection-readcreatedelete} Note: Despite this section's focus on permissions specific to the collection resource itself, this use case also incorporates inherited read access to @@ -464,30 +465,32 @@ permissions: * [=Read access=] to the `comments` [=collection=] so they can list existing comments (including their own). -* Inherited [=read access=] to the `comments` [=collection=] +* Inherited [=read access=] to the [=resources=] in the `comments` [=collection=], so they can read the contents of existing comments (including their own). -* [=Append access=] to the `comments` [=collection=], which allows them to - add their own comments, but not change any that exist already. -* Ability to write (edit or delete) any resources in `comments` that they - have created themselves, but none created by anyone else. +* [=Create access=] to the `comments` [=collection=], which allows them to + add new comments, but not change any that exist already. +* Default permissions on new [=resources=] in `comments` that stipulate: + * [=Delete access=] for the creator of a [=resource=] - so they can delete + their own comments if they like, but no one else's.
* [[#req-agent-identity]] * [[#req-collection-read]] * [[#req-inheritance-readonly]] -* [[#req-collection-create]] * [[#req-collection-creator]] +* [[#req-collection-create]] +* [[#req-collection-delete]]
-### Append-only access to a Collection ### {#collection-appendonly} +### Create-only access to a Collection ### {#collection-createonly} Alice realizes it would be helpful if Carol, Oscar, and Frank could provide her with job opportunities that they think she would be a fit for at their respective organizations. -She provides them with [=append access=] to the `opportunities` +She provides them with [=create access=] to the `opportunities` [=collection=]. This allows each of them to add new [=resources=] to `opportunities`, without the ability to see the listing of other [=resources=] in the [=collection=], or modify them. This means that they can each add @@ -635,7 +638,7 @@ https://research.example/ Daily reading - `daily-analysis/` + `daily-summaries/` Collection Daily analysis for group research @@ -693,7 +696,7 @@ well as any that are added in the future. -### Read-append access to collection resources ### {#inheritance-readappend} +### Read-create access to collection resources ### {#inheritance-readcreate} Every day, someone in the group is responsible for recording data from devices in the field, and storing those metrics in `daily-metrics`. @@ -705,8 +708,10 @@ the `research` [=authorization group=]: the [=collection=]. * Inherited [=read access=] so that they can read the contents of those [=resources=]. -* [=Append access=] so that they can add new readings. They cannot modify - readings after they are recorded. This provides confidence that readings +* [=Create access=] so that they can add new readings. They cannot modify + readings after they are recorded, because they do not have [=write access=], + and they cannot remove them, because they do not have [=delete access=]. + This provides confidence that readings are not manipulated after the fact.
@@ -718,7 +723,7 @@ the `research` [=authorization group=]:
-### Read-write access to collection resources ### {#inheritance-readwrite} +### Manage a hierarchy of collection resources ### {#inheritance-manage} The members of the `research` [=authorization group=] collaborate on a daily summary, where they analyze the day's field readings stored in @@ -728,24 +733,31 @@ Bob sets the following permissions on the `daily-summaries` [=collection=] for the `research` [=authorization group=]: * [=Read access=] so they can see the current list of [=resources=] in - the [=collection=]. -* [=Write access=] so they can change the contents and members of the - [=collection=] -* Inherited [=read access=] and [=write access=] so they can read the - contents of the summaries in the [=collection=], author new ones, - and update the contents together until they're satisfied with the results. + the `daily-summaries`. +* [=Create access=] so they can add new summary [=resources=] to `daily-summaries` +* [=Delete access=] so they can remove summary [=resources=] from `daily-summaries` +* Inherited [=read access=] so they can read the + contents of the summaries in the [=collection=] +* Inherited [=write access=] so they can modify their contents +* Inherited [=create access=] so they can add [=resources=] to any [=collections=] + that might be added to `daily-summaries` +* Inherited [=delete access=] so they can remove [=resources=] from any + [=collections=] that might be added to `daily-summaries`
* [[#req-agent-group]] * [[#req-collection-read]] -* [[#req-collection-write]] +* [[#req-collection-create]] +* [[#req-collection-delete]] * [[#req-inheritance-readonly]] * [[#req-inheritance-change]] +* [[#req-inheritance-create]] +* [[#req-inheritance-delete]]
-### Append-only access to collection resources ### {#inheritance-appendonly} +### Create-append access to collection resources ### {#inheritance-createappend} Bob purchases a new field device that is able to automatically push daily metric readings in `daily-metrics`. @@ -755,10 +767,10 @@ Bob gives the new field device the following permissions on the * [=Read access=] so it can access the list of resources in the collection * Inherited [=read access=] so it can read the contents of existing metric readings -* [=Append access=] so it can create a new daily metric resource if a member of +* [=Create access=] so it can create a new daily metric resource if a member of the `research` [=authorization group=] hasn't made one for that day yet. * Inherited [=append access=] so it can add metric readings to daily-metric - resource that already exists. + resources that already exist.
@@ -1019,12 +1031,14 @@ Erin is a research intern that will be assisting Felicia's team in processing and synthesizing data for the `Acme` trial. She will remain on the team until the end of her current academic term on June 30th, 2020. -Felicia has granted Erin inherited [=read access=] and [=write access=] to the -`measurements` [=collection=], which contains measurements for all trial +The `measurements` [=collection=] contains measurements for all trial participants, across all trials. -Felicia adds a time-based condition for Erin which states that her access to -`measurements` is only valid through June 30th, 2020. +Felicia has granted Erin [=read access=] to the `measurements` [=collection=], +and inherited [=read access=] and [=write access=] to the +[=resources=] in the `measurements` [=collection=]. Felicia adds a +time-based condition for Erin which states that this access +is only valid through June 30th, 2020. Erin will have no access to `measurements` after June 30th, 2020. @@ -1032,7 +1046,6 @@ Erin will have no access to `measurements` after June 30th, 2020. * [[#req-agent-identity]] * [[#req-collection-read]] -* [[#req-collection-write]] * [[#req-inheritance-readonly]] * [[#req-inheritance-change]] * [[#req-conditional-time]] @@ -1050,7 +1063,8 @@ measurements that have already been processed. * All measurements for the `Acme` trial are tagged with `Acme` * When a new measurement is processed, it is tagged as `processed` -Felicia authorizes Erin to have inherited [=read access=] and [=write access=] +Felicia authorizes Erin to have [=read access=] to the `measurements` +[=collection=], and inherited [=read access=] and [=write access=] to `measurements`, with a condition that the [=resources=] must: * **include** the `Acme` [=tag=] @@ -1085,7 +1099,8 @@ over time. When Felicia prepares a new report `/reports/report-1`, she authorizes only the senior research team members receiving the report to have inherited [=read -access=] to `measurements`, with a condition that a given measurement must be +access=] to [=resources=] in `measurements`, with a condition that a given +measurement must be related to `/reports/report-1` by an `ex:hasMeasurement` predicate for that access to be permitted. @@ -1220,15 +1235,32 @@ For example, to constrain Oscar's access to `https://oscar.example` to only cases where an application he trusts is involved: * Oscar **with the** `trusted-applications` [=authorization group=] has - [=read access=], [=write access=], [=read permission access=], - and [=write permission access=] to `https://oscar.example` + the following permissions on `https://oscar.example`: + * [=Read access=] so that he can read summary data for the + `https://oscar.example` [=resource=], and list its contents. Inherited + [=read access=] to all member resources so he can read and/or list their + contents. + * [=Write access=] so that he can change summary data for the + `https://oscar.example` [=resource=]. Inherited [=write access=] to + all member [=resources=] so he can change their contents. + * [=read permission access=] and [=write permission access=] so that + he can read and manage permissions. Inherited [=read permission access=] + and [=write permission access=] so that he can manage permissions + for all member resources. + * [=Create access=] and [=Delete access=] so that + he can add and remove resources. Inherited [=create access=] and + [=delete access=] so that he can add resources to member [=collections=] + and delete resources from them. Following that, per [[#inheritance-modifying]], he could extend this default for the `health` [=collection=] to include `healthapp`: * Oscar **with the** `trusted-applications` [=authorization group=] AND - `healthapp` has [=read access=], [=write access=], [=read permission access=], - and [=write permission access=] to the `health` [=collection=] + `healthapp` has [=read access=], [=write access=], [=create access=], + [=delete access=], [=read permission access=], + and [=write permission access=] to the `health` [=collection=], along + with corresponding inherited permissions for [=collection=] member + [=resources=].
@@ -1236,10 +1268,14 @@ for the `health` [=collection=] to include `healthapp`: * [[#req-application]] * [[#req-collection-read]] * [[#req-collection-write]] +* [[#req-collection-create]] +* [[#req-collection-delete]] * [[#req-collection-read-permissions]] * [[#req-collection-change-permissions]] * [[#req-inheritance-change]] * [[#req-inheritance-readonly]] +* [[#req-inheritance-create]] +* [[#req-inheritance-delete]] * [[#req-inheritance-read-permissions]] * [[#req-inheritance-change-permissions]] * [[#req-inheritance-modify]] @@ -1646,10 +1682,16 @@ or limiting access to a [=resource=] or [=collection=] by an [=agent=]. Related use cases: [[#basic-appendonly]], [[#basic-readappend]]
+### The system shall limit the ability to delete a certain [=resource=]. ### {#req-delete} + +
+ Related use cases: [[#collection-readcreatedelete]] +
+ ### The system shall allow for access to a [=resource=] or [=collection=] to be limited to the [=agent=] that created it. ### {#req-creator}
- Related use cases: [[#collection-readappendwrite]] + Related use cases: [[#collection-readcreatedelete]]
### The system shall not rely on the URI path to identity [=resources=] or [=collections=] ### {#req-uripath} @@ -1660,30 +1702,36 @@ or limiting access to a [=resource=] or [=collection=] by an [=agent=]. ## Access to collections ## {#req-collections} -### The system shall allow the ability to read a certain [=collection=] to be limited, exposing only the data from the [=collection=] resource itself, and a listing of its members. ### {#req-collection-read} +### The system shall allow the ability to read a certain [=collection=] to be limited, exposing only the data from the [=collection=] resource itself, and a listing of its members, and excluding the contents of its members, or any metadata about them. ### {#req-collection-read}
Related use cases: [[#collection-readonly]], [[#collection-readwrite]], - [[#collection-readappend]], [[#collection-readappendwrite]] + [[#collection-readcreate]], [[#collection-readcreatedelete]]
-### The system shall allow the ability to change data specific to a certain [=collection=] to be limited, including only the data from the [=collection=] resource itself, and a listing of its members. ### {#req-collection-write} +### The system shall allow the ability to change data specific to a certain [=collection=] to be limited, including only the data from the [=collection=] resource itself, and excluding any additions or subtractions from its list of members. ### {#req-collection-write}
Related use cases: [[#collection-readwrite]] -
+
### The system shall allow the ability to create a [=resource=] in a certain [=collection=] to be limited.### {#req-collection-create}
- Related use cases: [[#collection-readwrite]], [[#collection-readappend]], - [[#collection-readappendwrite]] + Related use cases: [[#collection-readwrite]], [[#collection-readcreate]], + [[#collection-readcreatedelete]], [[#collection-createonly]] +
+ +### The system shall limit the ability to delete a [=resource=] in a certain [=collection=].### {#req-collection-delete} + +
+ Related use cases: [[#collection-readcreatedelete]]
-### The system shall allow for the creator of a [=resource=] or [=collection=] in a certain [=collection=] to be automatically granted access to the created [=resource=] or [=collection=].### {#req-collection-creator} +### The system shall allow for the creator of a [=resource=] in a certain [=collection=] to be automatically granted access to the created [=resource=].### {#req-collection-creator}
- Related use cases: [[#collection-readappendwrite]] + Related use cases: [[#collection-readcreatedelete]]
### The system shall allow the ability to read the access permissions associated with a certain [=collection=] to be limited.### {#req-collection-read-permissions} @@ -1693,7 +1741,7 @@ or limiting access to a [=resource=] or [=collection=] by an [=agent=]. [[#uc-historyofchanges]] -### The system shall allow the ability to change the access permissions associated with a certain [=collection=] to be limited.### {#req-collection-change-permissions} +### The system shall allow the ability to change the access permissions directly associated with a certain [=collection=] to be limited.### {#req-collection-change-permissions}
Related use cases: [[#collection-control]] @@ -1706,56 +1754,62 @@ or limiting access to a [=resource=] or [=collection=] by an [=agent=].
Related use cases: [[#uc-inheritance]]
+ +### The system shall allow for a certain resource to be read if the [=agent=] has inherited [=read access=] from the parent [=collection=] the [=resource=] is a member of. ### {#req-inheritance-readonly} -### The system shall allow for the members of a certain [=collection=] to extend or augment the permissions inherited from that [=collection=].### {#req-inheritance-modify} +
+ Related use cases: [[#inheritance-readonly]] +
+ +### The system shall allow for a resource to be changed if the [=agent=] has inherited [=write access=] from the parent [=collection=] the [=resource=] is a member of. ### {#req-inheritance-change}
- Related use cases: [[#inheritance-adding]], [[#inheritance-modifying]] + Related use cases: [[#inheritance-manage]]
-### The system shall allow for a certain [=collection=] to specify access permissions that are inherited by its members and cannot be augmented. ### {#req-inheritance-force} +### The system shall allow for new data to be added to a [=resource=], without being able to change existing data in that [=resource=], if the [=agent=] has inherited [=append access=] from the parent [=collection=] the [=resource=] is a member of. ### {#req-inheritance-appendonly}
- Related use cases: [[#inheritance-forcing]] + Related use cases: [[#inheritance-createappend]]
-### The system shall allow for a certain resource to be read if the [=agent=] has inherited that permission from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-readonly} - +### The system shall allow for new resources to be added to a given [=collection=] if the [=agent=] has inherited [=create access=] from the parent [=collection=] that the given [=collection=] is a member of. ### {#req-inheritance-create} +
- Related use cases: [[#inheritance-readonly]] + Related use cases: [[#inheritance-readcreate]]
- -### The system shall allow for a new resource to be created if the [=agent=] has inherited that permission from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-create} + +### The system shall allow for resources to be deleted from a given [=collection=] if the [=agent=] has inherited [=delete access=] from the parent [=collection=] that the given [=collection=] is a member of. ### {#req-inheritance-delete}
- Related use cases: [[#inheritance-readappend]] + Related use cases: [[#collection-readcreatedelete]]
-### The system shall allow for the default permissions of a newly created [=resources=] to be inherited from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-default-permissions} +### The system shall allow for the members of a certain [=collection=] to extend or augment the permissions inherited from the parent [=collection=].### {#req-inheritance-modify}
- Related use cases: [[#inheritance-defaultcreated]], [[#inheritance-extended]] + Related use cases: [[#inheritance-adding]], [[#inheritance-modifying]]
- -### The system shall allow for a resource to be changed if the [=agent=] has inherited that permission from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-change} + +### The system shall allow for a certain [=collection=] to specify access permissions that are inherited by its members and cannot be augmented. ### {#req-inheritance-force}
- Related use cases: [[#inheritance-readwrite]] + Related use cases: [[#inheritance-forcing]]
-### The system shall allow for new data to be added to a [=resource=], without being able to change existing data in that [=resource=], if the [=agent=] has inherited that permission from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-appendonly} +### The system shall allow for the default permissions of a newly created [=resource=] to be inherited from the parent [=collection=] the [=resource=] is a member of. ### {#req-inheritance-default-permissions}
- Related use cases: [[#inheritance-appendonly]] + Related use cases: [[#inheritance-defaultcreated]], [[#inheritance-extended]]
-### The system shall allow for the access permissions associated with a certain resource to be read if the [=agent=] has inherited that permission from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-read-permissions} +### The system shall allow for the access permissions directly associated with a certain resource to be read if the [=agent=] has inherited [=read permission access=] from the parent [=collection=] the [=resource=] is a member of. ### {#req-inheritance-read-permissions}
Related use cases: [[#inheritance-control]]
-### The system shall allow for the access permissions associated with a certain resource to be changed if the [=agent=] has inherited that permission from the [=collection=] the [=resource=] is a member of. ### {#req-inheritance-change-permissions} +### The system shall allow for the access permissions directly associated with a certain resource to be changed if the [=agent=] has inherited [=write permission access=] from the parent [=collection=] the [=resource=] is a member of. ### {#req-inheritance-change-permissions}
Related use cases: [[#inheritance-control]] @@ -1815,7 +1869,7 @@ does not satisfy the following use cases: * [[#inheritance-modifying]] * [[#inheritance-forcing]] * [[#inheritance-extended]] -* [[#collection-readappendwrite]] +* [[#collection-readcreatedelete]] * [[#conditional-time]] * [[#conditional-tag]] * [[#conditional-filter]] @@ -1880,14 +1934,31 @@ An access mode denotes a class of operations that an [=agent=] and/or [=application=] can perform on one or more [=resources=]. Read access is an [=access mode=] that allows [=agents=] and/or -[=applications=] the ability to read, but not modify a [=resources=]. +[=applications=] the ability to read, but not modify a [=resource=]. When +the [=resource=] is a [=collection=], this includes access to the list +of [=resources=] in that [=collection=], but does not include access to +their contents, or any metadata about them. Write access is an [=access mode=] that allows [=agents=] and/or -[=applications=] the ability to create, update, or delete a [=resource=]. +[=applications=] the ability to modify the contents of a [=resource=]. When +the resource is a [=collection=], the contents of the [=collection=] resource +itself can be modified, but [=create access=] and [=delete access=] are +required to create or delete [=resources=] from the [=collection=]. Append access is an [=access mode=] that allows [=agents=] and/or -[=applications=] to add data to a resource, but not modify any data that -already exists. +[=applications=] to add data to the contents of a resource, but not modify +any of the existing contents. When the resource is a [=collection=], the +contents of the [=collection=] resource +itself can be added to, but [=create access=] is required to add new +[=resources=] to the [=collection=]. + +Create access is an [=access mode=] that allows [=agents=] and/or +[=applications=] to add new [=resources=] to a given [=collection=]. + +Delete access is an [=access mode=] that allows [=agents=] and/or +[=applications=] to delete a [=resource=]. If the [=resource=] is a +[=collection=], it includes the ability to delete [=resources=] in that +collection. Read permission access is an [=access mode=] that allows [=agents=] and/or [=applications=] to view [=authorizations=] associated with a [=resource=]. diff --git a/proposals/wac-ucr/uc-survey.md b/proposals/wac-ucr/uc-survey.md index a59b8c5f..598b9381 100644 --- a/proposals/wac-ucr/uc-survey.md +++ b/proposals/wac-ucr/uc-survey.md @@ -22,7 +22,14 @@ Notes: ## Basic resource access -### Control access +### Change permissions +URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-change-permissions + +* +1 bblfish: public [si] [ai]. + +### Read permissions (was basic control?) +URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-read-permissions + URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-control * +1 justinwb: to the ability to read and write permissions on resources. public [ai]. private [ai]. @@ -35,6 +42,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-control * +1 dmitrizagidulin: public [si]. * +1 bblfish: public [si] [ai]. + ### Read-write access URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-write @@ -48,6 +56,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-write * +1 dmitrizagidulin: * +1 bblfish: public [si] [ai] (note: the resume example implies a PATCH mechanism for HTML, which needs to be identified, and taken on elsewhere. PATCH for RDF is specified and quite implementable (it involves SPARQL UPDATE)). + ### Read-append access URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend @@ -78,7 +87,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#basic-readappend-multi * +1 justinwb: * +1 elf-pavlik: -* +1 csarven: [d] such that agent A sends a notification about the recommendation to agent B's inbox ie. #collection-readappend , instead of updating a resource that references it. +* +1 csarven: [d] such that agent A sends a notification about the recommendation to agent B's inbox ie. #collection-readcreate , instead of updating a resource that references it. * +1 jaxoncreed: * +1 KaiGilb: graphMetrix * +1 hindia: @@ -177,7 +186,8 @@ This is an important aspect of onboarding and the growth os Solid. "Grant access only if the user consents to be added to a list for future contacting etc". * +1 bblfish: public [si] [ai]. -## Basic collection access +## Collection access +URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-collection ### Read-only access to a Collection URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readonly @@ -190,7 +200,8 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readonly * +1 KaiGilb: graphMetrix * +1 hindia: * +3 dmitrizagidulin: -* +1 bblfish: public [si] [ai]. (proviso: if the ldp:Container only contains ldp:contains links, and no other descriptive info, it would be difficult for people to know what the contents are to make up their minds about what they are interested in. See the Tor example where it would make no sense. Perhaps one needs to add that the container shows the title of the contents, and summary, and links to requests to see the contents. This would require something like an solid:InformativeContainer which shows such information and acts like an RSS Feed.) +* +1 bblfish: public [si] [ai]. (changes with PR 166 ok) + ### Read-write access to a Collection URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readwrite @@ -203,10 +214,10 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readwrite * +1 KaiGilb: graphMetrix * +1 hindia: * +1 dmitrizagidulin: (though I agree with @jaxoncreed that clarification is needed.) -* +0 bblfish: public [si] [ai]. (agree with jaxon. I also think one needs to distinguish between ability to add new resources the Container, and changes to the container itself. You may be happy to allow people to add to an ldp:Container but not to change the nature of the container, say from an ldp:BasicContainer to an ldp:IndirectContainer, as the latter container has speech act implications beyond the creation of the content. See my [chapter 2 of my 2nd year report](https://co-operating.systems/2019/04/01/). Yes, delete without read seems dubious and dangerous - in [RelBAC](https://github.com/solid/authorization-panel/issues/150) I think delete is a subproperty of write.). +* +0 bblfish: public [si] [ai]. (changes with PR 166 ok) -### Read-append access to a Collection -URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readappend +### Read-create access to a Collection +URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readcreate * +1 justinwb: * +1 elf-pavlik: @@ -216,16 +227,16 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readappend * +1 hindia: * +0 dmitrizagidulin: The usefulness of this UC, as written, depends on resource names (filenames) being human-readable. -* +1 bblfish: public [si] [ai] (agree with Dmitry though I one could also allow new types of containers that act as RSS feeds, giving title and summaries of the contents therein). +* +1 bblfish: public [si] [ai] (changes with PR 166 ok) -### Read-append-write access to a Collection -URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readappendwrite +### Read-create-delete access to a Collection +URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-readcreatedelete * +1 justinwb: Being able to designate the creator of a resource with specific privileges in an append scenario on a container is extremely important to a number of collaborative scenarios. * +1 elf-pavlik: -* 0 csarven: Seems like duplicate of #collection-readwrite and #collection-readappend +* 0 csarven: Seems like duplicate of #collection-readwrite and #collection-readcreate * +1 jaxoncreed: * +3 timbl: * +1 KaiGilb: graphMetrix @@ -236,21 +247,21 @@ a number of collaborative scenarios. * +2 bblfish: public [si] [ai] -### Append-only access to a Collection -URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-appendonly +### Create-only access to a Collection +URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-createonly * +1 justinwb: * +1 elf-pavlik: * +1 csarven: Wide use. Required for [ap] eg. creating annotations or notifications. [d]. * +1 jaxoncreed: -* +3 timbl: Append-only access allows you to implement the semantics of message passing. That is a crcuial building blcok for many systems, +* +3 timbl: Append-only access allows you to implement the semantics of message passing. That is a crucial building block for many systems, technical and social. We may been extra functionality to in some cases giuve people read-write access to a thing they have posted using append-only access. * +1 KaiGilb: graphMetrix * +1 hindia: * +3 dmitrizagidulin: * +2 bblfish: public [si] [ai] -### Control access to a Collection +### Manage permissions for a Collection URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-control * +1 justinwb: @@ -263,7 +274,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#collection-control * +3 dmitrizagidulin: * +1 bblfish: public [si] [ai] -## Inheritance +## Collection resource inherited access ### Read-only access to collection of resources URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readonly @@ -276,12 +287,10 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readonly * +1 KaiGilb: graphMetrix * +1 hindia: * +3 dmitrizagidulin: -* +1 bblfish: public [si] [ai] (note: I find the phrase "research authorization group" unwieldy. Why should - one distinguish an authorization group, from any other group of agents? Any access control rule can - authorize any group to access resources) +* +1 bblfish: public [si] [ai] -### Read-append access to collection resources -URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readappend +### Read-create access to collection resources +URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readcreate * +1 justinwb: * +1 elf-pavlik: @@ -293,12 +302,12 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readappend * +1 dmitrizagidulin: * +1 bblfish: public [si] [ai] -### Read-write access to collection resources -URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readwrite +### Manage a hierarchy of collection resources +URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-manage * +1 justinwb: * +1 elf-pavlik: -* +1 csarven: Wide use. Required for [ap] - similar to #inheritance-readappend. [d]. +* +1 csarven: Wide use. Required for [ap] - similar to #inheritance-readcreate. [d]. * 0 jaxoncreed: I think this needs more clarification on what happens to nested collections. * +3 timbl: * +1 KaiGilb: graphMetrix @@ -306,8 +315,8 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-readwrite * +3 dmitrizagidulin: * +1 bblfish: public [si] [ai] -### Append-only access to collection resources -URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-appendonly +### Create-append access to collection resources +URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-createappend * +1 justinwb: * +1 elf-pavlik: @@ -319,7 +328,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-appendonly * +3 dmitrizagidulin: * +1 bblfish: public [si] [ai] -### Control access to collection resources +### Manage permissions for collection resources URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-control * +1 justinwb: @@ -355,7 +364,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-extended * +1 KaiGilb: graphMetrix * +1 hindia: * +1 dmitrizagidulin: -* +1 bblfish: public [si] [ai] (note: I don't understand the last paragraph: what is a "granular fashion"?) +* +1 bblfish: public [si] [ai] ### Adding new subjects to inherited permissions URL: https://solid.github.io/authorization-panel/wac-ucr/#inheritance-adding @@ -456,7 +465,7 @@ case addresses that. * +1 KaiGilb: graphMetrix. This seems very important. Like only give certain doctor relations access to records. * +1 hindia: * +1 dmitrizagidulin: -* +1 bblfish: public [si] [ai] - agree with dmitri and justin +* +1 bblfish: public [si] [ai] - agree with justin ### Conditional access by filter URL: https://solid.github.io/authorization-panel/wac-ucr/#conditional-filter @@ -528,7 +537,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-client-constraints * KaiGilb: im a little unclear on this case * +1 hindia: * +1 dmitrizagidulin: -* -1 bblfish: this is better done on the client, where such information can be written out once, without needing to have control access to every resource on the web that the app could have access to. +* +1 bblfish: this needs to be done on the client, where such information can be written out once, without needing to have control access to every resource on the web that the app could have access to. I described this better in [Interop Panel Meeting 2021-02-02](https://github.com/solid/data-interoperability-panel/blob/master/meetings/2021-02-02.md). ### Application determining access privileges URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-client-determine-access-privileges @@ -578,6 +587,7 @@ get to VC in the next cycle. in a wallet spec or implementation guide. * +3 bblfish: public [si] [ai]: this is very much a requirement on the server not the client. Without it we cannot secure privacy for the client across pods, as clients would constantly have to present for each remote resource every ID it has, even when none are valid. * +0 csarven: "minimal" is unclear. Client to present only one credential? Least "sensitive" - what criteria? Exact/Close match (schema) of what's allowed? Good UC to support. Not essential for [ap]. I don't plan to implement it. +* +2 bblfish: [si] [ac] re: csarven, reasoning about credentials is difficult I agree, so there should be a library that does all that type of work. That is what the [Launcher App](https://github.com/solid/authorization-panel/blob/master/proposals/LauncherApp.md) or something like it is meant to do. ### Limit information disclosure through URI @@ -593,7 +603,7 @@ represents data. * +1 hindia: * +0 dmitrizagidulin: Doesn't belong in authorization, this should be in the server spec security/privacy considerations section. -* +3 bblfish: [si] [ai] This is essential to make sure that authorization is completely based on follow your nose principles, not on pattern matching URLs or other implicit assumptions. Having a Tor based Solid Server should make for excellent demos at security conferences, ie conferences where the audience we need to convince go. Putting a Solid Server behind Tor should not be a lot of work, neither should creating a UUID to Resource mapping. +* +3 bblfish: [si] [ai] This is essential to make sure that authorization is completely based on follow your nose principles, not on pattern matching URLs or other implicit assumptions. Having a Tor based Solid Server should make for excellent demos at security conferences, ie conferences where the audience we need to convince go. Putting a Solid Server behind Tor should not be a lot of work, neither should creating a UUID to Resource mapping. Note that I also defend the idea of [full use of relative URLs in Solid](https://github.com/solid/specification/issues/194) which I believe is compatible with this. ## Trust @@ -608,7 +618,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-trustedissuers * +1 hindia: * -0 dmitrizagidulin: Seems like a very specific use case (a special case of allowing access by group). -* +0 bblfish: agree with dmitri, but still useful. Door should be left open to it, and perhaps wait until the situation arises where people demand it. +* +0 bblfish: agree with dmitri, but still useful. This is actually a case of restrictions on issuers, which is the (nearly) the only thing TLS client certificate negotition allows. ### Block access to agents URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-blockagents @@ -632,6 +642,7 @@ URL: https://solid.github.io/authorization-panel/wac-ucr/#uc-validation URL: https://solid.github.io/authorization-panel/wac-ucr/#group-membership-vc * 0 csarven: Some use but not essential for [ap]. I don't plan to implement it. +* +1 bblfish: This is actually quite advanced, but I think it can be done elegantly summarized in the meetings notes for [2021-01-27](https://github.com/solid/authorization-panel/blob/master/meetings/2021-01-27.md). ### Possession of a verifiable credential URL: https://solid.github.io/authorization-panel/wac-ucr/#capabilities-vc @@ -659,4 +670,4 @@ flows or one-time shares. * +1 KaiGilb: graphMetrix (maybe +1) * +1 hindia: love this too * +1 dmitrizagidulin: Essential for shares. -* +0 bblfish: interesting use case. This could be just that the resource is read/write to everyone? (+if needed making the URL obscure). Or is the server meant to detect a redirect? +* +0 bblfish: interesting use case. This could be just that the resource is read/write to everyone? (+if needed making the URL obscure). Or is the server meant to detect a redirect? If it requires the user to go through a user interface as done on Google according to Dmitri, then this may not be scalable. So it needs to be tied in with some machine readable system where the client auth app can automate some tasks when authorized by a users' policy.