---
# System prepended metadata

title: 'W3C Solid Community Group: Data Interoperability Panel'

---

# W3C Solid Community Group: Data Interoperability Panel

* Date: 2021-12-07T15: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
*

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

* Justin
* Pavlik

## Agenda

### Action Items from Last Week

### Establish patterns for supporting to successive versions of shapes and shape trees

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


* Pavlik: In Authz Agent implementation -= getting to the point of creating data registrations for specific shape trees. Should we allow for existing registration with instances, do we allow to change the registered shape tree or not? For the user, the shape tree shouldn't change ever (IMO) - if its events, projects, or tasks, it shouldn't bubble up to the user when things evolve. From my perspective, it would be useful to have semantic versioning. RDF you can already extend quite easily. Maybe you just increment the minor version. Based on experience / deployment - maybe there's a need for a breaking change with major version increase. Also may want to ensure there's a release tool to migrate data, but give applications a warmup period that they should start implementating that and data shouldn't be migrated yet. Let people start migrating data as applications begin to support it. Would be recommended period at which point you start migrating. After certain grace period people should be able to safely migrate. Maybe not part of spec but ecosystem requirement. As app developer implement the current and maybe previous.

* Justin: The most productive thing we can do right now would be to bullet out some assertions. Some ideas we want to test.

* Angel: Shouldn't have to force applications to move to a new version after a certain amount of time. I don't want an app to stop working just because a shape tree moved on to a new version.

* Justin: I agree. We don't want shapetree version management be something users need to deal with. If the application needs to end up dealing with it, the user will need to deal with it. My guess is that we will have less cases with breaking changes with shapetree definitions than shape definitions.
* ...: Is it best practice / convention or part of the specification. For the most part is best practice / convention. In the spec we would just put how to identify versions. I think you need convention which stresses backwards compatibility. Rather than saying that you need to migrate your old data..., maintaining both may create a bunch of other problems.


* Pavlik: Few comments - what if i want to use a normal application that isn't as rigorously maintained. If i only use it for my own data, i could make a choice not to migrate. Migration shouldn't happen automatically. Authz agent should keep some stats with an access log it could analyze to say that based on last X months activity, you could know which applications may/may not be affected. Gets more complicated when user is not the data owner (e.g. Bob on behalf of Acme). Breaking changes would always need to be justified. Bob would need to use two applications for his own data - and then pick a maintained application to access Acme data. Breaking changes should be justified but need to anticipate them happening. Should provide as much as possible that whenever something makes that decision, they have a log of data. If you don't know the data you don't have control over what version it's at.

* Justin: Ideally you would avoid data migration, it is always difficult. Can you have many instances in a data registration. Can you have instances which conform to v1 of task and v1.2 of task. Those are no-breaking changes versions. Server determines which shapetree it conforms to. Instances could be assigned based on which version it match. It could test newer version first and go back. For non breaking changes it would be ideal not to do data migration. For braking changes I'm worried about migration creating a breakage. 

* Jamie: Migration does seem risky - but can you say that things that go in the container are required to fit a specific version. Can you ask for something based on version conformance (e.g. asking for something in 1.3 but would like it in 1.2).

* Justin: You could do that. Solid server would need to support ability to pass back something in a given representation. ... 

* Jamie: Let's say I have task manager, it shouldn't require to add priority to every single data you have.

* Angel: What happens in inverse case. What happens if you have priority field... User can expect some field which is part of application but is no more in a data model.

* Justin: If you remove something in the latest version, and applications stay conformant they would be equipped to handle it.

* PAVLIK: Need to work out breaking / non-breaking changes with some examples. Doubt we can avoid having some kind of migration step. There will always be trade-off / burden on someone. Don't think someone should have two different data regsitrations because they have different major shape tree versions. Permissions are also affected - would be very messy to partition data based on version of the shape tree. Fair to put burden on application developers. Should write down what are the assumptions that we don't expect the user to deal with that. Decide that those two are conflicting and move the burden to the application developer.

* Justin: We also should split app developer on two parts, authorization agent developer and regular app developer. More burden on AA would be better because is the most specialized application.

* Pavlik: Agree whatever the authz agent can do without burden on end-user that should have highest priority to avoid. Will take some work to clarify 

* Justin - Agree we don't want to end up inadvertantly passing along to end user through authz aghent


* Pavlik: For backwards compatible this shouldn't be very problematic. Really should only be breaking changes. Should be very infrequent. Resource server could track access - which application has been accessing certain registrations, it could tell the user based on access history whether something can be updated. Should be seamless.

* Justin: Based on the data that we have, we already know which application are accessing which kind of data. AA can look and know what applications would be affected by this. It would know which application were used in let say last year.

* Pavlik: If we have a data registration of acme and alice is using certain applications, unless we notify upstream the delegations then the authorization server of acme will not know which user is delegated to which application. May need some upstream notification.

* Justin: We should determine if version identifier should be added to shapetree specification.

* Barath: How would the version be used?

* Justin: The version would be used in the event of change of shape tree definition. It may be bit gray, what if shape changes but not shape tree definition changes.

* Barath: Is the value to have monotonic increasing counter. You know it changed by the virtue of the data. But version number could add sequencing. It also could tell if syntax have changed or also semantics have changed.

* ...: Shape can describe a health record. Gov agency may decide that some field will be reinterpreted in a different way. The data will stay the same but meaning would change.

* Pavlik: Barath can you make issue describing the scenario you described? Makes sense to start to track these things.

* Pavlik: Data registration should at least point to major version (e.g. all instances point to this major version.) (JB +1)

### Finalize design for Trusted Consents and Trusted Grants

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

* Pavlik - sharing screen with diagram from 187

* Pavlik: At least every user would have authz agent. Question of how Omni gives admin level access to bob (trusted grant), and then how delegation is done. Treat separately.
* ... When resource server is being created for omni, they would create an authorization server - which is responsible for holding the policies applicable for that resource server. Need to be a way in this bootstrapping step to give Bob a trusted grant.
* ... Authz server o f omni would have this initial trusted grant that bob has full access. whatever bob can do, omni can do. Always a person that would do something. In the initial case we can imagine that for acme bob is the acme ceo. Based on the grant, bob should be able to use the authorization agent. He can be CEO of two organizations (omni, yoyodyne), but they should be able to use an authz agent...
* .. struggle to point out - at minimum there needs to be full access to...
* .. in topic of trusted grants we have to decide if we need more specific ones fo data registry, agent registry, access consent registry. don't know if we need trusted consents vs. just trusted grants.
* ... based on the intiial trusted grants bob would create consents based on the initial trusted grant
* ... need to separate these topics

* Pavlik: Good starting point is to have a trusted grant that means access equivalent to the data owner (full access). Someone wants to have the same equivalent access (e.g. Bob want to have equivalent access to omni).

* Eric: Whats difference between Bob and Omni? Do they always need people to do something?

* Pavlik:

* Eric: When you say you're acting on behalf of omni is there a role in there as well? At W3 there is an advisor committee rep and that person is also a team member and they have one login that serves two different roles. actually they have two logins. they get to vote because they're on the team, and also because they rep MIT (so they have two votes). Somebody at omni can write checks because they're in an accounting role, and see sensitive data because they're in. aresearcher role.

* Justin: Trusted grant - owner equivalent one, we have already role of the owner. Anything else would just fall under regular consent grant process. The most obvious recipient of trusted grant is the authorization agent. 

### Delegation chains use cases


---

PROPOSAL: text
* name: +1,0,-1
*

RESOLUTION: text

ACTION: text
