– DRAFT –
RCH bi-weekly - first time for 3 months!

phila: The first thing to cover.

Jennie: Hi Jennie Meier, from Digital Contract Design, working on Decentralized Identifiers and other items at W3C.

phila: Welcome to the group!

<phila> w3c/rdf-canon#190

<gb> Issue 190 media type of canonicalized `application/n-quads` (by gobengo) [wr:open]

phila: The main topic is to seek exit from CR; that's what I hope we'll get to -- a few issues that we need to look at and clean up.

w3c/rdf-canon#190

phila: Do people know Bengo?

manu: yes, we do.

phila: What's the status? Should we register a media type for canonicalized quads? Any strong views in favor or against?

manu: Against at this point primarily because it's a bit of a pain to do it and we should have talked about it at a decent amount of length before doing.

manu: I'm hesitant to do it right at the end of CR as we transition to PR -- we should have done it before CR and had some implementation feedback. It's not a big deal, we can always do it later.

manu: I don't know that there's a strong need for this.

phila: Anyone else with a view?

<ivan> +1 to manu

seabass: The thing that comes to mind, when you're returning C14N N-Quads, you're doing it for security, not sure it helps to trust client for that... while someone thinks there is a use case, can't understand what that could be quite yet.

ivan: I'm not a security expert, but as a layperson in that area, I'd be concerned to handle canonical n-quads, I would have to re-canonicalize if I care about security. I also agree with manu's arguments.

markus_sabadello: I agree with what others have said, in most cases it's C14N is part of something else, part of an intermediate step, not a lot of use cases where you need to store/transfer this data.

gkellogg: The original media type needs to have provisions to be extended, in this case, I don't think there's such a provision.

phila: Aren't we not extending N-Quads?

gkellogg: If there can be an extension, the media type needs to provide for that.

manu: I don't know for sure what n-quads allows as extensions. But what Gregg said I believe is correct, we should check to see if n-quads allows a profile parameter. We just need to look up in the IANA registry or read the spec. If it allows profiles or something. If it doesn't, the proposal just won't work.

<ivan> nquads specification is here

<gkellogg> https://www.iana.org/assignments/media-types/application/n-quads

manu: We'd have to register an entirely new media type, which again we haven't contemplated in this group.

manu: I agree with Sebastian and Ivan and the others, you can't trust someone giving you canonical form, at least for security purposes, you have to canonicalize yourself.

manu: I'm struggling to understand the use case like Sebastian is.

phila: My own view aligns w/ everyone else here... c14n is idempotent, whether something says it's c14n'd or not doesn't matter, you need to ignore it and re-c14n to be sure.

manu: I just went and checked the n-quads spec.

Checking the spec, https://www.w3.org/TR/n-quads/#sec-mediaReg, yes Gregg is correct -- there are no required/optional parameters for n-quads, we can't use profile, we'd have to register a new media type.

manu: So if we wanted to do this, we'd have to create a new media type and we do not.

<phila> Proposed resolution: We thank Ben for the comment but feel that C14N would always be re-executed before trusting that the data was canonicalized and don't see the value in adding a new media type, especially this late in the standardization process. Also, no scope for extensions in the existing n-quad media type registration

manu: +1

<phila> +1

dlongley: +1

<ivan> +1

<yamdan> +1

<gkellogg> +1

<dlehn> +1

<seabass> +1

<Jennie> +1

RESOLUTION: We thank Ben for the comment but feel that C14N would always be re-executed before trusting that the data was canonicalized and don't see the value in adding a new media type, especially this late in the standardization process. Also, no scope for extensions in the existing n-quad media type registration

<phila> Issue 19 w3c/rdf-canon#19

<gb> Issue 19 Add history of the development of the c14n work (by philarcher) [documentation] [spec:editorial]

w3c/rdf-canon#19

manu: I know I've said this before, I will put this on my work queue for this weekend. If someone else wants to do this instead of me, as I have repeatedly failed, I would be happy.

manu: I apologize for not having addressed this yet.

manu: I will do it this week unless someone else beats me to it.

