# W3C Solid Community Group: Data Interoperability Panel

* Date: 2021-11-16T14: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
- e Pavlik
- Barath
- Eric P
- Jamie F

---

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

- Justin B

## Agenda

* Justin: We have very few issues left on the project board. I'll be working on the two In Progress items, should have them ready for review next week.
* ...: Looking at todo, besides fixing dark-mode and adding acknowledgements. We have three outstanding issues left.
* ...: I think we can discuss trusted grants today. For references list it will be good to have clear use case to discuss it around.

* PAVLIK: On #210 - one of the last authentication meetings, there was no intention to require content negotation, so authn was assuming to only require JSON-LD. we should get back to them and suggest that the common denominator be that it be hosted on solid storage so there can be conneg. From our side, how would having just this static JSON-LD work? For now this profile is only used by authorization agent to get access needs. Don't think it's a huge burden to have JSON-LD parser on authz agent.

* Justin: If we update interop spec, saying that application need groups should be stored in a different public resource than application profile. I would reduce the footprint by a lot. There would be less surface area to worry about the profile. One would still need JSON-LD parser but it would simplify things a bit.

* PAVLIK: discussing https://github.com/solid/solid-oidc/pull/18#issuecomment-968956762

* ...: This is the latest sequence diagram from the PR that denotes the authorization server. Diagram shows where the user is authenticated with which party. Address authenticating the user, and also identifying the client. Client ID document includes the redirect uri, and then redirect uri is included in the profile. Allows us to verify that it is the identity of the client. Another way to verify the client would be through static registration (e.g. webid of the client used as client id), and client secret is created and then the client credentials flow is used.
* ... who do we want to make respondible for verifying client identity? should it be redirect or client credential flow? should openid provider take that responsibility or should the authz agent do it? if you want to do the static registration should it be done with openid provider or authz agent?
* ... in the authentication part, there's not a strong reliance on the client identity, when user gives consent we should identify the client somehow, but most important part of client id is authz related. could be reasonable for authz agent to have that responsibility. something we need to consider - don't have a clear preference at this moment. already rely on OP for user identity, so we could rely on it for that.
* ... when talking about authz agent, authz agent would likely also have its own authorization server. most interesting part is who do we want to make responsible for verifying client identity?

* Justin: Right we have OP doing to much, identifying the user and giving access token without any scope. Splitting out the responsibility with AS, which will figure out what client is allowed to access.

* Pavlik: Correct. Also note that there would likely be a claim token format that needs to be devised. Could push relevant data grants which authorization server. Would also have access to agent registrations and verify that a client is allowed to access something. Alternatively, token introspection could allow resource server and authorization server to coordinate on policies. Could use ACP/WAC however they like. Left for authz server and resource server to ... makes design more flexible and acp/wac details can stay relevant there.

* Justin: UMA is one implementation of this pattern. That would mean that you need Authorization Server (or Authorization Agent that is UMA compatible)

* Pavlik: possibly we only need pushing Claim Token

* Justin: I would be nice if we can keep it simple

* Pavlik: May not need to redirect to interactive claim pushing and just use claim pushing and established token format. What would be the spec for the authz server? 1) Should understand the data grant formats 2) how does it coordinate with the resource server? if it uses acp, then add something small to acp that adds client constraints per user. acp right now just restricts client, but should be a way to do it per tuple agent->app. something that we should take on weds calls.

* Eric: Would it be easy to move ACP to standards track [equivalent].

* Barath: I was talking with graphmetrix folks. Their model is non hierarchical. They don't use containment to indicate hierarchy. As soon as you do that we break WAC and ACP assumptions for hierarchies. It may take some heat off WAC / ACP discussion and accept multiple access control paradigms.

* Eric: I think people may still argue need for ACP if we have WAC.

* Justin: I don't think the only way to prove that design is good is to prove that all the other designs aren't.

* Eric: We have shown couple of cases where WAC doesn't do it's job. We could say A: WAC as deployed doesn't do job B: We can't change it without breaking existing implementations C: If we make something new we can introduce more braking changes.

* Barath: Do we have any public use cases from graphmetrix?

* Justin: I think the difference is that they still have containment hierarchy but they don't use semantics of URI.

* Pavlik: One should be able to rely on `ldp:contains` statements. More complex may be allowing multi parent hierarchies.

* Justin: I'm in general advocating for flatter spaces and shape trees let you model virtual hierarchies.

* Pavlik: In TS implementation I'm going to encapsulate URI creation logic in mixin class to easily change it later on.

* Justin: I agree with Barath that authorization systems often need those hierarchies.

* Eric: People expect something like hierarchies do the job for them. In shapetrees we have references to implement virtual hierarchies.

* Barath: In other systems I saw it happening by changing access control manually on each resource. If someone uses old client library you will not get the same implementation of recursive update.

* Eric: If I have one giant filesystem I would need to impose some hierarchy on top of it.

* Justin: I guess that their resource have types like container. Possibly they also do multiparent.
* ...: From interop standpoint it may not affect us at all. But it affects authorization and access control.

PAVLIK: Finishing generation of data grants from data consents into the sai-js implementation. Would be good to review it on wednesday call. Would be good to get data grant vocab changes done (in progress on spec call)

### PRs and Issues

## Action Items