search

w3c / strategy

team-strat, on GitHub, working in public. Current state: DRAFT
157 stars 46 forks source link

[wg/lws] Proposed charter: Linked Web Storage Working Group (ex Solid) #377

Closed pchampin closed 1 week ago

pchampin commented 1 year ago

New charter proposal, reviewers please take note.

Charter Review

Charter: https://solid.github.io/solid-wg-charter/charter/

What kind of charter is this? Check the relevant box / remove irrelevant branches.

Horizontal Reviews:

Communities suggested for outreach:

Known or potential areas of concern:

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

Anything else we should think about as we review?

himorin commented 1 year ago

Personal question during drafting i18n HR, do ones listed in Dependencies are really 'Dependency' or extensions to Solid Protool??

csarven commented 1 year ago

I believe it is intended along the lines of required orthogonal modules ( https://www.w3.org/TR/spec-variability/#subdivision-module ) or components rather than extensions ( https://www.w3.org/TR/spec-variability/#extensibility ).

himorin commented 1 year ago

No comment nor request from i18n

siusin commented 1 year ago

Is the PING interested in reviewing this charter? @sandandsnow

ruoxiran commented 1 year ago

APA will review this charter at next week's meeting, sorry for missing this one.

ruoxiran commented 1 year ago

no comment from APA

plehegar commented 1 year ago

(PING has comments, coming soon)

plehegar commented 1 year ago

(no comments from PING)

2023-09-15: PING comments were simply to align the charter with the charter-template, which was done.

plehegar commented 1 year ago

2 comments:

[[ Adopted Draft: Solid Protocol, Version 0.10.0, eds. Sarven Capadisli, Tim Berners-Lee, Ruben Verborgh, Kjetil Kjernsmo. W3C Solid Community Group, 2022. ]]

should read [[ Adopted Draft: Solid Protocol, Version 0.10.0 ]]

Also add the names of the proposed chairs.

plehegar commented 11 months ago

The Solid specification contains a LOT of normative references to document that have been developed in Community Groups. This MAY become an issue when the document attempts to move to Candidate Recommendation and beyond. See also considerations for normative references (which will need to be placed under a better process to be revised).

plehegar commented 11 months ago

The Solid specification contains references to Identity and Authentication. The spec will need to better integration with the rest of the identity/authentication efforts at W3C.

rhiaro commented 10 months ago

Sorry for the delay in getting the TAG review of the charter out. The following review represents consensus of the TAG.

Solid WG Charter review

Scope

The focus of the charter (covered by the mission, and the name of the WG in particular) should be around a problem space, and not a particular product or existing solution. While having well used and incubated existing work as inputs to a charter is of course valuable and necessary, in this case it sounds like the outcome is a foregone conclusion.

This is particularly important as the motivation in the charter touches on many very broad areas - identity, data access, privacy, decentralised trust - all of which are active research areas, and many of which are covered by recent or ongoing work in W3C already.

Having a well-defined and tightly bound scope for a charter is good practice - but applied to the problem space, not the solution space. At this stage, we should see a well-scoped problem space, and a range of input documents; but here we see an extremely broad problem space, and a single proposed solution.

Multi-stakeholder involvement

We're concerned that there's an underlying idea that a W3C WG is a place to rubber stamp something that has already been decided, rather than a venue to bring together multiple points of view to reach consensus on how to solve a common problem. It may well be that the Solid Protocol is the consensus solution, but we can't know that until WG participants have had a chance to examine their options. The current framing may deter people in the same problem space (personal data stores, and/or decentralised trust architectures) who are working on solutions other than Solid from participating in the first place, and the community would lose out by excluding their valuable perspectives.

This concern is exacerbated by the language around backwards compatibility with existing implementations - we'd be happy to be told this is not the case, but we sense a reluctance to deviate from what has already been specified.

Deliverables

The introduction mentions the Solid Protocol has been incubated and implemented since 2018, but the Security and Privacy Considerations in the spec are short and have no detail specific to the protocol. In particular, we see no mention of data in the personal storage being encrypted. This makes us question the maturity of the work, and compounds the concerns about multi-stakeholder engagement.

The out of scope section mentions identity mechanisms, but the deliverables mentions WebID and Solid-OpenID; is this in contradiction?

The five "dependencies" are actually deliverables - none are standard today and the charter suggests they group is planning to make them recommendations. Yet they are not listed on the timeline. The timescale seems ambitious for this amount of work.

Part of our focus is to help the architecture of the web stay cohesive, and encourage new specs/features to work with or build on existing parts of the web platform. In that light, we'd like more information on how some of the deliverables relate to existing or in-progress work, for instance:

Are any of the specifications intended as things that can or should be integrated into browsers? How do they fit into the wider web platform ecosystem? We're concerned about a silo of Solid standards which sit apart from everything else.

We encourage everything that comes for TAG review to include an explainer. Your explainer is a living document that describes the current state of your proposed web platform feature, or collection of features. In the early phases of design, this may be as simple as a collection of goals and a sketch of one possible solution. As your work progresses, the explainer can help facilitate multi-stakeholder discussion and consensus-building. The TAG would really value an explainer for each of the various pieces proposed here, with user stories and details about the relationship to existing work and considered alternatives.

Conclusion

We encourage you to reframe your charter proposal to anticipate more multi-stakeholder involvement from the outset, for example by taking the documents from the Solid CG as inputs, alongside other relevant work in the area, and working on a solution that solves the problem you have identified in a more holistic way.

One potential way forward might be to re-frame the working group as a Personal Data Stores working group, have the Solid specifications as some of several inputs to that group, ensure a wide community of implementers joins that group (wider than than the existing Solid community), and seek to integrate into or interoperate with existing, mature web technologies where possible.

timbl commented 9 months ago

Dear W3C TAG,

Thank you for your extensive review on the Solid Working Group Charter. We look forward to working together with you to ensure that the Working Group can start early 2024, and are available for any conversations that will facilitate this.

As you know, the Solid project is close to my heart, because it represents what I consider an important part of the future direction of the Web. As much as I appreciate your review, I do see two kinds of differences we’ll need to resolve together. One part relates to the W3C process, and the other to technical aspects of Solid.

Based on your guidance, we will refine the charter such that the TAG can review a version that clarifies any ambiguity that there may be.

On the W3C Process

The focus of the charter (covered by the mission, and the name of the WG in particular) should be around a problem space

The W3C Process Document defines problem space exploration as the role of a W3C Interest Group. A working group should take an existing and fairly mature technology and refine it very precisely until it has aligned specification, tests, and implementations.

While having well used and incubated existing work as inputs to a charter is of course valuable and necessary, in this case it sounds like the outcome is a foregone conclusion.

Rest assured that there is no such conclusion: “Solid” is the name for a technology in progress, passed as input for the WG to consider and refine. This is how working groups have always worked: recent WGs such as DID and VC formed similarly from incubated works and implementations in a CG and then considered, refined (or rejected), and formalized those inputs.

This is particularly important as the motivation in the charter touches on many very broad areas - identity, data access, privacy, decentralised trust - all of which are active research areas, and many of which are covered by recent or ongoing work in W3C already.

W3C is not a research organization. It refines and standardizes existing practice that works. Running code carries a lot of weight: while some W3C working groups struggle to get three independent implementations, the draft Solid protocol has around 6 already. This strongly indicates our need for standardization, rather than a rubber stamp.

At this stage, we should see a well-scoped problem space, and a range of input documents

The process of getting from a broad problem space to a specific solution space is incubation. In W3C that is done by CGs and IGs, not WGs.

We're concerned that there's an underlying idea that a W3C WG is a place to rubber stamp something that has already been decided

As already indicated above, much more work is needed than just a rubber stamp. Only the main direction has been decided – through years of incubation in a W3C Community Group and with many stakeholders. What hasn’t been decided is the exact format of the solution, and that’s what we aim to do in the Working Group, with those stakeholders.

On the technical aspects of Solid

The Security and Privacy Considerations in the spec are short and have no detail specific to the protocol.

Existing documents are inputs, and they are indeed not ready for a rubber stamp, nor do we want them to be at this stage. Refining and finalizing the Security and Privacy - and Internationalization and Accessibility - sections is something the WG will be well placed to do.

In particular, we see no mention of data in the personal storage being encrypted. This makes us question the maturity of the work, and compounds the concerns about multi-stakeholder engagement

The Solid Protocol is a client-server protocol, like HTTP, like CalDav. The role of the protocol spec is to define what goes over the wire, how it is constrained, and what it means. The role of the spec is not to constrain or second guess implementations. Because it uses HTTPS, the network traffic is always encrypted. If implementations want to use encrypted hard drives, encrypted filesystems, or encrypted databases to protect data at rest, that is their prerogative. The spec does not and should not dictate those implementation details, though it can and should encourage security and privacy steps to be taken in implementations, such as encryption at rest.

The out of scope section mentions identity mechanisms, but the deliverables mentions WebID and Solid-OpenID; is this in contradiction?

There is no contradiction: identity mechanisms are out of scope, so the OpenID/WebID mechanism allows for pluggable IDPs such that Solid can be IDP-agnostic.

The five "dependencies" are actually deliverables - none are standard today and the charter suggests the group is planning to make them recommendations. Yet they are not listed on the timeline. The timescale seems ambitious for this amount of work.

This concern is crucial to us as well; let’s work together on an adequate timeline.

I had understood the Linked Data Notifications protocol, standardised in 2017 by the Social Web WG, to be related to the Solid project. How does it relate to the deliverables here, in particular the Solid Notifications Protocol?

LDN is one notification channel that can be used with Solid. Other channels can be added in the future.

How does the Solid Notifications Protocol relate to Web Notifications? Since Web Notifications is relatively mature and enjoys multi-stakeholder buy-in, we'd like to encourage you to consider integrating with this technology.

Web Notifications is for delivering user notifications in a browser, not (AFAIK) for sending notifications from a server to either another server or to a client.

How do WebID and Solid-OpenID relate to FedCM? Are they alternatives, or compatible? Right now there is a considerable amount of multi-stakeholder support forming around FedCM so we would like to encourage you to acknowledge this work in the proposed charter.

They are compatible. SolidOIDC allows for pluggable IDPs, it does not specify what happens beyond that, so login may or may not use FEdCM.

Is ACP accomplishing similar things to CORS?

CORS is limited to scenarios 1) across origins 2) in browsers 3) for the current user. ACP defines fine-grained access control between servers, regardless of origin, and any kind of client or actor.

