search

w3c / vc-wg-charter

Developing a new charter for the VC WG.
https://w3c.github.io/vc-wg-charter/
Other
3 stars 12 forks source link

Refactor WG inputs and outputs to follow (approved) WebApps Charter style #77

Closed msporny closed 2 years ago

msporny commented 2 years ago

This PR builds on PR #76, #73, #66, #63, #51, and #50 and refactors them in a way that other WGs have found success wrt. charter approval. It also addresses @Sakurann's request to categorize the layering, and @selfissued's request to put the JWP work back in scope (if adequate progress has been made at IETF).

Preview | Diff

iherman commented 2 years ago

I am bit bothered by the new title for 2.2. It could be read as if this WG developed CCG or IETF. recommandations...

msporny commented 2 years ago

I am bit bothered by the new title for 2.2. It could be read as if this WG developed CCG or IETF. recommandations...

It's the same language that the WebApps group uses. I don't have a strong opinion and was just trying to follow WebApps model as @kdenhartog had requested. I'll try to think of alternate wording that will make it clear that those are potential future inputs from CCG and IETF that may become W3C Recommendations.

kdenhartog commented 2 years ago

Agree with moving to this structure and will put forth ~some modifications~ a follow on PR for additional recommendation track documents that I think would fit in here as well.

msporny commented 2 years ago

@kdenhartog wrote:

Agree with moving to this structure and will put forth some modifications for additional recommendation track documents that I think would fit in here as well.

I thought about doing that in this PR as well, but then was concerned that people might use that as a reason to object to this PR. I'd rather do another round in a PR that builds on top of this one. For example, VPR and VC API should probably be in that list of "things we might want to move to REC if CCG finishes with it"... but then I was concerned that people would object to the PR on those grounds... so I tried to only cover things that people already have in as PRs... and then try to see how far we can take this new structure in a future PR (if/once this one is merged).

kdenhartog commented 2 years ago

move to REC if CCG finishes with it"... but then I was concerned that people would object to the PR on those grounds... so I tried to only cover things that people already have in as PRs... and then try to see how far we can take this new structure in a future PR (if/once this one is merged).

Yup that's what I figured as well so waas going to do in a separate PR that builds on this instead. A small focused PR should be able to get us to hone in on this a bit better

iherman commented 2 years ago

The issue was discussed in a meeting on 2022-02-23

View the transcript #### 4.6. Refactor WG inputs and outputs to follow (approved) WebApps Charter style (pr vc-wg-charter#77) _See github pull request [vc-wg-charter#77](https://github.com/w3c/vc-wg-charter/pull/77)._ **Brent Zundel:** normally we would move to the next topic, but we are actually merging PRs. **Manu Sporny:** let me explain where this PR is coming from. … we have struggled to classify documents correctly. … the purpose of this PR is to align our documents with the WebAppSec WG's approach. … in their normative spec list, they very clearly state their deliverables. … they also have a section for WICG, which generates input documents for the WG. … this section of the WebAppSec charter which has been approved, says: "we may deliver these things, as long as the prerequisites have been met".. … our charter lists 2 items we intent to deliver. … last week, kyle suggested we also use conditional normative specifications.. … VC-JWP is a normative deliverable if IETF is done before we go to REC, same thing is true of BBS+. … PGP, which orie asked for, if the CCG or some other incubation group finishes this in time, then it can become a normative deliverable of this group. … the intent is to message these documents in the way that we have seen the WebAppSec WG be approved. **Kristina Yasuda:** I understand the logic. … deliverables that are conditional make sens. … can you clarify the 3 listed deliverables. … I don't understand how these fit together. **Manu Sporny:** excellent questions..... … typically the way W3C WG behaves, the WG decides how to publish specs (1 document or many). … what we list in our charter does not need to map 1-1, other than if we say we will publish something as a REC it has to be a REC. … to be clear, this list might not be complete yet. … this is just a preliminary PR that addressed what we already have. … VC-JWP, currently the data model spec requires us to normatively define the mapping for VC-JWT... if JWP is done at IETF, we will need to do the same thing for JWP. … all the core crypto work would need to be done at IETF before that can happen. … this is the exact same model we followed for VC-JWT. … we point to IETF RFCs for JWT. … regarding crypto suites.... … when this WG defines a crypto suite, those suites don't invent new crypto... we are just pointing to IETF crypto. … what we are planning on doing is discussing packaging formats.... … the suites, may be their own individual specs, or we may want to bundle them. … re your question on what is an "input document".. … yes, we intent to take over the data integrity spec. … the W3C process is that a WG takes CG drafts, and says they intend to standardize. … the VC2.0 WG will list the data integrity report the CCG has been working on, and then it becomes a WG doc. … we take it over, input documents usually have clean IPR, that are taken in to be worked on by a WG. **Oliver Terbu:** can we say its not the intention of the group to produce an exhaustive list?. **Brent Zundel:** we are intending for it to be non exhaustive list of input documents. … the charter does not say this list is final. **Oliver Terbu:** is it the intention of the final specification to be an exhaustive list?. > *Manu Sporny:* Oliver, yes, that should still be possible. > *Manu Sporny:* We will have failed if we don't allow that.. **Oliver Terbu:** in other words, can we keep using other suites that are not listed. **Brent Zundel:** the charter does not disallow that. > *Oliver Terbu:* ok, thanks. > *Manu Sporny:* agree with Kristina, having an exhaustive list of CCG input documents would be useful.. **Kristina Yasuda:** confused regarding CG Drafts and their ability to seek standards track. **Ted Thibodeau Jr.:** CGs produce reports... those reports look like specs, but they are not, thats why they take them to WGs. … a CG has no power over a WG. … CG's that submit final reports can ask for a WG to adopt a report as an input document, but the WG is not required to take on ANY work from a CG. > *Kristina Yasuda:* Thank you for clarifying, Manu, Ted!.
msporny commented 2 years ago

This PR has been rebased on top of all of the merges we did this week during the WG call. It's ready to be merged during the call next week if we have no objections.

brentzundel commented 2 years ago

Both chairs have approved this PR, other changes have been requested and made. Other approvals are in place. Merging in accordance with our working mode. If further changes are desired, please open issues and PRs for them.

msporny commented 2 years ago

Merging

Blerg, looks like this was squash-merged, which makes it difficult to fix the conflicts elsewhere...

When merging, please follow this general practice:

^^^ Those rules are good rules to follow for any Github repository and can be applied to most (if not all) Github repositories.

What happened here was:

  1. This PR was squash merged to main.
  2. Then another PR (msporny-other-deliverables) was multi-headed merged onto this PR (but will never make it down to main since this PR was already merged -- Github should really prevent that from happening, but it doesn't).
  3. Now I'm trying to rebase msporny-other-deliverables on top of main, but since this PR was squash-merged, I have to fix all commits made in this PR by hand (and there were a lot of commits made in this PR). That's going to take 30 minutes out of my day.

Just trying to document what happened so we can avoid it happening in the future. I'm working on it now.