W3C home > Mailing lists > Public > public-credentials@w3.org > June 2022

[MINUTES] W3C CCG Verifiable Credentials API Call - 2022-06-21

From: CCG Minutes Bot <minutes@w3c-ccg.org>
Date: Wed, 22 Jun 2022 13:33:11 +0000
Message-ID: <E1o40Tj-002gIE-Kf@mimas.w3.org>
Thanks to Our Robot Overlords for scribing this week!

The transcript for the call is now available here:

https://w3c-ccg.github.io/meetings/2022-06-21-vcapi/

Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:

https://w3c-ccg.github.io/meetings/2022-06-21-vcapi/audio.ogg

----------------------------------------------------------------
VC API Task Force Transcript for 2022-06-21

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0038.html
Topics:
  1. Introductions and Relevant Community Updates
  2. Use Case Update
  3. Options for /credentials/issue
  4. Options for /credentials/verify
Organizer:
  Manu Sporny, Orie Steele, Markus Sabadello, Mike Varley, Mahmoud Alkhraishi
Scribe:
  Our Robot Overlords
Present:
  Manu Sporny, Shawn Butterfield, Eric Schuh, David Chadwick, 
  TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), Joe Andrieu, 
  Dmitri Zagidulin, Dave Longley, Kayode Ezike, Tomj, Ted Thibodeau

Our Robot Overlords are scribing.
Manu Sporny:  All right welcome everyone this is the verifiable 
  credentials API call this is June 21st 2022 our agenda is here on 
  the agenda today is options options options so option processing 
  for all the VC API endpoints.
Manu Sporny:   I'm sure all of us will be.
Manu Sporny:  Give talking about options by the end of the call 
  but that's basically it for the agenda today we've got a couple 
  of other kind of questions around who's implementing what 
  endpoints yeah that's it that's it for the the agenda will also 
  do you know introductions relevant Community updates and start 
  out with that we have a couple of those things going on any other 
  updates or changes to the agenda anything else folks would like 
  to discuss today.
Manu Sporny:  For we get started.
Manu Sporny:  Okay and in Eric I'll note the will want to talk 
  about the status of the use cases and what the next step is there 
  after we do introductions and Community updates all right so 
  let's go ahead and jump into introductions.

Topic: Introductions and Relevant Community Updates

Manu Sporny:  And relevant Community updates.
Manu Sporny:   All right.
Manu Sporny:  One here that would like to reintroduce themselves 
  since we know who most of these the folks are here in a new 
  reintroductions.
<manu_sporny> First VC2WG meeting is next week: 
  https://lists.w3.org/Archives/Public/public-vc-wg/2022Jun/0002.html
Manu Sporny:  All right any updates just Community updates in 
  general I've got one and that is that the very first verifiable 
  credentials 20 working group meeting is happening next week so 
  first we see to delete G meeting is next week the Brent sundel 
  one of the.
Manu Sporny:  Um it is 11 a.m. eastern which I guess puts it 
  around 4 p.m. or 5 p.m. based on depending on where you are in 
  Europe if you have not rejoined please do so you need to rejoin 
  the group to recommit to the IPR agreement they will be posting 
  an agenda later on this week so just as a heads up.
Manu Sporny:   Up the to code.
Manu Sporny:  Here's our Brinson Del who has been who co-chaired 
  the VC part of the VC actually did he do vc10 I think he did part 
  of it right he definitely was a co-chair of the did working group 
  Brent's great and then we have Christina yasuda from Microsoft I 
  think this is I don't know if this is her first time sharing w3c 
  group or not but she's excuse me also done quite a bit of work on 
  it.
Manu Sporny:   Driver's license.
Manu Sporny:  That sort of thing that Microsoft so and then of on 
  Herman's going to be our our staff contact along with 
  pierre-antoine who are both you know really really wonderful 
  people as well so both so we're in very good hands is what I'm 
  trying to say and and it will be exciting to see see everyone you 
  know again new faces and old faces any questions are.
Manu Sporny:   Concerns about that.
Manu Sporny:  Unto other announcements.
Manu Sporny:  All right any any other announcements relevant 
  Community updates anything of that nature.
Manu Sporny:  Dimitri of got a question for you to any anything 
  public about kind of where what jff for vcd use going to do next.
Dmitri Zagidulin:  Yes now so this is still subject to change but 
  I believe the current plans are to do the next Jeff of plugfest 
  the successor to the first one that will involve most likely 
  issue API the day before the Autumn iiw at the computer science 
  museum History Museum.
Dmitri Zagidulin:  Day before yeah.
Manu Sporny:  So wait in person day before.
Dmitri Zagidulin:  And person day before.
Manu Sporny:  Interesting cool what do you know what the date for 
  that is.
Dmitri Zagidulin:  Yes so that is one second.
Dmitri Zagidulin:  Ah so that's November 14th.
Dmitri Zagidulin:  Right right everybody brush up on your apis 
  yes.