Would WAC be more at home as an IETF standard? Because it is built on top of HTTP, we wonder if it would fit better with that standardization work.

WAC is an input to the WG and by no means a predetermined outcome. Nonetheless, W3C protocols have historically tended to be above IETF standards in the stack, and so if something is built ON http, then there is an argument it belongs at W3C, as we see with many existing W3C standards.

Are any of the specifications intended as things that can or should be integrated into browsers? How do they fit into the wider web platform ecosystem? We're concerned about a silo of Solid standards which sit apart from everything else.

Solid is a profile spec of many existing parts: HTTP is pretty generic, OIDC is a huge industry norm. ACP is new, but WAC has been around for a long time and is not Solid-specific. Great effort has gone into reusing existing standards and technologies specifically so that Solid is not a revolution of all existing web standards (unlike blockchain), but rather built on top of them. The Solid Protocol is a framework which has already allowed, and will in future allow, things like the authentication, patch formats, and notifications to be migrated over time.

Explainer

We encourage everything that comes for TAG review to include an explainer. Your explainer is a living document that describes the current state of your proposed web platform feature, or collection of features

Absolutely, this is an important point and we have already started work on a comprehensive explainer. We’d be glad to walk you through it once we are ready, please stay tuned.

Meanwhile, we’ll work with the TAG to ensure that the final version of the charter will be the one that gets the Working Group started soon, as many W3C Members are eager to start standardization work on Solid. We’re open to any further questions, and look forward to the forthcoming conversations.

