---
# System prepended metadata

title: 2020-01-06 Authentication Panel

---

# 2020-01-06 Authentication Panel

## Present

* Jackson
* Elf
* Jamie
* Michiel

## Issues

### Launcher
 - Michiel: We have built a launcher app (Different from henry's) It's basically an .acl editor app. It's currently using a list of apps that it knows about and it knows exactly what that app needs. For example markbook needs access to your bookmarks. If you don't have a bookmarks file there. So markbook does not require control access. The current version has a limited number of tricks. It can basically do some class from your public type index or one from your private type index. But, the next version can specify steps with follow your nose. So you'll always start with the user's webid. Its main function is editing your .acl files.

- Jackson: We had discussion about capabilities based access for apps. Token that app would use would inculde capabilities which restrict what this app can do.

- Michiel: That sounds like more powerful approach. Currently we only have ACL and token doesn't involve any logic other than user's webid. It sounds powerful but it makes a major shift. I like current approach where we use tripples to manage access.

- Elf: Just to clarify: Whatever capabilities you would use would use the same vocab as the acl. There are 3 things we're dealing with:
    - Type index: it looks like we're moving towards shapes rather than types
    - The access mode: Read, write, append... this is defined in the acl
    - The location: The location of a resource
- Elf: Currently the app can know access modes and type, but not location. Practically you could use the same vocabulary. The app could have clear capabilities that it presents to the resource server, and this way it's handled on the the user and app side rather than the storage side. It would just change the fact that the app needs to present the capability instead of only being stored on the storage.
- Michiel: I think there's a small leap and a big leap
    - Small leap: Shapes: If the server needs to understand shapes, it makes the server more complex. If your pin number is in there. The small step in the public shape index. A problem with the current spec is if you use an app and the other person doesn't use that app, the other person gets to choose what apps are used. A capabilities based token would fix that.
- Elf: And throughout our discussions we would focus on users restricting access to other users. In practice we cannot ensure which apps a user use
- Jackson: we could provide capability for restricting which apps other users can use. They can still claim that they use allowed app but use a different app. Mostly power users could claim using other app.
- Michiel: When I log in to the app and give it my identity credential. This token will say its for this app.
- Elf: In practice we could use the redirect of the uri to identify an app, but a person could still spoof that if the app and idp are in collusion.
- Jackson: We can use both capabilities based and acl based enforcement. In case where Alice doesn't trust Charlie with choice of his app to access some resource(s). This would not happen by default but as opt-in rule and understanding that Charlie still with some tooling could pretend to use that allowed app while using different app (eg. proxy etc.).
- Michiel: Which spec includes that aproach?
- Jackson: still under discussion.
- Michiel: Alice grants access to Bob using their WebID. What if she would refer to document that lists apps that bob delegets to.
- Jackson: Technically it sounds similar. Just the URL of Bobs authorization gets passed in the token. It sounds like Alice needs to know location of that document in the way you propose it.
- Elf: The capabilities would either be embedded in the token. It could be a capability url. It's not a publicly listed resource. The token would include the reference. Only the resource server can access it. Capability urls shouldn't be guessable.
- Michiel: What if the acl document on alice's pod currently lists bob's webid. What if she adds a secret to it.
- Jackson: Capabilities give Bob power to restric application rather than Alice.
- Elf: That secret approach would still allow Bob to share that secret with any app.
- Jackson: Main difference seems that one has rules interpreted upon the request, the other one relies on gathering secrets before.
- Michiel: Using capabilities URL for all data sounds reasonable.
- Jackson: When it comes to shapes and discoverability, we still have issue of semantic meaning of URL. Path defines a underlying folder structure.
- Jackson: We also have discussion about using tags.
- Michiel: This sounds similar to secrets.
- Jackson: I worked on rules engine which could handle various acl rules.
- Michiel: We should make sure we don't create to much surface for DDOS attacks.
- Jackson: with lack of capability system one may want to reject access by default.

### Capabilities Discussion (#53) https://github.com/solid/authorization-and-access-control-panel/issues/53