Dmitri Zagidulin:  Yeah people people did well yeah.
Manu Sporny:  Okay cool okay well good there's a quite a bit of 
  time between now and then you know we'll have yeah good okay good 
  for those of you that weren't a part of the first plugfest I 
  think we had what a grand total of three weeks to really 
  Implement and demonstrate some level of you know VC display 
  interrupt but it was good it got everyone yeah it's a.
Manu Sporny:   Yeah it was it was good.
Manu Sporny:  Okay thanks for that Dimitri that's good that gives 
  us a bit of planning is there any any thoughts about you know 
  what apis if any or did methods if any or is that just like the 
  topic of the next discussion in these need you okay.
Dmitri Zagidulin:  That's that's really the topics as you can 
  probably imagine there is a three or four different Lanes or 
  groupings or communities do the VC API open as you connect family 
  of protocols and of course wacky did come.
Dmitri Zagidulin:  So one of the challenges of the plugfest is.
Dmitri Zagidulin:  Do we demonstrate interop within that 
  particular lane and then for the overachievers wallets that can 
  speak the different families of protocols.
Dmitri Zagidulin:  Really that's the topic that is going to be 
  the subject of much argument on the mailing list.
Dmitri Zagidulin:  More agreement that's correct that's right 
  that's right I do not mean to cast aspersions preliminarily.
Manu Sporny:  Or agreement we just all going to agree with each 
  other we're just gonna agree on a single protocol and in put all 
  this behind us it'll be great all right any other updates are 
  anything Community updates before we go in to use case updates.

Topic: Use Case Update

Manu Sporny:  All right Eric over to you Eric and Josh over to 
  you where are we on use cases when should we talk about them next 
  etc etc.
Eric Schuh:  Sure so I think since the last time I gave an update 
  Joe and I have had some discussions and our plans have somewhat 
  shifted a little bit this is still dealing with someone at the 
  Fallout of one dropping off so plans change but effectively we 
  accepted the existing.
Eric Schuh:  Was in the.
Eric Schuh:  Case GitHub and I am working on what I believe is up 
  to seven P ARS one for each of our six use cases and then a 
  general one to respond to some of tall Ted's requests for some 
  just minor I guess formatting changes here and there so I'm 
  planning on having those 7pr.
Eric Schuh:   In by next week.
Eric Schuh:  Better platform for talking about each use case 
  individually worked out some bugs with the mermaid stuff in 
  rendering I think as well so I think next week would maybe be a 
  good time to take a look at the GitHub repo and its current state 
  I don't know if there's going to be too much to discuss because I 
  have a feeling people will it'll be more useful for people to 
  kind of take their own time outside of this call for some sense 
  of that to review and then maybe if we have.
Eric Schuh:   Have issues we can come back the following week or 
  in.
Eric Schuh:  Six and have discussions then but look for those P 
  RS in the next week before this call next week I'll I'll have 
  them.
Manu Sporny:  Awesome great thank you for that and for all the 
  work there Eric I really really appreciate that and Ted and Joe 
  as well you know for input I'm sure I put myself on the cue to 
  say I finally got around to fixing that mermaid flow diagram 
  rendering thing in respect so I don't think it does any of the 
  weird vertical height stuff anymore and there's a new release out 
  there so I don't know if you saw.
Manu Sporny:   That Eric but if you did.
Eric Schuh:  I did yep and I'll take a look during this this PR 
  process one last thing I wanted to mention is that Joe and I have 
  also decided to move our six use cases that we have so far to the 
  focal use cases section of that document and start to cherry-pick 
  kind of more breadth of use cases from both the VC use cases 
  document and the did use cases document so that.
Eric Schuh:  Well kind of.
Eric Schuh:  Out of that so if anyone has any use cases from 
  there that they'd like to see appear in the VC API please either 
  submit a PR or make an issue and let us know.
Manu Sporny:  Awesome thank you for that okay any questions and 
  concerns around the use cases document.
Manu Sporny:  Do either of you have I have I've wanted to do 
  either of you have an idea around like how this gets into the VC 
  working group or not in this iteration do you do you think I 
  could do you feel like it might be in a position where you would 
  want it as a use cases document published as by the VC working 
  group.
Eric Schuh:  I'll toss that one to jail.
Eric Schuh:  And we can't hear you.
Manu Sporny:  No audio for me yeah.
<joe_andrieu> reloading]
Eric Schuh:  I guess while we're waiting for him my initial 
  thoughts would just be that similarly to how we want to start 
  cherry-picking use cases from both the did use cases document in 
  b.c. use cases document I think that there's a good chance that 
  some of this will flow into it I'm not sure if one-to-one copy 
  would make sense or not probably try to leave that to the VC to 
  group to decide.
Eric Schuh:  But hopefully there's going to be.
Eric Schuh:  Interesting use cases that we could cherry pick out 
  might make sense.