timbl commented 9 months ago

Solid Charter Review 2

(Note an earlier response by the TAG in fact was not a consensus of the TAG. Here is the minority report.)

The TAG thanks the Solid Community Group and the rest of the Solid community for its work over many years to refine this important technology, and for bringing it further along its track in W3C in the proposed working group.

The TAG recognizes an exciting technology which is user-empowering in a way that most of what we see is not. To be user-centric is a core value of the Web, and a core value of the TAG.

In the Advisory Committee review of this charter, there were opinions expressed by some that this WG should, instead of taking the specification as incubated by the Solid CG, should start a general review of the whole field of personal data stores and related products. The TAG points out that this would be the work of an Interest Group, not a Working Group. It is very important that specifications incubated in community groups (as well as elsewhere) have a clear path to WG.

The TAG notes that the Solid Protocol has rough consensus and running code, and respects that.

The TAG notes that the Candidate Recommendation status of a Rec-track document was introduced as a “call for implementations” when there was agreement on the specification but insufficient implementations. Noting that there are already more interoperable implementations of the Solid Protocol than many W3C WGs try to achieve to exit CR, it would be reasonable for the spec to skip the CR stage.

The TAG notes that while most of the dependencies are on Rec track or equivalent, some are not yet. The TAG is happy to work with the Solid WG to help prioritize the work involved, and also to negotiate with other groups to resolve these issues.

