# W3C Solid Community Group: Data Interoperability Panel

* Date: 2022-03-01T15: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

* Wouter Termont
* Stijn Taelemans
* Justin Bingham
* Laurens Debackere
* elf Pavlik
* Eric Prud'hommeaux
* Jeff Zucker

## Regrets
*

---

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

* Pavlik

## Agenda

### Pull Requests

https://github.com/solid/data-interoperability-panel/pulls

* [Fix AccessNeedDescription pointing back to AccessNeedGroup #239](https://github.com/solid/data-interoperability-panel/pull/239)

### Issues

* [Terminology: Access Consent #242](https://github.com/solid/data-interoperability-panel/issues/242)
* last minutes to vote on new naming: https://pollunit.com/en/polls/osk8gjzizehvo-vqkbobda
* [TypeIndexen and DataRegistrationen #247](https://github.com/solid/data-interoperability-panel/issues/247)

### Misc

* Source of truth for access control (cf. discussion LDB & WT): Are these the consents/grants in the registries, or the decisions of the AS? In particular: can a (UMA) AS overrule AA consents/grants, either temporary or by changing the ACPs/ACRs?

## Minutes

### sai-java

* JB: I completed functional parts and now just add coverage. I can walk you all through next week and I welcome feedback.

### Fix AccessNeedDescription pointing back to AccessNeedGroup

[PR#239](https://github.com/solid/data-interoperability-panel/pull/239)

* EP: Made one small fix; seems good to go.

### Terminology: Access Consent

[Issue#242](https://github.com/solid/data-interoperability-panel/issues/242)

* JB: If you haven't filled out your preferences please take a minute to do it now. https://pollunit.com/en/polls/osk8gjzizehvo-vqkbobda
* JB: Last week the question was if there is free site providing such pools. This one seems to be working well and I was able to set up this pool using free tier.
* JB: In short Consent is bit loaded term and it may be better to use different name.
* ePa: Most people gave at least one dot for * Authorization so it seems no objections.
* JB: With authorization it seems nice since it includes Authorization term.
* EP: I want to make sure we don't use this term elsewhere
* JB: In the spec we have section talking about Authorization broadly, we could consider renaming it to avoid any confusions.
* EP: We don't have any structures with that name
* EP: Should we consider Data Access Authorization? It seems different to authorize Data Access than authorize Data.
* WT: I agree we don't need to add access but now we seem to have bit redundant terminology - Access Authorization.
* LD: I would stick with Data Authorization, I don't see need to add anything in between.
* JB: What about the main Access Authorization? Is it strange to say it?
* LD: Maybe we should make it consistent.
* EP: Authorizing data to me sounds like authorizing incorporation of data rather than sharing of data.
* JB: Data Authorization must have an Access Authorization it is part of, maybe that provides the context.
* ePa: I see it as good improvement. We may need to do one more, hopefully final, iteration when we have some examples going beyond Data Registrations. So Generic authorizations for data browser like apps and admin level / trusted authorizations.
* JB: Section 7 of the spec is called Data Authorization. It broadly describes authorization flows. Does anyone have any suggestions for new good name.
* LD: Why not *Authorization Flows* as you just referred to it.
* JB: I would also consider Authorization Patterns and *Authorization Scenarios*

ACTION: JB: to make PR with renaming and change section 7 title.

### Source of truth for access control

* WT: Cf. discussion LDB & WT: Are these the consents/grants in the registries, or the decisions of the AS? In particular: can a (UMA) AS overrule AA consents/grants, either temporary or by changing the ACPs/ACRs?
* WT: Laurens and I discussed AA AS and their interaction. What is the source of truth for the access control. If Access Grants set by AA it would be weird if AS couldn't overwrite it.
* EP: I see AS associated with RS, on the other hand AA is associated with User (RO sometimes also End-user). We would like to support applying authorizations across multiple RSs each possibly having different AS.
* JB: I agree. Access Authorizations and Data Authorizations in some cases will still apply to new Resource Servers.
* LD: Do you need UMA style AS at this point or AA which can configure UMA style ASs. I think you could make UMA AS understanding interop. It would also need to have access to Access Grants and registrations. Do we imagine ASs aware of interop spec?
* WT: I lost Laurens when he spoke about UMA. I don't know why it would be neccessary for AS to know grants and consents.
* elf Pavlik: Great topic for wednesday authorization panel. the way i see it is that authz agent needs to be able to do access authorizations and access grants. authz server needs to be able to access the access grants applicable to the RS it is associated with. then based on those generate ACRs / ACLs. keeps resource server from having to know anything about data grants. feels like an attractive separation of concerns. i think the authz server that implements UMA would need to be aware of access / data grants - then whatever the resource server is using (ACP/WAC/etc).
* WT: why would AS need to handle the dual roles - exchange of tokens / grant awareness
* elf Pavlik: it's a matter of what else we want to put on the authorization server in addition to exchange of tokens. ... seems to me nice to not put more responsibilities on the authorization agent. since the resource server and authorization server have a pre-established relationship it seems straightforward that the RS allows the AS to write all of the ACRs / ACLs. In the approach i see only the AS would need to write the ACRs / ACLs (i.e. control mode).
* LD: Agree with pavlik - some level of awareness needed on the UMA AS to interpret the grants and write the ACLs / ACRs. Concern if we implement awareness of the UMA grants, what does it do to the trust relationship. Does it need to establish a trust relationship with the pod owner to get their data grants? What if they are stored in a separate pod? Agree generally that we implement it in the UMA AS.
* elf Pavlik: Pod stores the data and needs to know what kind of authorizations are set from the resource owner. Authorization server controlling access to the RS that has the agent registry, would need a way to ... All of the data grants are pointing to specific data registrations, so it should be possible to determine which RS they are on, from which you can determine which AS is associated, and could give access to the associated AS.
* JB: We can also look at push based mechanism
* LD: I think push would work i'm worried about pull based mechanism.
* JB: If we have push based approach AS only needs to know how to translate grants into ACR/ACL. AA would be responsible for sorting out which grants need to be available for who.
* WT: I have some details but they can wait until tomorrow.

ACTION: Pavlik: to create issue clarifying AA AS RS interactions

### TypeIndexen and DataRegistrationen

[Issue#247](https://github.com/solid/data-interoperability-panel/issues/247)

* JZ: Working on the WebID profile panel / spec to document the system as it exists now. Don't want it to interfere with what we're doing - really like the plans and looking forward to seeing them in place. Nothing is meant to derail what interop is doing. Trying to see - especially in transition - if there's a way to provide continuity between new and old ways of doing things. Where possible - I want to write what I'm writing in a way to not contradict anything interop is doing, and hopefully dovetails with it as much as possible. In terms of consent, there's no way the current trusted app mechanism will mesh with the one proposed in interop. Not making any comments on consent process - interop is on the right track. Wondering whether the data discovery process can be phrased in a way that fits both of the systems, because that would allow transition, and let some apps that are not yet (or never will) be using an Authz Agent to have access to some data. An app like a bank or hospital wouldn't be involved in this. Would only be for apps that have the intention of letting other apps see their data. If I as a user trust an app, and choose to trust it, how is that app going to be aware of what data is being created on my pod by who knows which apps? Currently you go to the profile which is public, then to prefs file (private), and from there to private type index, which tells you container of the resource. In interop, instead of prefs and type index there's a data registry and data registration. Is there some way for an app that I fully trust to look in the type index and see things that are interop compatible (shapes / shape trees) to follow it to the data. How would you prevent that second pathway in any case? If you can't prevent it, why not make use of it
* elf pavlik: The approach you're describing relies on trusted app whitelist that lists the apps you fully trust - is that correct?
* JeffZ: Yes that's correct (and not defending that approach)
* elf Pavlik: ... we were discussing flow where user establishes authorization, then AA creates grants, and AS uses those for ACLs. For this kind of authorization pipeline it would be hard to add support for old system / trusted apps. I don't think we can back-fit it because trusted apps would have to be taken into account. We can discuss more tomorrow in authorization panel session.
* JeffZ: To clarify - I agree with you about trusted apps. Given the current situation, as far as I can see there's nothing other than saying it shouldn't happen that prevents an app will full write privileges from doing what I'm describing.
* JB: I think the heart of the matter lies here. In interop security model, it doesn't provide path for backwards compatible model. It would lead to what you describe that we can't prevent that full access. If you conform to the spec application doesn't have such trusted level access unless explicitly granted. Technically there is discussion what is perfect security model and what reality looks like. One could possibly use that pattern and drop security posture. We aim at giving people something as secure as possible with least priviledge approach. All resources are not only constrained by the end user identity but also by the client (app) identity. Solid-OIDC provides both identifiers. Once again you could have backward compatible mode but it would require relaxing security.
* elf Pavlik: agree with justin points. i have been participating since 2015 in solid - and there was little emphasis on authorization clients, but instead authorizing users. trusted apps was trying to put a patch on it, but not really giving users control on what clients do on their behalf. we're doing that here. when talking about giving apps access - are you talking about root level acl or
* JZ: I don't want to defend trusted app situation. What is going happen to data gathered by the current apps? What will happen to applications like SolidOS which needs to know everything about data.
* JB: You can implement interop spec in the storage. SolidOS could use different data spaces in the storage which is permissioned differently. Without backend component it wouldn't be an Authorization Agent. I'm not super familiar with SolidOS. I think SolidOS could do the bridging.
* JZ: I will not press on the proposal with Type Indexes. I will want you to give more attention what will happen with current data and with current apps. Especially current apps.
* JB: I think these are really good questions. We will be looking into those questions now.
* JZ: Since our group is going to define what exists, you will have a good reference.
* elf Pavlik: Want to point out that the approach we took is to make app development as easy as possible and put as little burden as possible on them. For JS we have typescript implementation. Justin also wrote a Java version. Always prioritized that app should be as simple as possible.
* JB: We'll circle back with you on that. Especially when we talk about migration paths. Let's keep the issue open.