Eric Schuh:  Are you back.
Manu Sporny:  Joe is your audio working.
Manu Sporny:  Nope still no audio.
<joe_andrieu> sorry
<joe_andrieu> It's a good candidate for adoption by the VCWG
Manu Sporny:  Okay we can we can bring that up you could type 
  type out what you're saying Joe if it's short but we can come 
  back and discuss this on a future call as well.
Manu Sporny:   It's a.
<joe_andrieu> I'll raise that there once we get going
<joe_andrieu> +12
Manu Sporny:  Candidate for option on there we go it's a good 
  candidate for adoption by the VC working group okay good just 
  wanted to see if there was interest there from seizing on working 
  on use cases to pull that Mark in okay sounds good Joe you might 
  want to raise an issue I don't know well we can just bring it up 
  we're first meetings next week so you know we can just.
Manu Sporny:   Bring it up there.
Joe Andrieu: +1

Topic: Options for /credentials/issue

Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/292
Manu Sporny:  Right moving into the core of the agenda now we're 
  going to start talking about options so the specification this 
  came up during testing so Andrew Jones has been working on the 
  test suite and noted a bunch of issues with the the OAS files.
Manu Sporny:   Is specifying.
Manu Sporny:  Things for options that no longer makes sense or 
  we're not using and that sort of thing so we're going to go ahead 
  and take a look at that let me go ahead and share my screen.
Manu Sporny:  Okay so I think this is it and then let me pull up 
  the VC API.
Manu Sporny:  In right now we are going to look at issue 
  credential in specific the specifically the options for issuing 
  credential in right off the bat there's some errors here or 
  things that look like you know they're they're wrong to a certain 
  degree so every single one of the points that we have has this 
  options object one of the first.
Manu Sporny:  Had was as the op ER is the options thing optional 
  or not like do you have to specify options or can it be an empty 
  object that kind of stuff.
Manu Sporny:  Well you've got let's see if you have audio if 
  you've rejoined because you added some things here to start us 
  off yes I can hear you.
Joe Andrieu:  How About Now new browser so you know I realized 
  procedurally this might be an annoying place it's a raise this 
  but maybe it suggests a new issue on its own but we still don't 
  have our endpoint specifying which component is hosting that 
  endpoint and who's expected to call it and I think that's 
  confusing a lot of the conversations about are we talking about 
  an endpoint on a.
Joe Andrieu:   Verifier app or on.
Joe Andrieu:  Iris and those end up I feel being very different 
  surfaces.
Joe Andrieu:  So without that it's hard for me to even understand 
  which options were talking about.
Manu Sporny:  Yeah plus one to that and you've been very 
  consistent about you know that being an issue and I think the 
  group agrees that's an issue so would it be okay if we specify 
  which end point we're talking about like which which app we're 
  talking about sorry which which thing we're talking about like 
  whether it's the issue or a poor the issue or service that we're 
  talking about for launching into a conversation.
Joe Andrieu:  Yeah I think that's great I mean I think that the 
  key thing is for us to have a good conversation I think we need 
  to have that defined I think once we do we can talk about it and 
  then I think there's a second question is how do we get the spec 
  text updated so that incorporates that in some some way.
Manu Sporny:  PS maybe we could identify maybe we can add 
  something to the OS to say oh this is meant to be exposed through 
  the issuer app or it's meant to be exposed through the issue or 
  service where it's meant to be exposed through both I don't know 
  if we have any in points like that but maybe we can just kind of 
  tag each one of the endpoints on with respect to where they're 
  expected to be.
Manu Sporny:  System they packed be exposed on.
Manu Sporny:  That's not some of that out.
Joe Andrieu:  You know I don't know OAS enough to know if that's 
  sort of the right way to do it but it sounds reasonable.
Manu Sporny:  Well if it's not supported by OS we can just put it 
  in the respect proper to start.
Manu Sporny:  I guess because I was asking the kind of the 
  question conceptually site conceptually do each one of these 
  endpoints map to one or more roles in the ecosystem that can 
  decorate or one or more what are we calling these things systems 
  Joe what would what's a what's a nap and a service is that a 
  system is it a roll.
Joe Andrieu:  I've been I've been calling them components I think 
  that's the language with that first diagram in the VC API itself 
  where we identify those components.
Manu Sporny:  Hard to read English but oh well okay so.
Manu Sporny:  I need for PR add a ripped ER to each endpoint that 
  lists which components it's expected to be attached to.
Manu Sporny:  Okay okay so that's the first thing so credential 
  issue.
Manu Sporny:  So this endpoint is expected to be exposed on an 
  issuer service that's what implements it but it could be exposed 
  through the issuer app I'm that's a question not a not a it's an 
  assertion that's looking for people to say no that sounds wrong.
Dave Longley:  I'm going to go ahead and assert that it sounds 
  wrong.
Manu Sporny:  Okay so what's wrong about it.
Dave Longley:  Part of it that seems right as it's exposed on the 
  issue or service I don't know what it would look like to expose 
  it on the issuer app.
