- From: W3C CCG Chairs <w3c.ccg@gmail.com>
- Date: Wed, 18 Aug 2021 07:20:09 -0700 (PDT)
Thanks to Mike Prorock for scribing this week! The minutes for this week's Verifiable Credentials HTTP API telecon are now available: https://w3c-ccg.github.io/meetings/2021-08-17-vchttpapi Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Verifiable Credentials HTTP API Telecon Minutes for 2021-08-17 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0220.html Topics: 1. Introductions and re-introductions 2. VC HTTP API Renaming Poll Reminder 3. Simple Majority Objection w/ GNAP-KBAT Organizer: Manu Sporny Scribe: Mike Prorock Present: Manu Sporny, Mike Prorock, Bob Wyman, Mahmoud Alkhraishi, Dmitri Zagidulin, Joe Andrieu, David Chadwick, Ted Thibodeau, Orie Steele, Butch, Juan Caballero, Stuart Freeman, Justin Richer, Mike Varley, Kaliya Young, Brian Sletten, Adrian Gropper, Michael Herman, Marty Reed, Charles E. Lehner, Ted O'Connor Audio: https://w3c-ccg.github.io/meetings/2021-08-17/audio.ogg Mike Prorock is scribing. Topic: Introductions and re-introductions Reminder on renaming call Manu Sporny: Note that main topic will be: Simple Majority Objection w/ GNAP-KBAT ... call for any other topics ... noting that we are a friendly group and welcome new contributors ... reminder on q+ to get on queue ... code of conduct from w3c: be kind - let's work to a common goal Topic: VC HTTP API Renaming Poll Reminder <manu> This is the current renaming poll reminder: https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0124.html ... will disucss results once poll close ... please vote if you have note done so already ... concerns over simple majority raised as a strong objection Topic: Simple Majority Objection w/ GNAP-KBAT <manu> This is the objection -- https://github.com/w3c-ccg/vc-http-api/pull/224/files#r682106281 <manu> More background on the decision -- https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0110.html Joe Andrieu: Whether or not consesus is driven by majority vote ... a principled objection is a mechanism to deal with issues where consensus does not emerge ... likely a topic for future discussion with chairs and as a WG and CG level topic Manu Sporny: Noting that w3c process allows for revisting Mike Prorock: One with my Chair hat on, we're aware that there is a gap in some of the work item process documentation, particularly on links out to issue... links out to consensus on W3C Process definitions of consensus. [scribe assist by Manu Sporny] <joe_andrieu> Here's a link to the request to remove the spectext related to the resolution: https://github.com/w3c-ccg/vc-http-api/pull/224/files#r682106281 Mike Prorock: Now with Chair hat off, and with group participant hat on, I'm concerned of the same things as Joe, there is a principled objections, no one is saying GNAP is horrible, but way this was handled has strong concerns. [scribe assist by Manu Sporny] Justin Richer: Agree with process concerns - current state is a bit messy ... should not be able to derail process by one upset individual ... need to ensure that we can converge on a spec ... do want to note that it appears that objection may be using process to overturn a resolution with a non-desireable outcome ... concerned about precedent being set that we use principled objections to derive outcome NB: not a single person objection in this case Joe Andrieu: Noting that this is more than one person, have been that single voice in the past, but do not belive that to be the case here ... our process should be able to prevent a single hold up ... this was a split decision Justin Richer: Issue he is raising is the way the objection was raised Joe Andrieu: Raised PR to note that he did not think that the resolution was in line with CCG process - feels that meeting was structured in a way that allowed unpopular process to pass through to resolution <justin_richer> As stated on a previous call I think the :whole: PR is a bad idea, but I'm not going to try to stop anything on that. :) Adrian Gropper: Wants to state that he views this the way that justin does - one person has to do with process - resolution had some majority Adrian Gropper: If we want to talk about a principled objection to the process that is one thing - if we want to revisit the proposal as passed, that is a separate issue Manu Sporny: Ask for counter proposals? we can re-run proposal again ... other option to make a resolution to undo the resolution ... is there another proposal that might have a high chance of passing Adrian Gropper: If we reopen that he will object <michael_herman_(trusted_digital_web)> Why am I only hearing Adrian? ...an no one else. An interesting conversation but definitely 1-sided ;-) ... we could perhaps revisit a month from now and might get to consensus <orie> everyone can see that folks don't agree to the resolution... I suggest we make the WG notes and specs reflect the WG consensus. No consensus, no resolutions :) Man: proposal from adrian appears to be temporarily defer and maybe revisit? Adrian Gropper: Or to put differently, maybe there is a better home elsewhere based on scope Justin Richer: Ultimate concern around resolution itself is what harm is caused by the text of the resolution for the spec ... believe this to be a simple matter and does not understand rejection of GNAP, etc <orie> we don't need to say anything about GNAP if folks can't agree its a good idea... same thing is true of WebAuthN or DID ION :) ... only arguments i have heard are don't understand, or like, or not ready yet ... if WG later decides to cut it for harm reasons then it can be cut then ... do not understand effort in objecting at this stage given how early the vc-http-api spec is ... trying to figure out if this is something that is a genuine blacker Joe Andrieu: Notes concern is over should vs must ... too early when neither spec is yet finalized ... should not anchor this early as it may be difficult to change later as we don't yet know what mechanism is ... examples from VC crypto suite Manu Sporny: Noting that same folks are round robin-ing same concerns <justin_richer> I was going to answer Joe's assertions but really there isn't much of a point here. <orie> are Justin or Adrian planning to implement this API? ... if implementers dont want to implement it isnt going to go anywhere anyways ... curious if there are implements that are planning a gnap implementation ... just want to verify implementer interest at this time Orie Steele: Speaking for his impl - no plans on impl for GNAP ... at this time - not to say maybe at a later date <justin_richer> I do want to point out that OAuth 2.0 bearer tokens are also usable in GNAP <justin_richer> And that the various GNAP bound-token methods are being ported to OAuth 2.0 as well Adrian Gropper: In process of adding an implementation ... has knowledge of others that might implement <orie> if in the future GNAP and OAuth2.0 merge, I'll be happy to support it, when our tooling supports it. Orie Steele: They will not [scribe assist by Justin Richer] <justin_richer> That is like asking for HTTP1 and HTTP2 to merge Manu Sporny: Need direct endorsement from imple <orie> maybe OAuth3? Mike Prorock: Pure implementer hat only -- no plans to implement GNAP at this time, doesn't mean we're not interested in it, I'm loathe to introduce things that are not finalized... also bringing this to market and customers, keeping it confined to OAuth2 for the time being. [scribe assist by Manu Sporny] Mike Prorock: Confined to oauth2 for time being Justin Richer: Thinks there is confusion on what the impact of this resolution might be ... concern raised was that secure access to the API is fundamental question ... and that we should make use of best tools available ... wants addition of one paragraph that gives guidance for both gnap and oauth2 + RAR ... spoken against further profiling ... security should be a major concern Mahmoud Alkhraishi: No objection to gnap but no roadmap to implement at this time ... perhaps change must to should <justin_richer> to clarify the "MUST" is that the spec has to talk about it, "SHOULD" doesn't make sense there <justin_richer> this isn't a normative implementaiton requirement Mike Varley: Secure key has not plans for gnap at this time, however there could be benefits - future roadmap at indeterminate time Manu Sporny: Concern is that there is enough work to do and no one is ready to do anything with gnap, and even the addition of gnap to the spec causes external facing pressure to implement full coverage of spec ... in addition to process concerns <orie> we're waiting to see GNAP on Auth0 / Okta Roadmap, before committing to considering support for it. Counter argument is "we are not saying you have to do anything" - whereas just existince in spec implies something will have to get done at some point Mike_v: sees value in gnap - reiterate that they have plans for gnap at some point, but not sure how it fits at this time <orie> Maybe that will happen soon, maybe it will take years... either way, we don't think its worth holding up building a secure API... with existing API security products and standards. ... not necessarily a fan of a lot of shoulds in protocol as it can make conformance difficult ... can we leave door open for future profiling <cel> GNAP on our (Spruce's) roadmap, but we cannot commit to a schedule right now Manu Sporny: Would like to strike a balance by delaying conversation around gnap for 6months Adrian Gropper: +1 To keep resolution as is and delay for some months ... allows focus on other issues, but does not remove it entirely from discussion ... keep resolution as is, but delay any action and reviisit <justin_richer> I'm personally fine with a delay because there was never a time constraint to address Adrian Gropper: Fine with a delay Manu Sporny: Wants a concrete time, suggests and asks for preference in time range Adrian Gropper: No set time range Joe Andrieu: Correct pr to not act on this resolution Manu Sporny: What about changing pr to note resolution? Joe Andrieu: What about overall process - wg resolution then carried to main group Jow: missing chain and lacking leadership on group and process not documented and this is creating the issues <orie> chairs of the ccg arbitrate, and if they fail, W3C leadership is involved i assume... Joe Andrieu: Must fix process Mike Prorock: From a Chair standpoint, checked in w/ W3C -- Joe's noting something important - we have not clearly stated how to handle that for individual graoups -- we could state in CCG that Editors can act in that role, but typically things are being read from my perspective, from W3C, in this case, it should raise up to Editors of spec, if resolution couldn't be found there, escalated to CCG Chairs. [scribe assist by Manu Sporny] Mike Prorock: From there, back into W3C proper if it escalated beyond there -- I do agree with Joe, a lot of this is lack of well defined process, creating situation to begin with. If we don't get some of this stuff addressed, we're going to circle back to this point, that concerns me, the issue is just a symptom. [scribe assist by Manu Sporny] Mike Prorock: Thanks for scribing me, manu Manu Sporny: Trying to decide whether or not to push this issue - specifically did not call self chair because that can be harmful Justin Richer: +1 To moving on and solve process issues in parallel -- this isn't a W3C Process WG ... better to have group cohesion and be able to move on than to dwell on issues Manu Sporny: Does not want to force a process meta issue Joe Andrieu: Notes that chair has raised similar concerns ... group does not have an editor or chair <orie> we do have editors Orie Steele: https://github.com/w3c-ccg/vc-http-api/blob/main/CODEOWNERS <mahmoud> dont we have four editors? <orie> these folks are editors <orie> @peacekeeper @msporny @mavarley @OR13 @mkhraisha ... concerned about possibility for process changing between meetings when blocks are hit <orie> I am one of them ... existential concerns over process Mike Prorock: +1 <justin_richer> Nobody's saying to ignore the problem, they're saying that this group has other work to do while the process is also fixed Manu Sporny: Notes we do have editors and code owners - they also are on the call Manu Sporny: Thinks chairs need to step in and make a ruling ... suggest that we elect a group chair and check for obj to existing editors next call Orie Steele: Agree that ccg chairs should step in ... no editor should ever implement a resolution that does not have consensus ... editor is responisible for impl consensus, not what they think is best <justin_richer> One note, often real consensus can't be reached until there is concrete text to discuss. It's the editors' job to get people there. Orie Steele: +1 Justin <orie> we can always add stuff later, if consensus is reaccheed Mike Prorock: I can note from the Chairs meeting, this is a topic of concern at the Chair level, we have decided that we will be making adjustments to make PR to process docs to clarify this. [scribe assist by Manu Sporny] <justin_richer> So I don't disagree in principle with Orie but you can put stuff into the draft spec and say "hey the editors did this, let's talk about it" Manu Sporny: Mrprorock: If there is a concrete proposal that you would like to take to the Chairs, please feel free to send that over to Chairs as a group. <justin_richer> Waiting for the group to agree on every detail is a recipe for never moving forward, in my experience. Ted O'Connor: Clear from discussion and way folks are speaking that there is no consistency in the group - this appears to be a subcomittee on a work item that is vague to begin with ... CGs don't have a lot of process forced by w3c ... this whole controversy is over a vague item that was vaguely decided ... people are willing to block all progress based on vague items ... high value in loose coupling and that is what we need Mike Varley: +1 To loose coupling. Justin Richer: +1 To loose coupling <orie> I could live with OAuth2.0 until something better exists... but I'm an engineer... ... yes there was clumsiness in process, but becuase we are not acting like any other group, therefore there will be issues, but we are where we are - and we are trying to produce something of value, hopefully also to the outside world ... if we can agree on top level goals, assume all are trying to work in good faith then we can move forward ... and hopefully gets us somewhere as opposed to trying to get things to get to a perfect process point Manu Sporny: If you would like to see something concrete - please send to mailing list for ccg chairs to consider ... future calls will focus on concrete issues that we can act on ... we are way down in meta and process, and people are here to build whatever the vc-http-api is ... next week will be hearing from others on their apis and will be discussing scoping ... this is it - thanks all
Received on Wednesday, 18 August 2021 14:20:25 UTC