# Use Cases and Requirements Session
February 8th, 2021

## Present

- Justin B
- Henry S
- Dmitri Z
- Eric P

## Agenda

- Discuss Create / Delete - https://github.com/solid/authorization-panel/pull/166
- Latest UCR Updates / Reviews - https://github.com/solid/authorization-panel/pull/152

## Minutes

### Create/Delete PR 166

Justin B: The PR clarifies delete and creation use cases which previously were difficult to follow because they confused append of data on a container with adding a new resource to a container.

HS: I went through the PR and I agree that it is an improvement. The previous language was too close to the implementation layer of HTTP requiring the reader to know a lot more than is needed, and also perhaps closing opportunities for improvement to the access control layer.

HS: I added some minor typo/grammar commits to it.
Also I wanted to update the UC-Survey to fix the pointer references that were changed. So I did a git rebase on master as follows:

gh pr checkout 152
git rebase master
git push --force-with-lease

So you may need to pull the new version if you are working with a version on your file system.

HS: I was going to see if the changes would affect my responses to the UC Survey, and then add a +1 to the PR.

### UCR Requirements PR 152

Action items:

HS: Update requirement setup to "The system shall allow [e.g. access to be limited to the access control rule]"

EP: The system shall provide an \<a id="#ACLinterface">interface to access control lists\</a>.

EP: Consider a DFN link for "<a href='#limit'>limit<a>", e.g.

> Saying the system limits access to X, indicates that there is a mechanism by which a user or controller may set access permissions and the system will enforce them when agents \<a href="#ACLinterface">interact with ACLs\</a>.

Discussion on tension of privacy requirements for the client and server led Henry to point to this image

[](https://www.youtube.com/watch?v=8Q2L3RuSnBs&feature=emb_logo)
"*In order to improve our user experience we have opened up our authorization policies*"

What at first sight seems incredible, namely this bathroom with transparent plexiglass in the [Belgian Restaurant Belga Queent](http://www.belgaqueen.be/brussels.aspx#intro) has a technical explanation, shown by the YouTube video you get to by clicking on the image. Moral: we can solve this incongruity with some clever technology if we set our minds to it.

DZ: Can we timebox argument on determination of client privileges

HS: Agree we don't need to specify *how* this needs to work. But we do need to add a requirement on the information needeing to be made available to the client so that it can select an ID or credential needed to authenticate.

JB: "The system shall ensure that there are practical and efficient mechanisms available for the client to determine an appropriate credential to present for access to a given resource." - DZ +1, HS +1

DZ: Look at in-browser CHAPI scenario for real world example. Existing solution that separates authorization layer from credential layer

HS: yes TLS Client certificate authentication also allows the server to specify the id of certificate authorities it accepts.
The problem with TLS Client Certificates is that they cover a whole connection (not per resource) and are difficult to undo: once selected the browser automatically selects it (unless told otherwise in a difficult to find setting). Furthermore as CSarven pointed out last Wednesday's meeting and in [his comment on the issue 123 "keep track of effiency"](https://github.com/solid/authentication-panel/issues/123#issuecomment-768606815) a client that jumps across many servers can overwhelm the user with Certificate Requests leading to a terrible user-experience. With Verifiable Claims and client side policies we can do a lot better.

JB: Per comment on intro text about resource controller implicit requirements - consider switching "give" in use cases to "grant" / "authorize" and link to the explanation instead of the setup at the top

HS: Limit Information disclosure through URI - Look at suggested requirement (which essentially says no semantics from the URI name)

HS: Conditional access by payment - add some req for client to know the credential to present

HS: Limitations of legacy web access control - consider switching this to requirements, or fill missing use cases.

HS: Extended network - Add conditional relationship to illustrate the dynamic (Linked-Data) nature of use case

EP: Change "specific" to "given" on conditional relationship