Manu Sporny:  Is a software-as-a-service thing an issue rap.
Dave Longley:  No I don't think so I would think that would be an 
  issue or service.
Manu Sporny:  Go ahead Sean you're on the queue.
Shawn Butterfield:  Yeah I'm just thinking about what this would 
  look like if I were to implement it it wouldn't be so I'm plus 
  one today we wouldn't be on an issuer app we think of it as a 
  developer service so it would feel to a SAS developer like a 
  low-level API or a low-level library that they would implement.
<joe_andrieu> Link to the architecture overview where services 
  and apps are defined 
  https://w3c-ccg.github.io/vc-api/#architecture-overview
Manu Sporny:  What are we is an issuer app Joe is an issue or a 
  PK is a website in issue rap.
Manu Sporny:  Which is like a human facing website and then if it 
  exposes apis is it still an issue rap or does it become an issue 
  or service at that point.
Joe Andrieu:  So certainly a website could fulfill any of these 
  roles I mean I think I do not personally make a distinction 
  between json-based apis is being magical endpoints any different 
  than a website URL is an endpoint the difference that we put into 
  the architecture is that a nap executes the business rules and 
  policies whereas the service component is providing generic 
  services at the behest of a nap.
Joe Andrieu:  So in the in the in the scenario that we use for 
  u.s. permanent residence card the there was a mock website for 
  USCIS which held the business logic about who was supposed to get 
  what is credentials issued and that website spoke over the back 
  end to the verifier or the issuer service sorry to get those 
  credentials issued.
Joe Andrieu:  So the Touchstone that I've use is you know the 
  business rules that are specific to that application as opposed 
  to a generic service which is software-as-a-service.
Manu Sporny:  Okay so one way to look at this is anything that 
  provides generic Services is a service like the shorter service 
  we are fire service in things that have business logic in them 
  are the apps.
Joe Andrieu:  That's right that's how I tend to think about it.
Manu Sporny:  Okay that that seems like a nice clean the stupid.
Dave Longley:  Yeah and the other thing I would add to that is 
  that the that business logic acts as a gating factor for the 
  application to use decide whether or not it's going to use the 
  service so there's sort of a trust boundary thing that's how I 
  tend to think about it.
Manu Sporny:  Okay good it seems nice and clean architecture Lee.
Manu Sporny:  Okay all right so credentials issue is on the issue 
  or service. It has in the way you use it is you send it and 
  unsigned credential and it will basically attach a prove to it in 
  and send that proof back in previous calls we had we seem to have 
  come to agreement that these.
Manu Sporny:   He's issuer services.
Manu Sporny:  Especially this one is configured is pre-configured 
  through some kind of out-of-band mechanism to use a specific to 
  use specific key material to use specific revocation list formats 
  basically the endpoint is configured with all of these these 
  things so calling and dynamically changing.
Manu Sporny:   Aging the.
Manu Sporny:  In the credential status mechanism and all that 
  kind of stuff is complexity that we seem to have shied away from.
Manu Sporny:  So that's kind of the background for the options 
  object here.
Manu Sporny:  We have some weird things in here like for example 
  Challenge and domain challenging domain are typically used on 
  presentations they are not used in credentials when signing 
  credentials I think and then for credential status we're say I 
  think what we've said is that thing credential status is not.
Manu Sporny:  Settable anymore or by default it's not something 
  it's something that's pre-configured on the endpoint in not 
  settable when you make the call Dave.
Shawn Butterfield: +1 Agree
Dave Longley:  Yeah I was just going to say that the challenge 
  and domain which could also sort of be understood as a audience 
  are things that are used with authentication proofs and those are 
  not the kinds of proofs that you put on BCS and you put assertion 
  proofs on them and so challenging domain I don't think make sense 
  here and gradual status as mentioned would be something that was 
  already configured for the system so that would also for that 
  particular issue or endpoint or configuration and so that 
  wouldn't make sense as an.
Dave Longley:   Option either.
Manu Sporny:  The queue okay so I got a plus one from Sean.
Manu Sporny:  Okay so that means that the pr should strike 
  challenge domain and credential status from the options.
Manu Sporny:  Objections to doing that.
Manu Sporny:  Okay I'm hearing no objections I'm worried that 
  there's some kind of Miss rendering going on here so I'm going to 
  go and look at the OAS just temporarily.
Manu Sporny:  Let's see here.
<kayode_ezike> Couldn’t the service provide its own value for 
  ‘created’?
Manu Sporny:  No it would be in like who gets your credential 
  options up here it is okay all right so we're talking about 
  striking challenge domain credentials status okay there are no 
  objections to that need.
Manu Sporny:  OSHA mean credentials and remove challenge amazing 
  credential status from a list of suitable options.
Manu Sporny:  Michelle and point.
<dave_longley> Yes, @Kayode ... "created" should be autogenerated 
  if not provided
