---
# System prepended metadata

title: Solid Authorization Panel

---

# 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"
   