https://meet.jit.si/solid-authorization
- Minutes #220
- Previous week actions?
- Use Case 3: Inheritance #216
- Proposal (from Justin B) - Panel attention on authorization / consent workflows (e.g. trusted agent pattern from interop)
- Henry S
- Justin B
- Matthieu B
Henry: Currently, we have access control rules and inheritance that works with default.
What if you want to add someone to only one of the weekly-meetings?
Then you currently have to copy all the rules from the default into the newlh created ACR.
Matthieu: Yes, let's elaborate that.
Henry: The problem is that it goes against the "Don't Repeat Yourself" (DRY) software engineering principle.
Justin: If you have different sets of agents and try to maintain that, assume it's going to break.
Henry: It will become easier to pinpoint and show what the problem is.
Matthieu: We could maybe do imports via link headers.
Henry: I have a default ACL on the filesystem and you create a new acl with each resource and import its parent acl. That's what I show in 210 if you do a query asking for trig. If you get trig, you might as well have all the relevant info.
Matthieu: What if you don't have access to all the access control rules?
This is why I was suggesting link headers of rel type owl:import.
Justin: I think we are making very good traction on WAC & ACP. We have a draft of ACP that should be able to be reviewed soon. I wanted to ask for convergence on the workflows required for interoperability and consent. The pattern is "trusted agent" - "authorization server" the trusted authorization agent is trusted to give authorization. UMA is a pattern that was related to interop workflows that is pretty OIDC centric. This should be the forum in which we start cooperating and looking at. It would be a pretty in depth work track compared to the WAC/ACP track. It would cover how applications spec what they need to an authorization agent, how the agent presents it, how the authorization is made, how that's stored and persisted. There is a vein of it as well about verifiable credentials. At a minimum we need to start talking about it to figure out where it's gonna live. We rely on this pattern in interoperability and there's gonna be reliance on it in the ecosystem. But we haven't dug into the mechanics of how you communicate with your authorization agent. It feels like the right time to dig in here (I know Pavlik agrees). Maybe even have
Matthieu: Would UMA be a way to advertise which credentials are required to access a resource.
Justin: UMA existed before VC. It's one pattern we rely on in interop so users can provide fine-grained access to their data. I'm not proposing starting working on UMA, just looking at the workflow patterns of authorization agents. Can you use or take advantage of verifiable credentials in a number of ways? Storing decisions. Doing use case for authorization by credentials. I don't know which authorization you want and sending them all defeats the pattern. An authorization server you trust would be an answer. The pattern of having your own authorization agent would answer some questions. I can articulate the application ecosystem pattern.
Matthieu: It's about having an authorization agent?
Justin: It could be client or server/IdP or Resource Server. It is an actor that exists in and of itself.
Henry: Is the authorization server authorizing access to a resource?
Justin: Typical workflow:
- I want to use the "Acme" project-management App which is Solid enabled
- I'm not logged in
- I do solid OIDC
- I now have a token with claims showing I control my WebID and I'm using the "Acme" App (via its Client WebID)
- I have not given Acme project access to my resource yet (my access control rules prohibit access from non- specified apps by default)
- My authorization agent can help me manage the access granted to a specific application
- Why would I just give all access to Acme project?
- What you want is Acme project to say I have no access
- Acme looks in the WebID and sees who my authorization agent is
- Acme project sends me to my authorization agent and expresses the kind of data they need authorization to (Project Management data, for example), then asks which projects? all/work...
- I want only work project access for acme project, and the app gets back the list of things they have access to
That's an oversimplified example of what UMA does. It would facilitate that kind of fined grained access. Which is a pretty necessary pattern. You can build upon it. We currently haven't used UMA; we just made an authorization agent with sanity checking. Currently, UMA is supported by several IdPs, and the benefit of investigating it is that we've talked about IdP potentially doing that.
Matthieu: In short the authorization agent helps you manage fine grained access for specific agents.
See:
See also the data interoperability walkthrough videos:
- Application Interoperability Walkthrough - Part 1 (VIDEO)
- Application Interoperability Walkthrough - Part 2 (VIDEO)
Henry: The authorization agent says this app can access this kind of resources. So we're back to something like we could use owl. For example, everything tagged banking...
Justin: What we do in Interop is organise data by type using shapetrees. So when you get access, you essentially get access to a type within a scope. So the decision I make is an access grant and can be stored in my Pod with other grants. It's a pretty big subject for 8mn. This is a layer above it.
Access Grant for Acme Project:
Justin: This is what the authorization agent create. We just show the grants here, but the access needs groups stores what was requested and what was granted. You can actually do a diff and store it if you want more access.
Henry: I think it's close to my proposal on my launcher app.
Justin: Wasn't it proxying all the time?
Henry: In an ideal world, (simple), the app shouldn't get access to the internet without going through the authorization proxy. Imagine the app can only access web via your own managed proxy. You don't give it any cookies or certificates unless it goes through it. Now the proxy would have to know, for each app, which type of resources it has access to and what it can do with it. Perhaps some app's on your system and then you open when comfortable.
Justin: Here the authorization agent lets you make decisions in a safe space and then store the result.
Authorization screen:
Henry: In the launcher app view, the App is the one that has the key to sign the headers. Another app has to ask for a signature and will only sign if request is on resources of the right type.
Justin: You need it to be able to keep secrets. So if it's a safe space locally or remote... We're not opinionated, but it's not the App you're trying to use, it's something that allows you to make the decisions.
Henry: You need an ontology to know whtt will be asked for.
Justin: Have to go, but let's carve more time for this discussion.
- Matthieu to elaborate on UC3 with adding someone to a sub-container (WAC requires copying the base rules).
- Follow up on UMA discussion next week.