Manu Sporny:  You sure service and points.
Manu Sporny:  Yeah that's a good question.
Manu Sporny:  Defaulted current system time for created.
Manu Sporny:  So we have a default.
Manu Sporny:  Don't have normative language around that default 
  but that's fine we can fix that later there's another question 
  around a options is the options object itself optional like do 
  you could you just do credential colon and put in a credential 
  and that just leave options completely blank.
Manu Sporny:  I suggest it is totally optional.
Dave Longley:  Plus one to that.
Manu Sporny:  We like we don't have any mandatory options right.
Dave Longley: +1 To options being optional
Kayode Ezike: +1
Dmitri Zagidulin:  Yeah plus 1 to that as well.
Manu Sporny:  Okay all right.
Manu Sporny:  So the next need for PR.
Manu Sporny:  Optional is object itself was optional.
Manu Sporny:  Or if we were if we had.
Manu Sporny:  Me three and you know today.
Manu Sporny:  We have no mandatory options and the options object 
  is completely optional.
<dave_longley> can be omitted
Manu Sporny:  It could be specified.
Manu Sporny:  That's true for in can be emitted thank you and.
Manu Sporny:  And be emitted.
Manu Sporny:  This is true across the entire API.
Manu Sporny:  Clearly we'd have to look at every single endpoint 
  but I think it's true across the entire API.
Manu Sporny:  Because if it's not an option if it's yeah it's the 
  I'd like if it's in options at shouldn't we shouldn't be doing 
  this whole mandatory options thing.
Dave Longley:  It will probably be true for the whole API but as 
  you said we need to look.
Manu Sporny:  So we'll keep that in mind as we go along but I'm 
  sure that when there are no mandatory options which should be 
  true for all any points at The Shins object emitted.
Manu Sporny:  All right that's another PR.
<dave_longley> may not be true for verifying presentations 
  depending on how we pass "challenge"
Manu Sporny:  Okay so that's for that in point.

Topic: Options for /credentials/verify

Manu Sporny:  Just going to comment that so we don't lose it next 
  topic is where are the options for credentials verify.
Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/292
Manu Sporny:  And that is still this issue its Goshen around 
  credentials verify.
Manu Sporny:  Skull go ahead Dimitri.
Dmitri Zagidulin:  I'd like to propose that we tackled the topic 
  of verifier options from the end right what Amazon purportedly 
  starts with the Press.
Dmitri Zagidulin:  Is before doing that depends that's we start 
  that their app UI that's from that here's here's why proposed 
  that.
Dmitri Zagidulin:  Most of verification you I implemented so far 
  tends to.
Dmitri Zagidulin:  Even though we do have a little bit of 
  fine-grained results right we have a list of Errors we have a 
  list of checks performed but I would like to propose we go one 
  step further and have the verify API return back a list of events 
  and then pass fail on each one of them so for example right the 
  reason I mentioned start with you I first is.
Dmitri Zagidulin:  Even imagine a wallet or a verifier app 
  displaying an overall status verified or not but then displaying 
  the details a list of okay expiration date checks out the 
  signature checks out but the key was revoked or the credential 
  was revoked right so my proposal is and this this would affect 
  the options object which is why the working backwards Bart what 
  if we.
Dmitri Zagidulin:   Change the.
Dmitri Zagidulin:  Bi to return an overall result but also an 
  events log which would be objects similar to the checks 
  performed.
Dmitri Zagidulin:  But with more detail.
Dmitri Zagidulin:  If people think that's a good idea that might 
  help inform.
Dmitri Zagidulin:  Verify options list in case somebody wants to 
  not perform all of the checks but just to subside so that's it.
<ccgbot1> DavidC has been added to the queue: DavidC
<kayode_ezike> Yes, events log would be great! I believe this is 
  a related PR: https://github.com/digitalbazaar/vc-js/pull/92
Manu Sporny:  Yeah I mean that that that sounds intriguing 
  Dimitri I think the so yeah plus one to exploring that I think 
  you know we probably when you and you included this in what you 
  said right we I'm concerned that we need a simple yes no response 
  back with more detail which is what exactly which is what I think 
  you're you're adjusting.
Dmitri Zagidulin:  Yes yes so definitely both.
Manu Sporny:  Here okay so let's let's take a look at the end 
  point does anyone have any concerns about going down this path.
Manu Sporny:  Okay go ahead.
Manu Sporny:  David go ahead to meet tree.
Dmitri Zagidulin:  We both so my.
Dmitri Zagidulin:  Response to that would be one one reason why 
  might be a good idea to provide an event log in success as well 
  is because different verify our services will perform for in 
  checks right so it informs the user.
Dmitri Zagidulin:  Exactly what do we mean by this is verified 
  did this particular service check the revocation status or did 
  this particular check.
Dmitri Zagidulin:  I don't know check for the issuer's keys 
  revocation.
Dmitri Zagidulin:  Not not all services will be do that hence the 
  level of.
