Skip to content

Latest commit

 

History

History
186 lines (127 loc) · 9.9 KB

2022-02-15.md

File metadata and controls

186 lines (127 loc) · 9.9 KB
Raw

W3C Solid Community Group: Solid Editors

Present

  • Sarven Capadisli
  • Justin Bingham
  • Kjetil Kjernsmo
  • Tim Berners-Lee
  • Ruben Verborgh

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.
  • Join queue to talk.

Participation and Code of Conduct

Scribes

  • Sarven Capadisli

Introductions

  • name: text

Topics

  1. Decide upon scoping principles for 1.0 (finishing what we currently have quickly vs adding implemented features)
  2. Any issues that should be solved urgently for 0.9.x before starting 1.0?
  3. Determine and publish high-level roadmap for 1.0
  4. Determine criteria for inclusion of features into 1.1 and beyond
  5. How do we publish working drafts for new features?
  6. MuSCoW of concrete issues

Notes for Milestone 1.0

Scoping Principles for 1.0

  • JB: Propose that we list items in order of priority and then assign versions to them afterwards

  • TBL: Produce a spec has 0.9.x and has Secure WebSockets and nothing else. we need to get it into the spec and roll it out into the implementations and concentrate on that. It is much smaller than VCs, consent etc.. When we call it 0.9.6... so we can then talk about 1.0 . Happy to talk about 1.0 and after that - whatver is included in it / prioritised. Top priority is Securre WebSockets and nothing else. I agree we should prioritise.

  • RV: Another concern is about perception.. it is about a number and so on.. if people see 1.0 they see it as an important version. For example, for consent it is important for 1.0.. people might think that it has/doesn't have consent and say things about the project.

  • TBL: Could we promise that in 1.0?

  • RV: Somehting like consent is seen as very important and may be easy to shut down if it is not in.

  • KK: Can that be in draft form?

  • TBL: Suppose we prioritise things.. 0.9.17 etc.. But we can start in parallel 1.1 .. do this prioritisation, and have consent after. We could create a spec 1.1.. ~CR .. requesting people to implement and we can say 1.1 exists. It exists. I think it'd be good to make a placeholder spec for each version.

  • JB: If we remove the word version temporarily.. we essentially talk about key features e.g., Secure WebSockets.. we can build out the list. I don't think for certain commercial orgs 1.x is important (???) but we can have the list that can be more attractive.

  • TBL: I disagree.. we haven't produced any documents.. I said we produce 0.9. Not allowed ot design new stuff. 0.9 is an impotrant focus. We all had lists.. kanban boards in various tech.. but need to focus from the very top of the list. We should draw a list and agree what's at the top (e.g., Secure WebSockets) and concentrate what's at the top of the list.

  • KK: It makes sense to get the ~WD out. I haven't seen certain org's consents. Consent is a blackbox to me. It makes sense to get that out in the open and then work on it.

  • SC: It takes time and experience to call whichever "consent" solution is for 1.0 - maturity of the solution along with implementations.

  • JB: There is lots of stuff on consent. There is stuff in data interop and also in research space. There is lots of efforts to make sure... ??? and to have alignment.

  • TBL: Is there anything in the interop spec that requires changes to the server?

  • JB: You can implement it without it. There is client id based security that's important. Having data validation on the server side is better e.g., have clients that would work better.

  • TBL: Where is the consent flow... nevermind the validation.

  • JB: Possible without introducing a custom VC API. It is added layer for trust/integrity - or for authorization based on consent decision. We acknowledge there are different ways of doing this. Need to look at what's out there and coalesce.

  • SC: {stuff}

  • TBL: When we prioritise things.. two lines: changes to protocol that the server has to worry and things that the server doesn't have to worry about. We kind of miss that.. that involves a wider set of people from the community. If they want to know when they'll have consent - it is basically a client-client protocol, it is a different spec..

  • JB: I think we can look at what those layers relies on.. Have to get more specific than just saying consent or just saying verifiable credentials. VC on its own is too broad.

  • KK: Dependencies that the 1.0 has.

  • SC: {reviews/summaries scope near future / long term}

  • JB: if we can come out of this session what the list is / priority / promises.. then we can go to the next thing. So this is what's on our plate.. and we can point people to that.

  • KK: Things for milestone we need to publish.

  • TBL: The roadmap is high/low-level?

  • KK: Some stuff is low/high..

  • TBL: https://solidproject.solidcommunity.net/Roadmap/

  • SC: Assuming Secure WebSockets is wanted next. Let's jot list of things that should be finalised in the next release of the protcol spec (near term):

    • Make sure all specs that's normatively referenced should be mature/final releases (at least post-CR level with multiple implementations developed by different parties)
    • Considerations sections: Security and Privacy Questionnaire, Societal Impact
    • Clean up existing/WIP e.g.: issues marked with revisit 1.0, required request-target forms, auxiliary resources, storage description, owner, creator...
    • A new N3 Patch type that handles variables (missing functionality from SPARQL Update)
    • Request Horizontal Reviews
    • Post-next-release stuff to look into: HttpSig

  • KK: Top of my head:

    • Should we disallow multi-resource operations on resourse-centric interfaces?
    • Should we have constraints on resource naming?
    • Constraints on resource state
    • Discovery (dependency for notifications and general hypermedia APIs)
    • Fully testable and tested
    • SPARQL

  • JB: (mine are features i'd like to see more in force ranked order over time)

    • Discovery of server configuration (i.e. well-known/solid equivalent)
    • Access control modes: add create / append / update / delete
    • Access restriction by client identifier - add to WAC
    • Access control policies
    • Server-side Data validation - shape validation, shape tree validation
    • Access Requests / Grants with pathway for legal basis
    • Pathway for establishing data integrity (e.g. VCs)
    • Pathway for Transactions (safe modification of multiple resources / rollback on error)

  • RV

    • Authorization that addresses all use cases / concerns
      • if fixing WAC
        • Create mode
        • Groups
        • Client ID
      • if going with ACP
        • a full ACP spec
    • App identification
      • for use in WAC, ACP, …
    • Consent (?)

things for future levels

  • TBL: not in order, trying to channel others - not sure

    • Server does the W3C consent request/grant protocol
    • Server uses posession of a VC for authentication of agents
    • ACPs
    • Server uses the consents data for request acess auth
    • Query - Quad Pattern Fragments
    • Pod level (¿¿server level??) metadta about services

  • TBL: not in order, what would be cool for the patform

    • N3 Patches sent up the notifications
    • Offline first, Local first
    • RSA crypto based identity
    • Web of trust
    • Dynamically loadable apps, panes, applets
    • Client-side encryption Back-compatability us really important for any changes

  • SC: My understanding is that we finalise the priorities/todos/direction, publish the minutes, share the plan with the community and request feedback, consider making changes based on feedback, publish blogpost summarises all of that.

  • KK: we need to formulate the milestone carefully so that the communication/intention is clear. We can't publish the minutes before it is carefully worded. It is part of the record.

  • JB: Anyone that goe sinto minutes and expects more than minutes probably has too much expectation. Unless we record decision/action item. Even for WIP context is important.. I agree with you getting the milestone out it needs to be published more. We need to break down some of the items to give more context. Starting to discussion for stuff we want to consider.

  • JB: Another half day meeting would be useful to add more context.

  • SC: All agree to continue next week.