Skip to content

Latest commit

 

History

History
120 lines (76 loc) · 8.08 KB

2021-10-26.md

File metadata and controls

120 lines (76 loc) · 8.08 KB
Raw

W3C Solid Community Group: Data Interoperability Panel

Present

  • Justin B
  • elf Pavlik
  • Angel Araya
  • Jamie Fiedler
  • Barath R

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

  • Justin B

Agenda

PRs and Issues

Incorporate Profile Requirements from Solid-OIDC

  • Justin: Solid-OIDC has some requirements for Social Agents and for Applications. In general our designs were meant to be complementary. In our spec document we haven't included Solid-OIDC properties in Social Agent document. There are also some differences in Application documents. I think we need to address and reconcile them.

  • Pavlik: I agree that we should work on that.

  • Justin: For Social Agent profile, is only solid:oidcIssuer has to be included?

  • Pavlik: yes, only this one is required

  • Justin: Should we include it in Social Agent Document

  • Pavlik: Yes, it will make it clear how the specs are overlapping.

  • Justin: Does anyone objects including it?

  • Pavlik: Probably only for personal WebID Documents, not for organizational ones.

  • Justin: Application profile document and Client ID Document need to be reconciled. In both it's an URI that should be dereferenced to get the document.

  • ...: Solid-OIDC mandates that it should be serialized as JSON-LD with specific context (unless contneg requests different). I want to clarify if we will have any conflict in what specs are expecting.

  • Pavlik: For solid-oidc i think it was decided a bit in isolation that the IdP would not have to parse RDF and if we put an RDF requirement it would increase complexity on the IdP (only need a JSON parser). It also came in when OIDC client registration came in. At first when it was webid / turtle with stringified json. If we made it JSON-LD it could be actual JSON.

  • ...: I would like to bring it next monday to the conversation and then present it in authn session next monday. It makes it very specific to the requirement for how the IdP would be implemented. Also then hosting those documents in solid storage could be problematic due to JSON-LD compacting. If there is solid storage using quad-store it could changed via serialization / de-serialization. Given those arguments it could be possible to change it.

  • Justin: If it doesn't change - if solid-oidc maintains the same requirements - how does that impact the interop spec as currently defined?

  • Pavlik: If you want turtle then you can negotiate for turtle then it should be respected.

  • Justin: If we can solve it with content negotiation - we still need to reconcile some of the properties, for example logo_uri (we have thumbnail). Also client name. Even with content negotiation we still need to "merge our docs together"

  • Pavlik: Agree. Similar to working out best practices for social agent, then we should do the same for clients. Should be possible to adjust the context to describe applications across the ecosystem.

  • Justin: The ideal outcome could be that you can content negotiate for JSON-LD or Turtle and we agree on combined contents of client document across both specs (and others in the ecosystem).

  • Pavlik: Agree - could have mini specs for social agent profile and application and other specs can reference those.

  • Justin: taking action to raise it at editor's meeting

  • ...: Last Wednesday we agreed to have spec for identity document for Social Agents, I think raising it for applications should get the same support.

Best Practices for Profile Predicates

  • Justin: I think this is really useful for the same reasons we just discussed. We also get real exploration of interop specification. My experience has been that number of people who are aware of it don't know exactly how it works. We should try to foster a little more understanding. This way we can get more understanding and support.

  • Pavlik: IANA has link relation registries, and maybe each spec should have a registration of properties (like IETF introduces specific claims / values and defines a registry where you have a process to register them). Each profile can start with initial number common across existing specs - additional ones can specify new properties.

  • Justin: Aside from being aware of it and supporting I don't know if there's anything else for us to do on it.

Vocab Review

[Define means for Access Grant Subject to Verify]#107

  • Pavlik: Since we rely on discovery of authorization agent and agent registration, the access receipt is really more of a ping. If we see who shared access with us, then at least we can verify that this registration is from that agent
  • Justin: Let's say I share some project data with Jamie. I have Social Agent Registration for Jamie in my Agent Registry. I could push receipt directly to Jamie's access inbox, or I can ping their Authorization Agent and provide it.
  • Pavlik: Aren't we assuming that Authorization Agent is subscribed to changes in Access Inbox?
  • Justin: In spec we are not specifying it. But we might also provide API to notify Authorization Agent.
  • Pavlik: If Jamie's authz agent receives the notification, how can he verify that it's from you. Jamie's authorization agent would go to Justin's webid, discover his authorization agent, and then would discover the social agent registration for Jamie (the one it discovered). The message is just an invitation to discover it. Registration doesn't even need to be included in the message, just a prompt to come and discover.
  • Justin: I think that works, we need to detail this in the spec.
  • Pavlik: Small PR - doesn't introduce anything new.

#174

  • Justin: It's not a blocker. In a scenario where I grant access to prescriptions but not a main medical record resource. I don't want them to modify the main medical record. I think shapetree specification can detail those external references. In interop we could describe them as data modeling best practice. We might need to make it normative.
  • ...: People end up making over expressive documents which include data they shouldn't.
  • Pavlik: Do we have this use case documented somewhere.
  • Justin: The closest one is conditional-by-relationship https://solid.github.io/authorization-panel/authorization-ucr/#conditional-relationship

Next meeting timezone (which one we pin it to?)

  • Pavlik: For me all good, just need to know which one.

PROPOSAL: next week pin it to 10AM ET

+1 Pavlik, +1 JB

RESOLUTION: next week pin it to 10AM ET

Misc

  • Justin: GHENT university started working on SHACL support, they mentioned shape tree support on a thread. On Friday Eric and I will do walkthrough over latest shapetrees spec. I'll drop link on the gitter, please feel free to join, I'll also try to record it.

Action Items

  • Justin to raise application profile specification at next protocol editor meeting.
  • Pavlik to raise application profile specification at next authentication panel meeting
  • Pavlik to create PR for Authz Agent share notification (#107)