The TAG notes that while SolidOIDC is currently the form of authentication commonly used, that in earlier days WebId-TLS was in fact used, and there have been suggestions that other systems of authorization, such as those based on HTTP Signatures, have been suggested. The TAG encourages the wider community to help triage and develop new solutions in the space.

The TAG recognizes that systems build using the Solid Protocol are fundamentally more user-empowering, and so recommends that as the platform becomes more robust with the work on th Solid WG, that future designs of systems which involve storing user data should all be compatible with the Solid Protocol, just as we encourage designers to use URIs and HTTP, rather than re-inventing them.

The TAG notes that the Architecture of the World Wide Web Volume 1 [AWWW] document which it produced in 2004 is out of date, and undertakes updating it to worlds of Progressive Web Apps and Solid Apps.

This does not represent the consensus of the TAG.

[AWWW] Architecture of the World Wide Web, Volume One

timbl commented 9 months ago

We encourage everything that comes for TAG review to include an explainer. Your explainer is a living document that describes the current state of your proposed web platform feature, or collection of features

Absolutely, this is an important point and we have already started work on a comprehensive explainer. We’d be glad to walk you through it once we are ready, please stay tuned.

As promised, an initial TAG-style Explainer for the Solid Protocol. There will be others, I am sure.

plehegar commented 7 months ago

The Team is convening a Council: https://lists.w3.org/Archives/Member/w3c-ac-members/2024JanMar/0021.html

plehegar commented 4 months ago

Plan is to circulate a new charter around to see if we get a common ground. See also charter changes.

pchampin commented 4 months ago

Plan is to circulate a new charter around to see if we get a common ground. See also charter changes.

More specifically: a snapshot of the new charter is now available here: https://www.w3.org/2024/05/proposed-linked-web-storage-wg-charter.html. Anticipating a new submission of this charter to the AC (depending, of course, on the decision of the on-going W3C Council), I'd like to request a new TAG review.

simoneonofri commented 3 months ago

The Security Review follows:

Security considerations are appropriate when considering the scope of the protocol. A few improvements are suggested, as follows.

At the Charter level, I would suggest adding to the Success Criteria the creation of a Threat Model (at the LWS ecosystem level) and a structured analysis according to RFC 3552.

At the level of Deliverables, particularly on the Solid Protocol is the Security Section. Considering that the specification defines a

