# W3C Solid Community Group: Data Interoperability Panel

* Date: 2022-02-23T15: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
- Tom H
- Stijn T
- Laurens D

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

* JB
* Pavlik

## Agenda

### Add grantedBy to DataConsent

https://github.com/solid/data-interoperability-panel/issues/246

* JB: Currently it's on Access Consent and not on Data Consent. I'm implementing it in sai-java and it is useful to have it at Data Consent level. sai-js uses it already on Data Consent level.

ACTION ITEM: Justin to make spec change

### Terminology - Access Consent

https://github.com/solid/data-interoperability-panel/issues/242

* LD: The issue was raised by Ruben as well. Consent is under some jurisdiction and has some meaning attached. If it doesn't fully match the legal term in may confuse the user. In issue we have some good alternatives.
* JB: I have no strong feelings against changing it. It is an opportunity to make design fitting legal contexts. Let's look at naming options.
* LD: I'm inclined towards the Access Policy. Also Access Clearance and Access Decision.
* TH: I don't have strong opinions.
* EP: Mentioned it may appear as a collision with ACP but wouldn't worry too much about it since policy is a pretty general term. Even ACP don't use this class it's just in the spec, and none of the snippets use that. Also the namespace is different.
* JB: I like policy. I think there is non-technical collision possibility. I see not having to do with that as advantage.
* EP: Besides technical bits, we should also things about how we talk about it - e.g. in new version of videos - talking about users using their authorization agent to set their access policies vs. access decisions. what makes sense for people to hear when explaining?
* LD: Agree with points made - think there could be room for confusion / misconstruing policy definitions, etc - but there are also a lot of overlaps between the two (similar to defining a policy within ACP). I do like that there's similarity but the differences complicate things. Access Decision may be a better term if there's semantic overlap with ACP spec.
* EP: The way i see how different components are implemented - the authorization agent records consents, then generates grants, then authorization server takes the grants and sets ACP or WAC. No single implementation would use them directly (aside from authz agent).
* JB: Does anyone know doodle like pool for choosing names?
* ...: We agree that we are going to change and we have a good list with choices we like.

### Access Needs for Public Resource

https://github.com/solid/data-interoperability-panel/issues/243

* LD: Use case is about hosting static websites on the pod and granting access to the public. We need a mechanism of granting access to the public.
* JB: +1 on establishing it. Thinking out loud, if we had reserved social agent's id, we could have agent registration for that where we could store public grants. This one would allow discovery of public data the same way.
* Pavlik: Do we really want to worry about the discovery because if they're public then they're probably linked from other public resources and do we need to worry about it? We need to think about how permissions are applied from authorization agent and represented in data grants. Would we possible make a public access registration rather than overloading a socal agent registration. We may want to add additional classes and make it a special case.
* LD: Agree that we should avoid overloading things - justin's point was interesting because if we could reuse the same discovery phase that could lead to useful use cases being implemented for application discovery. Might be interesting for some use cases (maybe not static site one). If you want to discover public resources with information about an individual. Do agree that we should treat it uniquely - but also should look to reuse what we've got
* EP: for the discovery, if we want to use a similar mechanism we currently ensure that its an authenticated request ... if we want to have public then request would need to be unauthenticated and allow public to be returned.
* LD: Good point
* JB: Could use another endpoint for public discovery
* EP: Could also consider adding to the registry set
* JB: But registry set isn't public
* EP: Could consider adding to main profile document. Main point is we just need static discovery here.
* JB: Would direct link to agent registration for public data from WebID Profile?
* EP: That would be simpler
* JB: If there was an agent registration for public grants are stored, with public read access and linked from WebID Document.
* LD: The static link would suffice, more important is how we define access needs.
* EP: Discovery sounds simple - access needs and grants need to be figured out. Think we should avoid overloading existing stuff. Use unique properties.
* JB: I don't object using different property
* LD: Agree don't overload - would be semantically incorrect to overload
* JB: Agreement on discovery - need to sort out access needs (adding to project)
* EP: What kind of access modes are we talking about for public
* LD: Suppose i have an application that's helping me make a static website for my pod, I need a way to express that what it creates should be publicly available (e.g. publicly readable).
* EP: OK. Makes more sense now. A little bit of a different flow because it's saying can you set the access on this resource vs. access to data that exists
* JB: We have difference with new data that gets created and data that is existing. I wonder if we are able to look at public in create access mode.
* EP: Not sure because if you have a workflow with draft to finish (and finish makes it public)
* LD: We should add this draft flow to the issue.
* JB: It sounds like ability to request making data public.
* [scribe afk]
* JB: Let's continue working on the approach with examples and aim at PR.

### Sharing access between social agents

https://github.com/solid/data-interoperability-panel/issues/238

* TH: The use case is around real estate brokers. The can use CMS system like kolibri, this sends link to a customer. Linker will create WebID etc. Later it helps user to put data in their storage. Later the data needs to be shared back with the real estate agent. We can assume that real-estate organization has WebID
* JB: The big part of this is an invitation workflow where invitation is a placeholder until WebID is created.
* TH: The idea is that the user doesn't have a pod yet.
* JB: In first draft we had a class called AccessInvitation, it was exactly for this purpose and I have implemented it in line with the original draft. During initial refactoring we extracted it out into separate mini spec. It sounds like we should start resurrecting it. So far we have what we cut out 5 months ago https://solid.github.io/data-interoperability-panel/invitation/
* TH: I will need to look at invitation part.
* Pavlik: Clarifying that the invitation. wasdesigned so that a data owner could grant access to. agrantee that doesn't have a webid yet. As soon as the grantee gets a webid it would be replaced with. afinal one. In this scenario the real estate agent has a web id, the user gets a pod and a web id, then some data sharing happens after the fact.
* TH: For. methis is the flow where social agent shares access to someone that did not request it. Here is the real estate agent that asked for. thedata, but the linker application says don't forget to share your data with your insurance provider. No direct connection between invitation to share data and sharing the data.
* JB: The real estate agent is looking to share their data or the other way around?
* TH: In this case an API provides data about you from the government.
* JB: So the real estate agent is requesting an access to the data from a person who doesn't have WebID or pod yet. They want to request access but data owner has to establish WebID first before answering granting the access.
* TH: Linker application supports user journey and orchestrates the flow of information.
* JB: Invitation flow is to share data with someone who doesn't have WebID yet. The invitation links above are mostly around that use case.
* TH: As real estate broker you want to have documents from clients, they send email with link to 'the linker'