phila: Ok, looking forward to seeing a PR for that.

CR exit discussion

phila: We have met our CR exit criteria, but we wanted to see if we could go further and not just meet letter but spirit of it... waited 3 months to see how things went.

phila: Question to the group, has there been extra implementation experience that is relevant to C14N, know there is a lot about Integrity Proofs, are there new implementations or other interest that we can bring to discussion to transition to PR.

manu: The last time we had this discussion, I requested that the group hold off; we were hoping to get some review from IETF/CFRG, we still haven't requested that review because the test suites for the data integrity work in VCWG aren't completely done. However, there have been other implementations of data integrity in the meantime, and they are also using RDF-CANON.

manu: I think we've waited long enough, so we can probably transition to PR.

manu: The nightmare scenario is some flaw being discovered in the future; is it possible to go to REC but recharter this group or another to be able to "fix critical bugs".

manu: Can we put this spec into a maintenance group so that we can react quickly? At that point, it's pretty safe to move this to REC.

manu: We should only come back if we find a critical flaw, which we're not expecting of course.

manu: Ivan is saying it's possible.

manu: I would be supportive of us transitioning to PR and then to REC. So this month/next month.

ivan: I will never say it's easy :) -- but it is possible. Actually, regardless of the question, this is an issue we have to settle before we go to PR, in the PR request and in the document, we have to state whether we accept/ready for class 4 changes in the future. We have to find the right terminology -- that has to be decided by us anyway.

ivan: The other thing we should be ready to answer is what our plans are after we finish. My proposal, but not staff contact, we will set up a maintenance WG that has a right to do these sorts of changes if the problem Manu describes surfaces. The answer is two-fold, yes, we need to put it into document and yes we have to put together charter for maintenance WG that can react to any critical issues.

phila: Thank you Ivan, wasn't aware of that process, will open an issue for this...

ivan: We have to decide this today if we go to PR.

phila: Surely that's true for any standard, one of them finds an issue, isn't that always true?

phila: There has to be a process for dealing w/ errata, issues.

gkellogg: There is also the implementation report, which still needs an update from P-A for his implementation.

ivan: He's back now, he has his hands full.