The Solid Protocol is a client-server protocol, like HTTP, like CalDav.

Based on HTTP, it refers to the related security considerations of HTTP.

Threat Modeling with STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) the considerations:

  1. Servers are strongly discouraged from assuming that HTTP request headers’ field values are valid or non-malicious.

    • Tampering: This relates to the risk of tampered request headers.

  2. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others.

    • Tampering: Sanitization helps in Data Validation/Injection vulnerabilities
    • Information Disclosure: Sanitization helps avoid unintentional data leakage.

  3. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements.

    • Tampering: Rejection of bad requests helps in Data Validation/Injection vulnerabilities

  4. Servers are encouraged to restrict untrusted requests. Servers are encouraged to apply normalization and canonicalization algorithms where applicable.

    • Tampering: Normalization and canonicalization help prevent tampered input.
    • Elevation of Privilege: Restricting untrusted requests prevents unauthorized access.

  5. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s).

    • Information Disclosure: Mitigating timing attacks prevents revealing resource existence.

  6. Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.

    • Information Disclosure: Minimizing exposed information reduces the risk of data leakage.

  7. Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar field values in header fields such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

    • Spoofing: Assumptions about the user agent could lead to improper handling of spoofed requests.

  8. Servers disable all cross-origin protections in browsers because resource access is governed explicitly by the Authorization component; as such, servers cannot rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource.

    • Information Disclosure: Disabling cross-origin protections needs to be carefully managed to prevent unauthorized data access.

  9. In particular, servers are strongly encouraged to ignore HTTP cookies from untrusted origins. Additional security measures can be taken to prevent metadata in error responses from leaking.

    • SpoofingInformation Disclosure: Ignoring cookies from untrusted origins helps prevent data leakage.

  10. For instance, a malicious application could probe multiple servers to check whether the response status code is 401 or 403, or could try to access an error page from an intranet server within the user agent’s private network to extract company names or other data, to mitigate this, when a request from an untrusted Origin arrives, the server may want to set the status code of error responses to 404 and/or anonymize or censor their contents.

    • Information Disclosure: Preventing specific status codes and anonymizing responses helps protect against data leakage.

  11. Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the server is behind a reverse proxy that terminates a secure connection.

    • Tampering: Using TLS prevents unauthorized data modification in transit.
    • Information Disclosure: TLS protects against data leakage in transit.

Given the Scope of the specification, it makes sense that consideration covers Tampering and Information Disclosure, and other Threats are delegated, such as:

Therefore, it might be useful to explicitly state that these aspects are delegated to the implementor and analyzed in a Threat Model.

plehegar commented 3 months ago

To make it clear: we're no longer pursuing the original proposed charter and expecting to send a new charter.

pchampin commented 3 months ago

@simoneonofri

I would suggest adding to the Success Criteria the creation of a Threat Model (at the LWS ecosystem level) and a structured analysis according to RFC 3552.

By "at the LWS ecosystem level", do you mean that the Threat Model should have a broader scope than "only" the LWS Protocol? That would make sense to me, but then do you envision this as a separate document? A Note or a Rec? Eitherway, it should not only be mentioned in the Success Criteria section, but also in the Deliverables section.

Is is what you meant? Just checking before proposing a PR.

simoneonofri commented 3 months ago

@simoneonofri

I would suggest adding to the Success Criteria the creation of a Threat Model (at the LWS ecosystem level) and a structured analysis according to RFC 3552.

By "at the LWS ecosystem level", do you mean that the Threat Model should have a broader scope than "only" the LWS Protocol? That would make sense to me, but then do you envision this as a separate document? A Note or a Rec? Eitherway, it should not only be mentioned in the Success Criteria section, but also in the Deliverables section.

Is is what you meant? Just checking before proposing a PR.

Yes, I would like to say a Note. Thank you for the clarification

plehegar commented 2 months ago

Apparently, TAG is fine with us moving forward. (via @ylafon)

plehegar commented 1 week ago

Announced