Open pchampin opened 5 months ago
himorin
commented
5 months ago is expected to have at least two independent implementations of every feature defined in the specification., but why a word interoperable has removed?
pchampin
commented
5 months ago
- why start date is the same as current running charter?
no particular reason; the WG considers this essentially as a extension of its current charter -- the only reason to ask for a full-fledged rechartering is that we need more than 6 months. We can make the new charter start when the current one ends, if that's deemed more appropriate.
- success criteria has interoperability as
is expected to have at least two independent implementations of every feature defined in the specification., but why a word interoperable has removed?
The word "interoperable" is not in the current charter, I don't know exactly why. I suspect that it was not in the charter template when we created it –or it was removed by an unnoticed accident... I have no problem putting it back.
- may not rely on wpt, but success criteria does not mention about open test suite
Same as above: I suspect this was not part of the charter template 2 years ago. No problem adding this, all the more that such an open test-suite already exists for RDF and SPARQL: https://github.com/w3c/rdf-tests
- performance HR (in coordination) is no longer exists
?? it was never there, as far as I can tell... And I'm not sure it would be relevant for this WG.
xfq
commented
4 months ago
- performance HR (in coordination) is no longer exists
?? it was never there, as far as I can tell... And I'm not sure it would be relevant for this WG.
That has been removed from the charter template, and should probably be removed from the new charter as well.
pchampin
commented
4 months ago
- performance HR (in coordination) is no longer exists
?? it was never there, as far as I can tell... And I'm not sure it would be relevant for this WG.
That has been removed from the charter template, and should probably be removed from the new charter as well.
Oh, sorry @himorin I misunderstood your comment about performance, and thanks @xfq for the clarification. +1 to remove it from the new charter.
(edited) this is now done: https://github.com/w3c/rdf-star-wg-charter/commit/afca7a2d20131ce600a66f90ea5d8f3d43ca5a79
himorin
commented
4 months ago no comment or request from i18n
(sorry, wrong line pasted at the first time...)
ruoxiran
commented
4 months ago no comment or request from APA.
simoneonofri
commented
4 months ago Hi @pchampin:
I have seen that many deliverables are quite dated and perhaps earlier than was recommended Security and Privacy considerations:
Mainly there are two elements (with examples from the specs):
Formats:
N-Quads is a general-purpose assertion language; applications may evaluate given data to infer more assertions or to dereference IRIs, invoking the security considerations of the scheme for that IRI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP IRIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended IRIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. N-Quads is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on N-Quads documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. N-Quads can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted N-Quads documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. N-Quads uses IRIs as term identifiers. Applications interpreting data expressed in N-Quads should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNICODE-SECURITY] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
Query language
Exposing RDF data for update creates many security issues which all deployments must be aware of, and consider the risks involved. This submission discusses some of the potential issues. New security problems are discovered regularly, and each implementation introduces its own concerns. Consequently implementers should be aware that this is only a partial list containing possible issues, and cannot be considered complete nor authoritative.
Write access to data makes it inherently vulnerable to malicious access. Standard access and authentication techniques should be used in any networked environment. In particular, HTTPS should be used, especially when implementing the SPARQL HTTP-based protocols. (i.e., encryption with challenge/response based password presentation, encrypted session tokens, etc). Some of the weak points addressed by HTTPS are: authentication, active session integrity between client and server, preventing replays, preventing continuation of defunct sessions. SPARQL Update incurs all of the security concerns of SPARQL Query. In particular, stores which treat IRIs as dereferenceable need to protect against dereferenced IRIs from being used to invoke cross-site scripting attacks. Implementations will need to enforce their standard permissions scheme carefully. Permissions schemes always require careful design, and it is important to ensure that privileges in one area are not inadvertently applied to other parts of the system. Systems that provide both read-only and writable interfaces can be subject to injection attacks in the read-only interface. In particular, a SPARQL endpoint with a Query service should be careful of injection attacks aimed at interacting with an Update service on the same SPARQL endpoint. Like any client code, interaction between the query service and the update service should ensure correct escaping of strings provided by the user. While SPARQL Update and SPARQL Query are separate languages, some implementations may choose to offer both at the same SPARQL endpoint. In this case, it is important to consider that an Update operation may be obscured to masquerade as a query. For instance, a string of unicode escapes in a PREFIX clause could be used to hide an Update Operation. Therefore, simple syntactic tests are inadequate to determine if a string describes a query or an update.
Thinking about specific Threats:
For Formats: Encoding errors, although there may be problems related to serialization/unserialization of the graphs, similar to what happens with the XML Signature Wrapping.
And assumptions:
I also did a search on arxiv there are no papers describing additional vulnerabilities. On SPARQL Injection a presentation from several years ago (in Italian).
If we think it can be useful to create a summary of potential threats, There are no further notes at present.
plehegar
commented
4 months ago No comments from PING
pchampin
commented
4 months ago @simoneonofri, thanks for the review. This will be valuable input for the specs, but I don't think it calls for any change on the charter itself. Would you agree?
simoneonofri
commented
4 months ago You're welcome, @pchampin; on a practical level, if the specs are updated, we can make a summary section.
plehegar
commented
3 months ago Various editorial updates in https://github.com/w3c/rdf-star-wg-charter/pull/60
plehegar
commented
2 months ago pchampin
commented
1 month ago The vote is now closed, with a fair level of support for the new charter, and no formal objection.
Some changes on the text were suggested.
pchampin
commented
3 weeks ago Some changes on the text were suggested.
pchampin
commented
3 weeks ago Some changes on the text were suggested.
plehegar
commented
1 week ago Proposed changes following AC review are under review until November 20.
New charter proposal, reviewers please take note.
Charter Review
Charter: https://w3c.github.io/rdf-star-wg-charter/
diff from previous charter
The group is chartered until August 2024, and is behind schedule on its deliverables. The group believes that it needs one more year to complete its work, so a regular charter extension (limited to 6 months) is not appropriate. Furthermore, the group would like to continue in maintenance mode once the deliverables are published (the published recommendations will allow new features).
Except for the new schedule, and the transition to maintenance mode, the new charter does not contain any substansive change compared to the previous one, so we don't expect any major issue with horizontal reviews.