Dmitri Zagidulin:  Okay so you're absolutely right that we don't 
  want this mechanism to shore up non-conforming implementations 
  but so far the specs and implementations leave a lot of leeway 
  for implementers which is should be a separate discussion topic 
  but also even business logic wise you don't always want to like 
  just as an example right.
Dmitri Zagidulin:  With the driver's license when using the 
  physical driver's license for age verification.
Dmitri Zagidulin:  The verifier looks at the date of birth but 
  also in some cases looks at the expiration right so some venues 
  will say yeah even if this is a valid license and your of age 
  because the credential has expired we're not going to.
Dmitri Zagidulin:   Accept it.
Dmitri Zagidulin:  Other venues will say no we don't care that 
  it's expired you're old enough go ahead and so to model that use 
  case.
Dmitri Zagidulin:  What about you.
Manu Sporny:  Well go ahead Dimitri I'm just noting that Joe's 
  been on the Q so Dimitri Joe and then David.
Dmitri Zagidulin:  That's also tomorrow that use case to give the 
  verifier the ability to perform a subset of the checks.
Dmitri Zagidulin:  Would PA real wood does not necessarily denote 
  about implementation it is still both are valid.
Manu Sporny:  All right thanks to me to go ahead Joe.
Joe Andrieu:  Yeah I think you both have good points I think the 
  seems to be the right balance is to make it optional to include 
  the event log on a failure value of I'm sorry include the event 
  log on success and that we should probably always include it on 
  failure I'm looking at this from a debugging standpoint and I 
  don't know how many times I've.
Joe Andrieu:  I was doing something that I didn't realize it was 
  doing and they're sort of information maybe I turn it on and do a 
  test or maybe I just have it on all the time but I could see in 
  production you may not want to have that extra traffic so 
  optional seems like a good way to handle it.
Manu Sporny:  Um I'm wondering if we got it I mean it's so these 
  are all good points I'm wondering if we're confusing verification 
  from validation I think what what Dimitri I heard you say had a 
  lot to do with validation use cases not verification so this is a 
  huge interoperability could be a big interoperability issue if 
  you have some verifiers saying yeah the verifiable credential is 
  valid and you have other verifiers saying no it's not.
Manu Sporny:   Ballad so I.
<dmitri_z> i do mean verification
Manu Sporny:  I think that we made a distinction in the vc10 data 
  model sorry we made a distinction in the vc10 specification where 
  we said there are two processes active here verification and 
  validation verification checks for things like is the signature 
  valid is the is the verified well I think it there we couldn't 
  even agree on that right because because there were things like 
  is the is the.
Dmitri Zagidulin:  That's exactly my point but the lack of a.
Manu Sporny:  Well I think what I thought what we said was okay 
  then we need to split these into two things and it may be that we 
  need to split this into two different apis the verifying API will 
  always do the same thing regardless of what issuer like their 
  normative things you have to check for like the signature being 
  valid for example in you have to check for the expiration date as 
  an example but when it comes to do you do you pay attention.
Manu Sporny:   To any more than that.
Manu Sporny:  All of a sudden you're in like validation and 
  that's where kind of the event log in specific business rules are 
  triggered and that kind of thing so I'm wondering.
Manu Sporny:  I'm well one we can have an event log for both but 
  I'm wondering if we want to separate verification from validation 
  I have two different endpoints or if folks feel like we really 
  should have this all on the verification and point.
Manu Sporny:  Go ahead Joe.
<ccgbot1> DavidC has been added to the queue: DavidC, DavidC
Joe Andrieu:  Yeah it depends which end point you're talking 
  about so validation as is written up in that section on 
  architecture happens at the app so the app is one that knows the 
  business rules and knows whether or not expiry matters or knows 
  whether a particular issuer is valid for a particular assertion 
  and my sense of verification was your check in the crypto and 
  you're checking the status property and that's it so.
Joe Andrieu:  Talking about having a validation endpoint at the 
  verifier service I think that's probably a bad idea I do think it 
  is something that app needs to handle and whether or not they 
  expose an endpoint for it is is my sense an internal question for 
  the app developer.
Manu Sporny:  Right thank you Joe Dimitri you're up next.
Dmitri Zagidulin:  So I think this is a really central question 
  for us whether we want to separate verification validation into 
  two separate API endpoints 11 consideration is that if we do have 
  two separate API points does that mean you the verifier.
Dmitri Zagidulin:  It's to make to API calls and.
Joe Andrieu:  Which verifier Dimitri.
Dmitri Zagidulin:  The client that is making the request.
Joe Andrieu:  Right so the when you said the verifier makes 
  multiple calls I'm thinking you mean the app calling the service 
  but I couldn't tell from the question.
Dmitri Zagidulin:  Yes let's say I've going to service.
Ted Thibodeau: +1 Validation == business logic; verification == 
  crypto, basic structure.  Separation of these endpoints seems 
  optional to me.