gkellogg: As everyone else that's done it, it's a matter of re-running it and it would be nice to have it show up. Part of the reason for this longer delay was to wait for more implementation reports to come in. I just asked Titanium for an EARL report, asked Andy Seaborne (but he's busy, not going to happen on time).

phila: No more actual submissions, we can ask P-A for his, but not expecting any more implementations at this point in time.

gkellogg: yes, correct. What happens if there are test changes? Maintenance group topic -- new implementations to added since it serves two purposes -- show wide implementation for PR transition, other is a way for people to find resources.

phila: We do want to maintain that list.

manu: I think the thing that's different here -- though it doesn't change what we do -- you could argue that this is a security specification, if this breaks, bad things happen, whereas if the documentation around the blink tag in CSS fails/needs to be removed, it's a minor annoyance.

manu: This is true of security specs in other groups too. There needs to be an expectation that W3C will be willing and ready to spring into action to fix security vulnerabilities.

phila: I'll prepare a proposal that covers these items.

ivan: We will not establish a maintenance group, we will propose a charter to the AC, not exactly right... the WG will propose a charter for a maintenance WG during the PR transition. W3C AC establishes it.

<seabass> +1

manu: I'm concerned about the word "respond", we will not only "respond", we'll fix the security flaws.

manu: We should be explicit that it's part of the job of the maintenance group.

<phila> Proposed resolution: We will propose a charter for a maintenance group that will look after the implementation reports and be ready to fix security flaws that may be discovered. This will be done during the PR period.

<ivan> +1

manu: +1

<phila> +1

<gkellogg> +1

dlongley: +1

<seabass> +1

<Jennie> +1

<dlehn> +1

<yamdan> +1

<phila> Resolved resolution: We will propose a charter for a maintenance group that will look after the implementation reports and be ready to fix security flaws that may be discovered. This will be done during the PR period.

<TallTed> +1

phila: Anything that is going to stop us to seek transition to PR?

<seabass> https://www.w3.org/2023/Process-20231103/#correction-classes

<ivan> -> relevant parts of the process

<ivan> https://www.w3.org/2023/Process-20231103/#revising-rec

manu: We also want to accept class 4 changes during the maintenance group -- that goes in the charter.

manu: I was uneasy about class 3 vs. class 4.

manu: I think we're safer with saying class 4. Class 3 is "make changes that affect conformance", but we may need to add a new feature to fix a critical vulnerability so we want to be as broad as we can.

manu: So class 4 is the right class.

<ivan> "Future updates to this Recommendation may incorporate new features."

<seabass> +1 for doing class 4 changes for security problems. We shouldn't limit ourselves in what we can do to resolve a security flaw.

ivan: We want to include that in the SoTD section for PR.

ivan: We can't make changes to Recommendations if we don't include this text in SotD.

phila: That goes in PR?

ivan: PR and REC.

phila: There are two things that need to happen before document is submitted to Director to transition to PR -- we must include that statement, the second one (Manu has to add to the history of the document). Those two things need to be reflected in the proposed resolution.

ivan: Gregg will have to check to make sure this is put in via ReSpec or it's manual.

gkellogg: I'll look into it.

manu: Can we include the statement "...to address security vulnerabilities"?

ivan: Respec might not let us, it's the standard text.

ivan: What's there is the standard text.

phila: We already said we want a maintenance WG.

ivan: I don't think this has to be listed here -- this WG just makes sure the statement is in the document, then new charter will make it clear when updates are accepted.

phila: Class 4 changes during PR?

ivan: No, AC just needs to vote on what we put in front of it.

gkellogg: ReSpec does not automatically add such a statement to SotD, might be some config parameters to check here.

<phila> Proposed resolution: The document at https://w3c.github.io/rdf-canon/spec/ is ready to use as the basis to seek Proposed Recommendation with two provisos: First the addition of the statement that "Future updates to this Recommendation may incorporate new features." Second, we hope to add a short section listing the history of this work. We expect a future maintenance WG to accept class 4 changes, especially any that are needed to fix any security

<phila> vulnerabilities that may be discovered.

<ivan> +1

<gkellogg> +1

manu: +1

<seabass> +1

dlongley: +1

<phila> +1

<yamdan> +1

<TallTed> +1

<markus_sabadello> +1

RESOLUTION: The document at https://w3c.github.io/rdf-canon/spec/ is ready to use as the basis to seek Proposed Recommendation with two provisos: First the addition of the statement that "Future updates to this Recommendation may incorporate new features." Second, we hope to add a short section listing the history of this work. We expect a future maintenance WG to accept class 4 changes, especially any that are needed to fix any security

<phila> vulnerabilities that may be discovered.

<dlehn> +1

<Zakim> seabass, you wanted to discuss a short announcement in AOB :)

ivan: Who will take care of what?

phila: Markus and I will get on the phone w/ P-A and get this done.

ivan: ok

Any Other Business

seabass: FOSDEM talk about RDF Canonicalization that I presented in Brussels was a great success, turnout of 200 people! Video has just been updated.

<seabass> https://fosdem.org/2024/schedule/event/fosdem-2024-2719-rdf-dataset-canonicalization-scalable-security-for-linked-data/

phila: great work sebastian! That's a lot of coverage -- 200 people... hopefully some will implement and do more security reviews.

phila: I'm not expecting any more meetings like this unless prompted during the PR period. For the time being, assume slot is free in your calendar, but we might have to reconvene. Unless something goes wrong, we're done!

dlongley: well done everyone!

manu: I wanted to extend a heartfelt thank you to Phil, Gregg, Ivan, the Daves.

<seabass> hear hear

manu: Thank you all for working on this and to everyone else here as well, Dan, Kazue, Sebastian, Ted -- fantastic to be done working on this after more than a decade.

<ivan> clap clap

<yamdan> great

phila: We're not completely done, but are most of the way through, thank you all very much!