Meeting minutes
markus_sabadello: Calls meeting to order
markus_sabadello: Welcomes everyone in the room and online
agenda review
markus_sabadello: Goes through agenda
markus_sabadello: Welcome to everyone, Monday morning at W3C TPAC
markus_sabadello: First time slot, it's been a great group and interesting useful work that we're doing. I sometimes feel like this is not the most glamourous group compared to DIDs and VCs, but let's not underestimate how important this is. This is not just a prerequisite for VCs, but it's really a mechanism for adding integrity/verifiability to any sort of data on the Web.
markus_sabadello: This is not just a short term prerequisite for VCs, this is a mechanism for a more trusted Web wrt. verifiability -- any sort of data, not a small thing. Thanks to everyone for their contributions so far to get to this point.
markus_sabadello: Any introductions?
Calvin_Cheng: Singapore government technology agency introducing themselves, interested in VCs, observing now.
Calvin: representing Singapore Govt
Doerthe Arndt: Hello Doerthe Ardnt here from RDF Star WG, interested in the work here.
dezell: Hello David Ezell, from Conexxus representing them and National Association of Convenience Stores and I think we have one of the real ongoing tests of VCs meeting with a good bit of success in retail space, not security expert, not my space, but have followed it avidily since the beginning.
markus_sabadello: Welcome, all the things we do here matter more when they're deployed in production.
phila: I know motiviation for this group comes from VCs, but also when I was on W3C Team, people were talking about canonicalization of RDF since far before VCs, but in RDF community it's been happening for many many years.
iherman: There was an XML Canonicalization WG, but it was a very different thing.
markus_sabadello: This work also comes up in the data spaces community.
Explainer Document
phila: The reason for putting this on the agenda, this is something that was Amy Guy and Hadley Beeman reviewing main document for the TAG highlighted the explainer document and thought things should go into explainer document that isn't. I had to update explainer document
phila: Needed to turn it into mini document and get it into group. Amy noted a few things that should be in the explainer that is not. Ted did a good pass on the document/text. There are four PRs that are pretty straightforward... looking for, maybe Gregg, if those PRs went in do we think it answers Amy's questions. Does explainer document answer what Amy is asking?
phila: On the TAG review -- triples and adding graph name once, this is the sort of thing we expect to see in an explainer. Gregg put some notes in -- does this address this?
gkellogg: I think I answered Amy in that TAG issue and you asked me to do updates to text and I needed to clarify that PR 5 is an update to your PR rather than base document.
<markus_sabadello> w3c/
<markus_sabadello> w3c/
gkellogg: It touched some non-overlapping areas, didn't make sense to update 4 -- in essence, the combination of those two answers what Amy was asking for. I think we need to get them merged together to verify for ourselves.
https://
phila: Ok, I'll get that reviewed and merged.
phila: Main thing it does is change language on charter/work -- thanks to Ted and Gregg to working on that. Turned it into a NOTE. A lot of the content is exactly as it was... explains problem space, use cases, etc.
phila: we spent a long time thinking about what output is going to be -- detail is in spec, not in this document.
phila: Doesn't change much, use cases not changed, that's the document as it is. Given how recently it's been done, we can't consider publishing as a NOTE immediately, will try to get PRs sorted out, by end of meeting it'll be there, Amy and TAG will be provided the document.
markus_sabadello: Should we tell TAG about this sooner than later?
phila: Yes, as soon as I merge the changes down.
markus_sabadello: Ok, next steps are to merge this and inform tag and us review the document.
manu: there is overlap with RDF-star; RDF Surfaces were also brought forward in the VC group.
… I don't know where this item fits in the agenda, but we may want to discuss this.
… If only to state in the explainer "this is was not in our charter, we are not supporting it (yet)".
<Zakim> gkellogg, you wanted to note potential use of base direction
gkellogg: To follow up on what Manu was saying wrt. potential futures -- one of the things in RDF 1.2 is support for base direction of literals -- as much as VCs are based on JSON-LD and as much as JSON-LD supports base direction... RDF interpretation is non-normative... that's something we should consider, base direction property -- make sure to clarify how that is serialized to RDF so it's done consistently
manu: this has come up recently in the i18n review of VC
… Suggestion of the group is to support language and base direction in VCs, but I don't remember how we decided to encode it.
… The VC spec will need to pick one of the two options in JSON-LD to serialize base direction, so that everyone serialize it the same way.
phila: I thought we had covered that already? Didn't we talk about literals?
manu: this issue is specifically about base direction
gkellogg: in JSON-LD, one option to encode base direction is the i18n family of datatypes.
… This was required to fit into the RDF 1.1 model. RDF 1.2 will support base direction natively.
ivan: This is not this groups problem, we should not diverted, this is an issue of the canonical quad serialization which his group does not define. For quads, that is done in another group -- in explainer, we depend on canonicalization of NQuads and RDF 1.2 finalizes it's work on canonical NQuads, our algorithm automatically works.
<gkellogg> +1 for keeping concerns separate
ivan: I don't want to minimize the importance of the problem, but this is not for this WG. We should clearly separate these concerns... what happens in VC is how we serialize things in JSON-LD, irrelevant for this WG.
markus_sabadello: Is this related to wha we said about canonical form of N-Quads?
gkellogg: This is taken from RDF 1.2 version in NQuads/Triples -- v1.1 doesn't have such a section, still has some ambiguities... group decided to adopt the language from RDF 1.2 and been going back/forth a bit -- in terms of language, this supports NQuads/Datatypes... one area we've discussed, BCP 47 expression in RDF. Commonly BCP 47 is case insensitive, there are preferences for how its encoded... allows lowercase normalization, what if
triples/quads differ in case used? Express the same value, might not be considered the same term, added language in c14n to strongly encourage implementers to use lowercase version of language tags so we don't run into these problems.
gkellogg: This appendix says how we serialize the result, language tags in algorithm, serialize something in different form... this is something that I don't think RDF 1.2 is done w/ either. Not something we can depend upon in this group.
markus_sabadello: The conclusion is that we don't have to do anything.
gkellogg: I think we've already addressed this.
markus_sabadello: Maybe explainer document can cover this.
gkellogg: datatype IRIs are not transformed, maybe language tags should be normalized, datatype IRIs are not and i18n does not and namespace depends on those IRIs.
phila: I've heard from Amy, Amy will be here after the break.
ivan: There is one thing not on the agenda, put in an issue that may lead to normative changes in document, nothing big/problematic -- we might use the time to look at the issue.
markus_sabadello: Issue #169? Sounds good to me.
<markus_sabadello> w3c/
w3c/rdf-canon#169
ivan: There have been negative remarks from some in the VCWG about us using SHA-256, some think it's not good enough and so entire algorithm is not ok -- text in spec has a few places says that implementations can allow changing hash function to something else... one remark in terminology section and that's it.
ivan: In parallel, important to be able to change hash functions, two additional tests to test suite, which includes requirement to change hash to SHA-384. That is part of official test suite, we already have 3 implementations that implement that. We should be stronger in the test and we should make it a SHOULD statement, wouldn't be shocked if we say it MUST -- user of algorithm SHOULD/MUST be able to change hash function to SHA-384, or if SHA-384 is
enough to cover things
<markus_sabadello> Related: https://
ivan: We should make language stronger, leave how to the editors, we should discuss the principle first.
markus_sabadello: The TAG review also covers this.
phila: I think we covered this, closed issue 160...
manu: we definitely discuss this. To be sure that everyone is on the same page:
… the hashing function we are talking about here is the *internal* hashing function that we use in the algorithm.
… We are *not* talking about the hashing function used on the output of the canonicalization algorithm.
… some national governments is considering moving from SHA-2 to SHA-3. We must be open to this kind of change.
ivan: To be precise, text in issue -- two things 1) algorithm must allow caller to change hash function, 2) if this is done, SHA-384 should be supported.
gkellogg: In the definition of the hash algorithm... default is SHA-256, implementations can be written to parameterize -- I agree that statement should be made stronger... implementations MUST allow algorithm to be specified, whether we get into enumerating other acceptable algorithms, that's shortsighted, as soon as we do 384, then we move to sha-3, or something completely different... takes input, generates an output... test was added to test suite
to show that if different hash function is used, you get different results.
+1 to not enumerating hash algorithms, other than the default. Leave it open to future changes.
gkellogg: Example specified, SHA-384 specifically, SHA-3, probably want to make that informative.
<Zakim> manu, you wanted to agree with gregg
manu: +1 to what gkellogg said. They are many hash functions.
… I'm on the fence on saying MUST for sha-256 and SHOULD for sha-384, and not go beyond that. Different organizations have different requirements.
… Leaving it open is more future-proof.
ivan: I think we have an agreement that language should be more firm -- on that, we can move on.
ivan: Whether spec refers to SHA-3 or SHA-384, only problem w/ not doing that, how do we test if we don't have a reference... current test has built in SHA-384, thorough test suite, at minimum SHA-384 -- language into issue reflects that... if we leave it open, nothing else in spec, how do we write a test to test that w/o specifying specific hash functions. How do we test this, that's the problem?
ivan: Implementations should implement SHA-256 or SHA-384.
gkellogg: One of the other things that we discussed, and provision for in the spec, other specs could be derived from this could specify hash function, would support our strength of language to support at least SHA-256 SHA-384 without enumerating others... we're getting into actual/future hash algorithm probably right way to do that is create a new spec that highlights that new item
<Zakim> manu, you wanted to note a spec that only defines hash function is a bit heavyweight?
manu: we don't want to later define a new spec that would only change the hash function
draft proposal: The spec text be amended to say implementations MUST support SHA-256, SHOULD also support SHA-384 and invite use of other hash functions in future.
manu: other specs should be able to say: "use rdf-canon with the hash function XYZ"
gkellogg: Perhaps a registry, naming schemes... rdfc-1.0-sha256 or similar things that would allow it to be more explicit, but to your point, we do not need an entire spec to replace the hash function -- too heavyweight -- but doing it in another algorithm that specifies that is ok.
gkellogg: As an implementer, I have libraries that have hash functions available to them, but can't necessarily do that if a call is made.
ivan: Let's not overcomplicate things, what phil put in as a draft proposal covers the situation we have today.
ivan: Let's run the proposal Phil suggested.
<TallTed> s/HSA-256/SHA-256
Proposal: The spec text be amended to say implementations MUST support SHA-256, SHOULD also support SHA-384 and invite use of other hash functions in future.
<gkellogg> +1
manu: +1
<TallTed> +1
<markus_sabadello> +1
<jyrossi> +1
<pchampin> +1
markus_sabadello: This implies that it must be able to be parameterized in the first place -- MUST be able to parameterized.
gkellogg: can we say MUST support SHA-256 and SHA-384
phila: What about MUST support other hash functions?
gkellogg: Text says you MUST be able to specify parameters.
phila: Let's try to get this written down in a proposal.
Draft: Implementations MUST support parameter to define hash function. They MUST support SHA-256 and SHA-384, and SHOULD be able to support further options
<gkellogg> "Implementations must allow the hash algorithm to be specified by parameter without any other changes."
PROPOSED: Implementations MUST support parameter to define hash function. They MUST support SHA-256 and SHA-384, and SHOULD be able to support further options
<gkellogg> +1
<ivan> +1
manu: +1
<pchampin> +1
<markus_sabadello> +1
+1
<yamdan> +1
<TallTed> +1
RESOLUTION: Implementations MUST support parameter to define hash function. They MUST support SHA-256 and SHA-384, and SHOULD be able to support further options
phila: This is a small change, but normative, conscious that we have a TAG review -- does this hold us up? Any resolution to go to CR will include things discussed today.
<markus_sabadello> w3c/
w3c/rdf-canon#167
gkellogg: This is a bit of a back and forth w/ PFPS.
phila: This sounds like this is a known problem, but not our problem to fix... been this way for 20 years. There isn't any controversy about this PR?
phila: Yes, sounds like we can go ahead
gkellogg: Ok, merging it now, then.
w3c/rdf-canon#171
markus_sabadello: This just adds funders, if there are no objections, we can merge.
ivan: We can merge
gkellogg: I'll merge now.
gkellogg: We just need a PR for the resolution we have and we're done.
manu: This covers all of the issues that PFPS raised?
gkellogg: Yes, seems like it does.
gkellogg: We might want to clean up issue markers in the spec -- should we leave issue marker in the spec.
ivan: We should remove it from the text
gkellogg: Issue for 98 should be removed -- as part of update for specification, issue markers for closed issues shouldn't stay in the document.
gkellogg: Privacy considerations, might reveal information... we do have issue markers in it... we have asked for review... we have text.
manu: does our section about Security and Privacy mention selective disclosure? It should.
… [after looking at it] Yes it does.
ivan: The reference should include a link to the Data Integrity specification.
manu: Yes, looks like this text covers that issue.
phila: Is the Data Integrity spec in TR?
manu: Yes, it is.
markus_sabadello: It sounds like we should be able to close issue #70.
<ivan> Is this the reference to be used on selective disclosure? https://
Need to add reference to [vc-data-integrity] from Section 6
phila: For privacy considerations section -- can we add a reference?
gkellogg: I can add a separate PR
gkellogg: We have use cases section w/ issue marker.
phila: That should point to the explainer document.
markus_sabadello: There is also some text about Editors notes about c14n details.
markus_sabadello: So, close issue #70?
markus_sabadello: Ok, five minutes to coffee break -- think we did all issues and PRs.
Process Briefing
pchampin: The only thing that is keeping us from going to CR is TAG review...
ivan: and then we have to do transition request... then approval, if we had documents, then has to be published on TR manually, automatic publishing needs to be switched off for a while -- done in old school way.
ivan: As part of CR transition, what's the earliest date to move to PR -- has to be part of transition request, limit for that, at least 28 days.
phila: The aim today is not to get into CR, we need to go through process -- if group agrees we're ready, have we got everything ready to go through that process.
phila: After coffee, we'll run the request to transition.
[Coffee break]
markus_sabadello: Thanks everyone, we have a half hour break now.
phila: Michiel can you say hello
Michiel de Jong: I followed manu's work
Jean-Yves Rossi: I joined W3C through Web Payments. I'm currently preparing a PhD about Semantic Web. I have a connection with Pierre-Antoine
phila: We appreciate Amy being here
phila: We asked for a TAG review
w3ctag/
phila: We actually went through the Security and Privacy Questionnaire. We answers the questions that apply to us.
phila: We also answered questions about the explainer document.
phila: The use cases document has been updated.
phila: I hope we answered your questions.
rhiaro: We don't have any further worries.
phila: Can you give us an estimation
rhiaro: I need to sync up with Hadley, but it should happen soon
phila: This morning, we looked at explainer, talked about process.
phila: We should now look at test suites, and talk about CR exit criteria
Test suites: https://
ivan: From my experience, the test suite is fine. There may even be some tests that should not be there, e.g. ones about NQuad serialization rather than Canonicalization
ivan: The test harness works
ivan: There are several implementations that went through the test suite
<gkellogg> https://
gkellogg: Tests are good, but I think we need to approve them.
phila: Do we need to review before we approve them?
ivan: I don't think so
ivan: For CR transition, we only need to say that we have a way to test. And we do have that.
ivan: I think we are fine for CR transition
phila: But it feels like a simple step to "approve" them
PROPOSED: Change status of tests documented at https://
<ivan> +1
<gkellogg> https://
<manu> +1
gkellogg: The report shows 4 implementations, one has partial compliance
gkellogg: We're also still expecting more reports
https://
phila: Do we have a sense how complete the implementations are?
phila: Are any of these implementations affected by the resolution we made this morning about alternative hash algorithms?
ivan: No, they all pass this
gkellogg: Some of the tests are against SHA-384
gkellogg: There's a test property to specify the algorithm to use
PROPOSED: Change status of tests documented at https://
<gkellogg> +1
<manu> +1
phila: Let's finish voting on the resolution please
<ivan> +1
+1
+1
<yamdan> +1
<TallTed> +1
RESOLUTION: Change status of tests documented at https://
phila: We can now turn the test status to approved
phila: We have an impressive list of implementations, by different people, in different languages
ivan: manu your group is doing the Python one?
manu: Yes
ivan: We have TypeScript, Ruby, Rust.. We also need Java, Python
ivan: They exist but have not submitted reports
manu: We have Java implementations which are passing VC Data Integrity
ivan: We should have independent reports from Java, Python
ivan: I think all four have regularly contributed to the specification, which is a good thing
phila: We have a test suite, multiple implementations, that's good
phila: Horizontal reviews are okay
w3c/
phila: We have talked about all issues
gkellogg: There are 2 pull requests
phila: Let's look at them
TallTed: I added a suggestion to maintain the readability of the source
gkellogg: Merged
This one addresses the earlier resolution about parameterizing the hashing function
gkellogg: Accepted TallTed 's suggestion
phila: Looks clear
gkellogg: This also removes an issue marker
manu: Minor knit about language.. The last bit that says "SHOULD"..
manu: Maybe this should be changed to "SHOULD support the ABILITY to add other ..."
manu: .. the ABILITY to SPECIFY other hash algorithms
phila: We can go to the issues and point to the PR which takes care of it
gkellogg: When we merge it, the issue will be closed
phila: Three approvals
phila: Let's merge
gkellogg: Done
New text appears in https://
phila: Currently open issues.. We talked about use cases, history, TAG review
phila: We have test suites and implementations
phila: We need to define CR exit criteria
phila: Usually 2 independent implementations of each feature, which we already have
ivan: Since we are talking about a security-relevant spec, we could make 2 changes.
ivan: We should say we have 2 implementations which pass ALL the tests. This is stronger than usual.
ivan: We could potentially say 3 instead of 2.
phila: We're setting the bar higher than what W3C requires, which is a good thing
phila: On Horizontal Review, should we just say they are completed, or should we go into details
phila: The Accessibility group agrees this is not an issue for us
ivan: In the submission request, you don't have to go into details, but you have to give clear pointers to the discussions (Github issues, email, etc.)
phila: We have acted on them
manu: There's a template for the transition request, which makes it easier
phila: Here's the document we're suggesting is ready for CR: https://
phila: Should we mention implementations in the document?
gkellogg: We can reference the test report
phila: The test suite is referenced
phila: All issue markers gone?
gkellogg: There is still an issue marker for use cases.
phila: We know this is editorial, not normative
phila: I'm planning a PR for that
This is the use cases issue: w3c/
phila: Then I think we're ready for the resolution
phila: Unless anyone says otherwise?
phila: This is the document we want to send to CR: https://
ivan: It's totally fine to reference the Editor's draft
Editor's draft: https://
manu: Do we need to include minimal review time
ivan: yes
Draft PROPOSED: The Working Group asks the chairs to seek transition of the editors' draft of the RDF Canonicalization spec to CR with a 28 day review period.
Draft PROPOSED: The Working Group asks the chairs to seek transition of the editors' draft of the RDF Dataset Canonicalization spec, https://
Draft PROPOSED: The Working Group asks the chairs to seek transition of the editors' draft of the RDF Dataset Canonicalization spec, https://
manu: Do we need to include exit criteria?
phila: Let's do that
PROPOSED: The WG recommends the CR exit criteria be: 1. Three independent implementations of all features, 2. Two independent implementations that each pass all tests
<ivan> +1
+1
<gkellogg> +1
<manu> +1
<yamdan> +1
<TallTed> +1
+1
RESOLUTION: The WG recommends the CR exit criteria be: 1. Three independent implementations of all features, 2. Two independent implementations that each pass all tests
PROPOSED: The WG recommends the CR exit criteria be: 1. Three independent implementations of all features, 2. Two independent implementations that each pass all tests
manu: Do we have to say a publication date?
PROPOSED: The Working Group asks the chairs to seek transition of the editors' draft of the RDF Dataset Canonicalization spec, https://
ivan: No we don't know that
<ivan> +1
<manu> +1
<TallTed> +1
<yamdan> +1
<gkellogg> +1
+1
+1
RESOLUTION: The Working Group asks the chairs to seek transition of the editors' draft of the RDF Dataset Canonicalization spec, https://
phila: Big thanks to gkellogg for all his work!
ivan: When is the end of the charter?
manu: Next June or July
ivan: Next goal is to have Rec at the end of the year? Or early January?
phila: We could be in PR in November?
ivan: Then there is a the voting period
ivan: End of January maybe
phila: We have half an hour left
phila: This afternoon we have meetings with other groups.
phila: Anything this group should think about?
manu: We could go over their agenda
phila: One agenda item will be Signing and Canonicalization (30 min)
manu: Topics also include restricting prefixes for JSON parsers, and supporting JSON-LD without full JSON-LD processing..
manu: There is a way of operating where you can presume that all LD processing has happened, without doing any of it.
ivan: From RCH point of view, we're done
phila: Is there anything we need to prepare for the afternoon
manu: Probably not
manu: A lot of it seems higher-level JSON-LD related
phila: So that's a discussion for the afternoon, nothing really that we need to prepare
Possibilities for future exploitation, development, promotion
phila: W3C doesn't do marketing, should we?
ivan: After PR, I would love to explore on how we handle RDF-star, RDF 1.2
ivan: We don't have to deliver anything, but having a WG Note how this algorithm could be extended would be interesting
<dezell> Side note - WoT has had a marketing task force that meets every week (not sure about now).
ivan: I could imagine thinking about a new version of this WG that would go on and make a next version to align with RDF
ivan: We are chartered until July. We could end our work, but could also use the time to brainstorm about the next version.
phila: It would be interesting to do, but who would be asking for this?
ivan: If we imagine the RDF community beyond VC to use this, then that's the answer
ivan: Some people in VC working group have been talking about property graphs.
ivan: If that is taken seriously in VCs, then there has to be an answer from RCH
ivan: Without any commitment, but we can brainstorm and write down ideas
<Zakim> manu, you wanted to "look beyond VCs"
manu: Yes we should look at property graphs, but it's far off
ivan: It's not that far off
gkellogg: There are 20 documents we're working on, still determining what exactly the semantics are
gkellogg: Hopefully get some clarity about this tomorrow
gkellogg: Maybe CR in the first part of next year
gkellogg: How we handle the triples and support property graphs, there is an "unstar" operation
ivan: Let's not start the discussion right now
gkellogg: We may not have to actually do much to support this
ivan: So 1.2 is not that far away
ivan: That means maybe in early 2025 1.2 may be out
<Zakim> manu, you wanted to note "computational usage" criticisms.
manu: Amy and Hadley brought up in TAG review on VCs.. Do we want to pull Data Integrity out of VC and have it deal with RDF in general?
manu: Do we want it to be less attached to VC work as it is today.
manu: When we started this, there were objections about the work being too broad. Therefore we are now more focused on VCs.
manu: I am wondering if there could be a separate group
manu: Going back to marketing, well right now there is negative marketing against RCH.. E.g. saying it is too computationally expensive.
manu: There are questionable arguments
manu: I wonder if we maybe need to have responses where we show people
manu: I wonder if it would be useful to show how much time you spend on canonicalization
manu: Should we have rebuttals to the criticism
manu: The other thing is you can construct attacks. We have dealt with this in the specification.
ivan: I wouldn't really know how to start that.
ivan: If we look at the first phase of the algorithm, my feeling is it covers 80% of practical situations. The other 20% deal with theoretical situations.
ivan: The question is also how expensive is hashing
ivan: Most of the operational cost is hash, and managing RDF graphs. This is not something about the algorithm, but about the underlying RDF environment
ivan: This topic is much lower. This doesn't have any end, you can't do it like that
phila: I think a period of time has to go by
phila: I know you're getting criticism right now. After Rec, this may go away.
phila: Anyone has anything else to say to the group?
phila: Thank you all, thanks Amy, thanks to the scribes.