# W3C Solid Community Group: Data Interoperability Panel

* Date: 2022-04-26T15:00:00Z
* Call: https://meet.jit.si/solid-data-interoperability
* Chat: https://gitter.im/solid/data-interoperability-panel
* Repository: https://github.com/solid/data-interoperability-panel

## Present

- Justin B
- Laurens D
- Stijn T
- e Pavlik

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.

### Scribe Selection

* JB
* Pavlik

## Agenda

* Aligning authorization panel work with ACP

## Minutes

### Aligning authorization panel with ACP

* Pavlik: suggest we try to align authorization panel work with the work we're doing
* LD: Agree that we need to do this. Have been demonstrating integration of interop grants with UMA authorization server. https://github.com/laurensdeb/authorization-agent
* JB: Is this code the policy layer above or you do both layers.
* LD: Authorization service plugs module that understands data consents and uses them to authorize requests.
* ...: It plugs itself to the components js add UMA AS. There are some error messages missing. It also allows policy to be communicated.
* JB: Can you give some examples of what policy languages can be plugged in
* LD: I looked at ODLR and Special ??? I found some issues with compatibility with interop data model. Compliance checking algorithms are lacking for ODLR. They are more expressive and allow more freedom to express interop concepts. I still have one more month to conclude it so I needed to pick my battles. I'm looking for sai-impl
* Pavlik: posting an [issue to community server](https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1154) to add an authorization server - have you followed?
* Laurens: Have been following but need to follow-up with CSS team. Release of CSS4 changes how unauthorized errors are handled in the code. Previously errors couldn't contain link headers - so I had to write a workaround. Was planning on updating that issue and adding a link to these modules. There are some challenges in using externalized UMA authorization resources because you have to identify owner of a resource to identify the interop registry set by an agent or the ACP policy that governs a resource. Had to work my way around that. Code in the repo does deviate from UMA 2.0 spec in that case. Introduces a new owner attribute
* Pavlik: How do you assume the owner for a whole storags?
* LD: CSS makes asusmption there is one owner for a given pod and they always have R/W/C on the pod. May be hard to introduce owners at individual resource level. Assumes owner based on who owns the root of the pod.
* Pavlik: Agree i don't think we should have diff owners for diff resources in a pod. In grants we assume the same.
* LD: Agree that its technically possible but introduces a lot of complexity (e.g. which registry set is authoritative). Also a problem in authorizing through UMA assumes that the registry set is always accessible or at least that there's write access to the registry set. May not always hold true in case of multiple pods and multiple UMA AS. May split into an issue to discuss further.
* Pavlik: In OAUth it's best practice that a given RS has one AS. Would assume there's pre-established relationships between AS / RS.
* LD: Will be doing some cleanup in the repo, putting into NPM, and posting into Solid-OIDC. Quite a bit of testing which serves as documentation. If there's anything else useful please let me know.
* JB: I'm very exicted about all this progress. I would be great if next you could do a live demonstration?
* LD: Next weeks should be fine during the implementers slot. Today I can't make it to that call.
* JB: I'd like to dive into the discussed issues. We really need to bridge the gap between pure WAC with Solid-OIDC to something that is more correct with AS and UMA. I know about some project that Inrput is doing and using UMA.
* LD: In UMA package there is implementation of HTTP implenetation of UMA AS. If you want to add VS or something like that you can do so. It is build in very modular way. After that we can also talk about some challenges I've encoutered. Is the UMA token DPOP bound?
* Pavlik: No it isn't mandated to be. Access Token will be considered out of scope of Solid-OIDC moving forward. If you use UMA that's how you do the exchange for the access token. If not, then it's impl specific. Before when we have a global access token a malicious use could use it to access any resource server. Now the token would be bound specific between the AS and RS.
* JB: If you are not using UMA, there is just OAuth2 authorization server?
* Pavlik: Are discussing adding a spec for how to do this with UMA claims pushing, but may also have another that
* JB: You may use OAuth token exchange, you may use UMA claims pushing. The priority is to have spec describing that.
* Pavlik: Solid-OIDC doesn't want to restrict that, but would want to define how to do the authz exchange and possibly have a mini-spec for how to exchange ID token with authz server. Need to discuss with editors of protocol how to bring these things together.
* LD: Looked at how UMA claims pushing is done in inrupt libraries but my interpresetation of UMA spec is a bit different than that. There should be a normative spec that specifies how that should work.
* Pavlik: Can you make issue for solid-oidc repo?
* LD: Will make an issue for it and will try to join authz panel next week
* JB: I created issue 152 in solid-oidc as part of editorial feedback. Solid-OIDC spec makes references to AS which should implement UMA2 grant. I don't think this document needs more normative text but at minimum there needs to be much more context. If you are implementer of CSS now you need AS implementing UMA. Client sides need adjustments. Primer was adjusted to reflect changes in the spec but it doesn't show any advantages of using this flow.
* JB: Laurens, in terms of interop spec. Have you found any real hurdles?
* LD: Generally speaking it was working quite well. The flow that occurs on the level of AS we transform it into authorizaed application of authorized social agent. I haven't evaluated it for efficiency. I delegate my authz calls to the sai implementation. I'm concerned how many request it may start doing if you need to start iterating through all the data grants. I haven't noticed any structural problems.
* Pavlik: You're using directly data grants for authorization?
* LD: There's no intermediary in between - it directly invokes interop authorizer - which has a number of strategies for the different registries. For example - if you need a social agent registration or application registration - there's a strategy that handles data instance authorization. I don't use any intermediaries like ACP or WAC.
* Pavlik: That's really awesome. We were discussing some months ago that we could use them natively and implement on the AS side. At some point we discussed with Aaron about ACP that it's more oriented for read time optimization. In those cases it may be easier to evaluate with ACP for performance.
* LD: That's an interesting point because that's something I've considered - pseudo ACLs that can be used for materializing decisions that have happened in the past as an authorization mechanism. Have been considering this and its more or less the idea that we were discussing there. I think in the longer term this way of implementing compatibility would be a way to introduce compat layer between ACP and WAC.
* Pavlik: I pasted a link from the discussion in the Authz panel - pointing out it can project differently on resources or agents. We should talk about this abstract access matrix so that you can have social graph based communication of access but for resource server it may be more convenient to project it on the resources for access performance. https://github.com/solid/authorization-panel/discussions/203#discussioncomment-610302
* LD: This access matrix idea is really cool. Could see it working
* JB: I find it really interesting that you use the data grants directly for AuthZ
* LD: It is definitelly possible, it can still be further optimized. Next week I can present more details and have more polished version.
* JB: I had discussion with Aaron (Inrupt) tyring to ensoure that everybody is working together on common sturcutres for authorization. We were talking about data grants. He was working on proposal to instead of use custom vocabulary to use [ZCAP-LD](https://w3c-ccg.github.io/zcap-ld/) to model them instead.
* Pavlik - https://github.com/solid/authorization-panel/discussions/203#discussion-3320914
* Pavlik: ZCAP is really intended for delegation chains - but if aaron wants to do that would be happy to coordinate it with him. We could always mix them a bit.
* JB: If it reasonable and fisible we should give it a shot.
* ...: In the beggining of discussion Aaron wasn't aware that interop supports atenuated delegation.
* ...: If we can get parity on what we have it will be much easier to refactor such change in.
* ...: We shouldn't wait if we want to make such change.