# 2020-11-16 Authentication Panel

## Agenda

- Issues
- elf Pavlik - [UC: 2.5.2. Limiting application access while not acting as resource controller](https://solid.github.io/authorization-panel/wac-ucr/#uc-client-constraints)
- how does it impact Authentication spec [Issue: Consider IdP to issue Identity Verifiable Credential rather than global access token #60](https://github.com/solid/authentication-panel/issues/60)
- how does it leverage App Authorization from Interop Panel [PerformChart example from UC above](https://deploy-preview-70--data-interoperability-panel.netlify.app/primer/#performchartexample)

## Present

* Dmitri Z
* Henry S
* Jaime
* Justin B
* Matthieu B
* e Pavlik
* Aaron C

## Minutes

- Pavlik: I think putting responisibility of constraining clients on IdP may be more pragmatic.

- Justin: Are we talking about general scopes? And you could further refine it on the resource server side. It seems that it could lead to conflicting decisions.

- Pavlik: It would be useful to see a use case with specific data instances acting as non-controller.

- Aaron: In terms of having IdP giving hints about scopes. SAML can give information about what access is granted. It works for single use cases but in more complex ones it starts breaking. If you rely on that as source of truth it stops working.

- Henry Story : If the problem is to be able to allow a user to limit access to apps so that they don't get all the access rights the user would be allowed to have, then there was the proposal for an intermediary type of Key Chain agent/App that can give out certificates or tokens to each app individually for read or write to each resource (see [LauncherApp](https://github.com/solid/authorization-panel/issues/45)).