Dave Longley: +1
Joe Andrieu:  Right so in that framing I think I still hold the 
  what I said before which is I think the app is responsible for 
  validation and therefore the app would not be asking the software 
  as a service to check its business rules the app itself is going 
  to be an embodiment of its own business rules and and if an app 
  calls a bunch of endpoints internally because it's got some micro 
  Services architecture you know that's up to the app to decide how 
  they how many endpoint calls they want to make on their own.
Manu Sporny:  All right thanks Joe um Ted mentioned something in 
  text David you're up next.
Manu Sporny:  There is in the in the jitsi chat I can only see 
  one Q so we'll we'll handle that that shouldn't hopefully you 
  know trouble.
Kayode Ezike: Sidebar: Does it even make sense to refer to the 
  functions in an apps as “endpoints”?
Manu Sporny:  Um thanks David Ted do you want to vocalize what 
  you put in to the chat Channel.
Manu Sporny:  I think it was a useful comment.
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): Yeah I can 
  make my mic work.
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): What I'm 
  saying is physically validation to my mind as business logic and 
  verification is crypto and basic structure is the thing integral.
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): Separation of 
  those two endpoints you know optional to me there's I can 
  conceive of situations where I would just want one thing for 
  anybody to deal with and what requests they made to it would 
  govern what process are and what they got back.
Manu Sporny:  Okay so the only question I have at that point Joe 
  said thumbs up to that Dave Longley did I see you + wanting that 
  or were you plus wanting something else.
Dave Longley:  Yeah I'm in agreement with Joe and Ted yep.
Manu Sporny:  Okay alright okay so that then calls into question 
  the name of the endpoint because the name of the endpoint is 
  credentials and verify but we're also doing validation in it how 
  do you square that Circle.
Manu Sporny:  Go ahead babe.
Dave Longley:  Well I don't think we are doing validation in 
  there especially we look at the definition that we put into the 
  VC data model spec we're checking cryptography structure and 
  timeliness which involves credential status and expiry date and I 
  think all of those things are generic checks that don't involve 
  any complexity for.
Dave Longley:   Business logic.
Dave Longley:  Reject a we would return false from a verification 
  point of any of those checks failed and we had an event log as 
  was described or whatever we want to call this log business the 
  app could apply business logic rules to make exceptions if it 
  wanted to.
Manu Sporny:  Go ahead show.
Manu Sporny:  Actually hold on I'm sorry David is that what is 
  that an old kyo-ahn said like okay sorry yep got it got it go 
  ahead Joe sir.
Joe Andrieu:  I was mostly just going to agree with Dave I don't 
  think validation is happening at the verifier service I think it 
  happens within the app and it may or may not express any point I 
  think we're talking about the verifier service API which should 
  not be doing validation.
Manu Sporny:  All right Dimitri does that gel with your worldview 
  or is there some.
Manu Sporny:  Because I feel like there's some misalignment but I 
  can't quite put my finger on it.
Dmitri Zagidulin:  It's it's a reasonable stance.
Dmitri Zagidulin:  I am okay with it for the moment.
Dmitri Zagidulin:  Headed that way see if I run into any 
  difficulties but if we're saying this if we're saying that 
  verification is atomic essentially the we do want that event log 
  that there is the question of whether or not we want.
Dmitri Zagidulin:  Turned on success and Joe made a good point 
  for debugging purposes it might be a good idea so that's a good 
  candidate for our options object which is how we started this 
  whole conversation but the thing I want to mention is if we're 
  treating verification versus validation as as atomic as the thing 
  for the service to perform it would be really interesting to see 
  some normative language for which exactly the steps we're 
  expecting other fire service to perform.
Manu Sporny:  Yeah I agree that would be we need a trainer 
  upright because because if we don't do that then all of a sudden 
  some implementations are checking for timeliness and other ones 
  are not and if we're checking for timeliness then we have to be 
  maybe have an option where we can override the time.
Manu Sporny:  Like I got this in the past I want to verify it was 
  valid in the past go ahead Joe.
Joe Andrieu:  Yeah I don't think that's what timeliness means in 
  this context I think it means checking the status and point.
Manu Sporny:  Okay I was I was going for something else there I 
  agree we need to check the status endpoint but what happens if 
  the if the credit credentials expired yesterday.
Manu Sporny:  Interesting yeah I know like I get it.
Joe Andrieu:  This was to support right the revoked driver's 
  license.
Manu Sporny:  Yep yep yep yeah okay alright so so expiration date 
  issuing State all that stuff is really about validation not.
Manu Sporny:  I get it okay yeah that makes sense to me does 
  anyone else have any concerns about that.
<davidc> it is ssential to describe the verification steps in the 
  VCDM
Manu Sporny:  Okay King so what are the steps for what are the 
  normative language check the proof check the credential status.
Manu Sporny:  Check for all its really checked the check check to 
  make sure the issuer check to make sure that.
Manu Sporny:  Check to make sure the issuer key has not been 
  revoked as of a particular date.
<davidc> check that Now is between the issuance date and 
  expiration date
