W3C home > Mailing lists > Public > public-credentials@w3.org > August 2021

[MINUTES] W3C Verifiable Credentials HTTP API Call - 2021-08-17 12pm ET

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Wed, 18 Aug 2021 07:20:09 -0700 (PDT)
Message-ID: <611d1719.1c69fb81.25a47.4e6e@mx.google.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:21 UTC