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] ✪
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
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
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] ✪
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
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] ✪
<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
<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