# Solid Authorization Panel
2021-02-03

## Call
* https://meet.jit.si/solid-authorization

## Present
* Justin B

## Agenda

* Announcements
* Schedule for meeting with Credentials Group
* Review Minutes
* See [prior minutes](https://github.com/solid/authorization-panel/pull/161) (2m)
* Pull Requests
* https://github.com/solid/authorization-panel/pull/152 (5m - status)
* Issues
* [Efficiency (issue 162)](https://github.com/solid/authorization-panel/issues/162): a non functional requirement, or a larger use case, or both?
* Topic Items
* Acceptance / merge of UCR

## Minutes

### Schedule for Credentials CG Presentation

Feb 24th - our presentation (using current panel time slot)
Feb 24th - presentation back to us (three hours later - their weekly slot)

## UCT

Justin: suggesting getting this done in the next two weeks before Credentials CG presentation.
... Proposes: Feb 17th for Milestone agreed upon target for Merge of UCR. With merge that day.

With potential extra meetings before then.

bblfish: free all time except 10am ET Mon-Wed for Solid meetings

Justin:
- Monday 8AM-10AM ET / 2PM-5PM ET
- Weds 3PM-5PMET
- Thursday 10AM-1PM ET / 2PM-5PM ET
- Friday 8AM-11AM ET / 2PM-5PM ET

Sarven:
- Thurs 09-10am ET
- Friday 08-09am ET

ericP (probably not critical for UC&R discussion):
- Monday 08am-11am ET
- Tuesday 08am-10am / 11am-13pm ET
- Wednesday 08am-11am / 12pm-13pm ET
- Thursday 08am-11am / 12pm-13pm ET
- Friday 08am-13pm ET

Mathieu:
Free most of the time and also not required for the meeting to happen. No objection for Friday after 10am ET.

Emmet
- Thursday 2pm - 5pm ET
- Friday 7am - 8:30 am ET, 10am onwards
- Monday 1pm onwards
- Tuesday 10am-11am ET, 12pm ET onwards
- Wednesday 10 AM ET onwards
- Thursday 11am - 12pm ET
- Friday 12pm onwards
- Monday 11:30am ET onwards
- Tuesday 10am - 12pm ET, 1pm ET onwards

Pavlik
- Mon - Fri 10am - 6pm ET

## Issue 162

CSarven:
Add a non functional requirements section.
Elf Pavilik:
The use case as shown in the issue 162 does not have enough authorization features
CSarven:
describes his example with Dokieli and TLS client certificates where annotations at different servers require authn/z [here](https://github.com/solid/authentication-panel/issues/123#issuecomment-768606815)
Elf Pavlik:
If resources are public there is no problem.
Arguing that the examples are too hypothetical.
Eric Prudheaummeux:
Functional requirements are how it is meant to behave
What would non-functional requirements?
Henry Story:
Non functional would be how the system as a whole functions.
Eric:
Don't bother with a functional requirement put then
but add a use case which makes it clear and add a functinoal requirement.

## Feedback on UCR

Henry: What do we do with the feedback?
It seems that all the feedback on the first use cases
is a bit negative, and we should improve the examples
to be more realistic

Eric: that's marketing, but important

Henry: also should we add a sentence, about "not all the use
case will necessarily be implemented in the first stage"