Skip to content

Latest commit

 

History

History
110 lines (80 loc) · 8.15 KB

2022-02-15.md

File metadata and controls

110 lines (80 loc) · 8.15 KB
Raw

W3C Solid Community Group: Data Interoperability Panel

Present

  • Justin B
  • Angel A
  • e Pavlik
  • Laurens D
  • Stijn T
  • Eric P

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

Scribe Selection

  • JB
  • Pavlik

Agenda

What about file storage?

#240

  • JB: I think this is useful topic to dive on.
  • ...: I shared example with shape tree with is very permissive. We could add it as specific shape tree in the spec and it would have special role.
  • ...: The access management, what you give someone access to in that space may be different.
  • LD: What happens if this catch-all shape tree overlaps with existing shape tree that is also located there.
  • ...: If as an application you get generic grant to that shape tree, it could start messing up things there, should we prevent it.
  • ...: We could avoid issue by forbidding this catch-all tree to overlap with existing shape tree.
  • Eric: This scenario will happen if you have un-managed and than also managed.
  • ...: It sound good to start with not allowing an overlap.
  • ...: Argument could be made for more hierarchical apps which have more nesting
  • JB: This permissive tree is just another shape tree that is registered. It's pretty much provides a free space. I see danger with apps just using that in a sloppy manner.
  • ...: In the second example, let's say a Jekyll site. You could make permissive shape tree which is for a static website but has different IRI than mentioned generic (catch-all) one.
  • ...: ShapeTree would allow setting nested validation in shape trees below, just data registry wouldn't care about it.
  • Pavlik: how should access policies be adjusted based on these use cases? If you have multiple websites you might want to treat the whole website as a data instance.
  • JB: I like this example of managing multiple web sites and treating each as data instance.
  • Pavlik: Jekyll example where process that generates a static site need to be authorized and data can come from multiple places. What we do with data registration can be used to manage data pockets that you use to generate static website. Authorize people to edit the source data and then manage the access of the process generating it.
  • JB: We may need to revisit this issue when Wouter comes back.
  • LD: If one have multiple sites it would be interesting to manage access via Access Needs, we should elaborate to that when we look at setting access policies. I may dedicated issue.
  • JB: There is Access Need aspect and also discovery aspect, I think about current public type index approach.

Consider referencing notifications subscription from agent registration

#241

  • Pavlik: mostly capturing thoughts from another issue where we were talking about sharing access receipts. previously discussed it would be benefiical to use public inbox for first contact only then switch to access inbox.

  • ... could switch to notification subscriptions so that once we get access receipts we can subscribe to the agent registration for any further changes (e.g. the reciprocal registration). in that case we could skip any further access receipts. when the grant is updated we could rely on the notification from the subscription. they can also detect that i have subscribed and could avoid sending additional access receipts. a nice optimization.

  • JB: how far out is notification spec?

  • Pavlik: Main focus is on websockets right now. Jackson M was looking at webhooks - need to check with him. Do we rely on server to implement publisher or could it be externalized?

  • LD: Focus of notifications panel have been centered too much around websockets. LDN and webhooks are much more powerful and more applicable. Definitely improve access receipts.

  • JB: This fits pattern of solid focusing mostly on in browser applications.

Trusted consents and grants

#187

  • JB: I'm working on Access Consents and Access Grants in sai-java right now. We had some really good issues and use cases that has been bought up.

  • ...: Angel working on Authorization Agent also raised questions where is the consent and grant for the authorization agent.

  • Pavlik: We should group those use cases a bit. Authz agent is pretty specific, but other use cases should be documented. One use case was databrowser-like app that needed wide access. Also use case brought up by Digita sounds like delegation related use case.

  • JB: How consent and grant for AA would look like?

  • LD: I think this may clear up a lot of things.

  • Pavlik: Current we rely on the linkage between webid document and authorization agent, and this might be good enough in a way for now. Could have it as "hasResource" pointing to registry or registry set.

  • JB: Let's say I switch my authorization agent, if we only have the statement in WebID Document there would be no record of me having this AA in that period of time. I'm loosing record of my decision. It may be important looking backwards.

  • Eric: Is it general auditing problem which we want to solve in more general way?

  • JB: We have a good model to record decisions and this case seems like a gap.

  • ...: Similar if I want to give access to a person which I fully trust, for example in medical scenarios.

  • Eric: I agree but I don't think we are the only place where we would want such auditing. I can imagine that we may need more general solution.

  • ...: For example to have a way to find all the history of data, I think git blame approach

  • LD: I want to emphasize point on delegating control to some proxy, like a parent or relative.

  • ...: It sounds similar to describing access of AA itself.

  • ...: If we rely on predicates in WebID document we put a lot of responsibility there. If new AA comes and presents it's Access Needs to new authorization agent would it still work?

  • Pavlik: agree we need to address this admin equivalent use case. also have a similar use case where we have a representative working on behalf of a given organization. lets start with those use cases rather than start with authorization agent.

  • JB: Maybe action item is getting use case for application use case and social agent use case which would fall into 'admin equivalent' consent?

  • ...: We could get it done before next week session.

  • Pavlik: we should also address was angel brought up about hasDataResource. believe it was created as part of a use case to give registry access. data grants should be kept just for data registrations / specific shape tree. maybe we create a different consent / grant type. e.g. "generic data consent" that doesn't specify a shape tree. don't need to keep it exactly the same as a regular data consent, and also avoid relaxing the shapes for a data consent. if we start relaxing there the implementation experience could get blurry.

  • JB: hasDataResource is bit of an artifact. We had trusted grant before refactoring and it could point to registries. I think it my be error of omission that we didn't remove it. We could remove it and if it comes back it comes back.

  • Pavlik: I should be easy to remove it.

  • AA: issue #235