Manu Sporny:  I'll just leave this I think we're going to need a 
  date thing here because how are you going to check the business 
  rule what API are you going to call to see if something was valid 
  on a particular date so so let me here's the here's the issue I'm 
  concerned about you've got a verifiable credential the issuer key 
  was revoked yesterday but you really just want to see if the 
  thing was valid the day before.
Manu Sporny:   For yes.
Manu Sporny:  Day so you're in the middle of a validation check 
  but you need an endpoint to call to see if the issuer key was 
  valid at a certain point in time Joe go ahead you're on the 
  queue.
Manu Sporny:  No audio from you Joe.
Joe Andrieu:  Sorry I lost my train of thought that the one thing 
  in here that's that you haven't mentioned is that it's a it's a 
  valid BC structural checks have been mentioned but I don't think 
  we've defined what that means I don't know if we have a formal 
  schema for example those sorts of checks what a I'm hesitant to.
David Chadwick: +1 To checking that the VC conforms to its schema
Joe Andrieu:  Just that temporality is anything other than a 
  validation check however it seems like it would be particularly 
  useful to be able to say validate this to the best of your 
  knowledge at a particular point in time the problem is you can't 
  necessarily adjust all the parameters to go into the past 
  especially for something like a status check so I think this 
  semantics have to be.
Joe Andrieu:   Be what.
Joe Andrieu:  Now and there may be some cases where we could 
  optionally support check it in the past however when you get back 
  that event log you will know that expiry failed and so if you 
  have business rules to say hey we don't care we're actually we 
  care about yesterday then I think your validation process could 
  handle that if it has the event log.
Manu Sporny:  Interesting any other thoughts on that.
Dave Longley:  I would my thought would be I would prefer all 
  these things to fail closed and all of the verification systems 
  can all know about expiration and current time and they can know 
  that they can check whether or not the current time is between 
  the issuance date and expiration date and they can fail when that 
  happens and that's returning event log that can be checked by 
  business rules to allow the VC to be used if desired.
Manu Sporny:  Interesting okay alright alright so on the pr is to 
  Define steps for verification at the verifier service using 
  normative language which means you check to make sure the 
  structure of the VC is valid you check the credentials schema 
  that's associated with it if one exists you check to make sure 
  that the issuer key has not been revoked you check to make sure 
  that the credential.
Manu Sporny:   This has not marked.
Manu Sporny:  As having been revoked and inevitably we will go to 
  the VC 20 API and maybe add additional checks what do we do when 
  that happens go ahead Joe.
Joe Andrieu:  Yeah I'm not answering your last question there it 
  was about if can we generalize the language here for issuer key I 
  think it should be verification method or something.
Manu Sporny:  See that thanks.
Manu Sporny:  So it seems like the event log having the event log 
  is a very important thing because in the future.
<dave_longley> and check that the current time is between 
  issuance date and expiration date
Manu Sporny:  How do you differentiate between what checks are if 
  we add a check which is you know over the next 10 years almost 
  inevitable.
Manu Sporny:  How do you know whether or not that check was being 
  made.
<ccgbot1> DavidC has been added to the queue: DavidC, DavidC, 
  DavidC
Dmitri Zagidulin:  Wait so was that a rhetorical question or is a 
  question to the group.
Manu Sporny:  Well the question of the group I mean like how do 
  you eat we're going to add another check at some point in the 
  future like let's just say that you know I we for whatever reason 
  vc10 didn't have the credential schema property and in the future 
  it does well we wouldn't list the credential schema property here 
  but then you know we do or or if the verification method let's 
  say we had revoked but we didn't have suspended and now we have 
  suspended.
Manu Sporny:   See what I'm saying.
Dmitri Zagidulin:  So again this to me seems like an argument for 
  optionally returning the checks performed on success exactly.
Manu Sporny:  Right that's yeah yeah that's what I'm saying I'm 
  that's what I'm saying is that.
Manu Sporny:  We're going to need it's yeah it's another argument 
  for that or it's one of the arguments for that.
Manu Sporny:  Go ahead David.
Dmitri Zagidulin:  What about a requested optional that long.
Dmitri Zagidulin:  So that's fine.
Manu Sporny:  I note the sorry I have been not tracking time 
  where three minutes over so go ahead Joe and then we're going to 
  have to shut the call down.
Joe Andrieu:  I was just trying to thumbs up and at the other 
  thing.
Manu Sporny:  Okay all right good okay so the other part of the 
  pr that's needed is we're going to say we want an event log it's 
  an optional value not mandatory that provides the checks 
  performed and by default that's turned off.
Manu Sporny:  Okay all right thank you everyone for the call in 
  the the Lively discussion today we got through a lot of things 
  especially we've got a number of PR's that need to be raised so I 
  will go ahead and note that here and that's it for the coal will 
  see everyone next week where we will talk a bit about the use 
  case of stuff and keep going through this options discussion 
  thanks all bye.
Received on Wednesday, 22 June 2022 13:33:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 June 2022 13:33:13 UTC