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

[MINUTES] W3C CCG Verifiable Credentials API Call - 2022-03-01

From: CCG Minutes Bot <minutes@w3c-ccg.org>
Date: Tue, 01 Mar 2022 22:22:49 +0000
Message-ID: <E1nPAtH-0000or-TY@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-03-01-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-03-01-vcapi/audio.ogg

----------------------------------------------------------------
VC API Task Force Transcript for 2022-03-01

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0147.html
Topics:
  1. Introductions and Reintroductions
  2. Relevant Community Updates
  3. Issuer endpoint cryptosuite configurations
  4. Exchange discovery
Organizer:
  Manu Sporny, Orie Steele, Markus Sabadello, Mike Varley, Mahmoud Alkhraishi
Scribe:
  Our Robot Overlords
Present:
  Manu Sporny, Orie Steele, Dave Longley, Joe Andrieu, Mahmoud 
  Alkhraishi, Jon St. John, Dmitri Zagidulin, Juan Caballero, Mike 
  Varley, Justin Richer, BrentZ, Brian Richter, TallTed // Ted 
  Thibodeau (he/him) (OpenLinkSw.com), Kayode Ezike

Our Robot Overlords are scribing.
Manu Sporny:  Welcome everyone to the March 1st 2022 VC API call 
  our agenda is here on the agenda today we've got just a quick 
  review introductions relevant Community updates then a discussion 
  on the issue.
Manu Sporny:  Cryptid sweet configurations on that end point so 
  this is Paul 263 and then after that we have a discussion on 
  Exchange Discovery through Mike Farley's Pole to 68 hold on one 
  second.
Manu Sporny:  Well let's see if the transcription is going still 
  yeah the transcriber still going so we'll keep going and then 
  after that we've got issue processing any updates or changes to 
  the agenda anything else that we want to cover today.
Manu Sporny:  Okay if not let's go ahead and get started the 
  first topic is the let's see introductions in reintroductions is 
  there anyone knew that would like to introduce themselves or 
  anyone that's been here for a while that would like to 
  reintroduce themselves.

Topic: Introductions and Reintroductions

Manu Sporny:  Go ahead Dave.
Dave Longley:  Yeah so I'm not new I've I just haven't been to 
  many of these calls lately my name is David Longley I'm with 
  digital Bazaar and I've worked on implementations for VC API and 
  various other things over a number of years and worked on a 
  number of Standards over the last decade or so.
Manu Sporny:  Great great to have you here Dave let's see well 
  John Henderson have you introduced yourself before.
Manu Sporny:  Feel you need to but we always like.
Manu Sporny:  Being from new folks.
<john_henderson> Sorry, I'm in a bit of a loud location
Manu Sporny:  Okay in a lab location well welcome and hopefully 
  we'll be able to hear from you in the coming weeks any other 
  introduction to reintroductions.
<john_henderson> But I'm a software engineer with EnergyWeb 
  working on SSI. Thanks for the welcome
Manu Sporny:  K any relevant Community updates.

Topic: Relevant Community Updates

Manu Sporny:  And I see John introduced himself by typing 
  something out software engineer with energy web working on SSI 
  great to have you here.
Manu Sporny:  The only Community updates I have our we're already 
  stated on the call earlier today the weekly call that is 
  verifiable credentials Charter looks to be on a pretty good 
  trajectory now where I think hoping the close close that up close 
  that Charter work up in the next couple of weeks get that in for 
  a formal vote so please take a look at the VC w.
Manu Sporny:  If you have not had a chance to already that is.
Manu Sporny: https://w3c.github.io/vc-wg-charter/
Manu Sporny:  Available as soon as DNS response here we go.
Manu Sporny:  And look at the poll request there a number of 
  outstanding pull requests there and then you know the did formal 
  objections have been handed back over to the w3c director so 
  we're hoping that that will be published the did Cora 
  specification will be published as a w3c standard sooner than 
  later.

Topic: Issuer endpoint cryptosuite configurations

Manu Sporny: https://github.com/w3c-ccg/vc-api/pull/263
Manu Sporny:  Okay moving on to our primary topic then this is 
  let's see topic issue or in point crypto sweet configurations I 
  tried to create a succinct title to it but if you look at pole 
  263 there is a much more kind of involved discussion going on 
  there.
Manu Sporny:  So we should just open up Dave you're the one that 
  raised the pr maybe you can do like a quick intro to thoughts on 
  it.
Dave Longley:  Sure so I raise this PR in response to sort of 
  looking at our initial design that we had for the VC API going 
  back a couple of years now and it seems like we might have had 
  some of the sort of authority model flipped in the configuration 
  model flipped for how I think the API should work effectively we 
  have a situation where we've created an API where the client.
Dave Longley:  Locations that are using it.
Dave Longley:  Attempt to build some set of parameterised 
  configuration variables they get in they can pick a number of 
  different variables and hope that those work as a valid 
  combination on the issuer Without Really knowing what the issuer 
  can do.
Orie Steele: +1 The API is mostly an http 400 service :)
Dave Longley:  Additionally the issuer may not even be able to 
  combine those those those selected parameters in to produce 
  something valid in response so that the the issue itself details 
  some of those gets into some of the details and give some 
  examples of that the other problem with this is the authority 
  model is kind of flipped where instead of having a party that 
  setting up the issuer create a set of valid configurations and 
  then saying client applications you can use these.
Dave Longley:   The the model that we have with the API key.
Dave Longley:  There's that party to just to just say I've made 
  all my keys and all of my everything available to anyone who has 
  access to this API you combine things however you want to use it 
  and I don't think that that's the right way to approach the 
  problem and I think some of that has come out of trying to 
  optimize the API for building a test Suite that allows us to mix 
  and match a bunch of different features to prove interoperability 
  but that doesn't optimize for real you real world use case and 
  for parties that.
Dave Longley:   I want to be able to select.
<orie> Dave answered my questions related to that PR here: 
  https://github.com/w3c-ccg/vc-api/issues/267
Dave Longley:  Clients are able to have access to different keys 
  to issue so that it can limit blast damage and for a variety of 
  other security and privacy reasons and so on so that proposal 
  that PR kind of my original approach was I'm going to start 
  chipping away at the parameters that are available to this API to 
  explain that the client can't really just pick and choose these 
  parameters its problematic and or a responded to that.
Dave Longley:   That asking me.
<orie> yes, and thank you for that very thoughtful proposal
<orie> I am still digesting it
Dave Longley:  Create a larger issue that sort of says instead of 
  chipping away at these one at a time why don't you make a 
  proposal that in a more unified way talks about how we might 
  readjust the API to address the concerns that I put in that PR 
  and that's in I think number 267 is where that proposal is so 
  that's kind of the whole issue that's on the table its kind of re 
  looking at the be Capi trying to understand what we optimized it 
  for with our design originally and whether or not.
Dave Longley:   Not that really makes it make sense for real 
  world use case for.
Dave Longley:  For test Suite.
Manu Sporny:  All right thanks Dave folks go ahead and throw 
  yourself on the Queue if you've got comments I know that or 
  you've engaged in that discussion I think mood has engaged in 
  that discussion so has Marcus but I don't think he's here today 
  so yeah if you've got thoughts concerns.
Manu Sporny:  Go ahead Mike you're on the queue.
Mike Varley:  Okay thanks folks can hear me awesome just wanted 
  to also mention that security has already implemented a similar 
  approach on our implementation of the VC API was more geared 
  towards multi-tenancy but when you register an endpoint you do 
  provide some of the parameters that you would want to support as.
Mike Varley:  When the API is called those parameters are applied 
  so I think this is approach an approach that secure key would be 
  interested in in fleshing out as described in the issue 267 and 
  we think I think we're aligned but you know we need to explore 
  further but it's something we're already looking at in that 
  entrust blog platform.
Manu Sporny:  Go ahead Dave.
Dave Longley:  Yeah this this new approach was also designed with 
  multi-tenancy in mind and it also shows some of these concerns 
  also came out of noticing that the existing approach does not 
  work very well for multi-tenancy you've got to try and mount what 
  the the existing API on to the end of some kind of other 
  configuration that allows for multi-tenancy and then you 
  immediately start running into these problems where clients are.
Dave Longley:   Are trying to ask.
Dave Longley:  Four things that they can't actually have or that 
  the issuer can actually do or that if the issuer did do could 
  create privacy problems just as one example that is listed in 
  that PR.
<orie> pretty sure clients can always ask for things that are not 
  supported... thats what http 400 is for.
<dave_longley> not a great client experience though :)
Manu Sporny:  All right thanks Dave um I'm gonna go ahead and 
  share my screen because the pr itself that we're looking at is 
  actually quite tiny but again I mean it opened up a huge kind of 
  discussion I think Dave with this PR you're just like remove the 
  verification method you shouldn't be able to set that it should 
  be kind of configured on the endpoint.
<orie> well its pretty good when the API documentation makes it 
  clear.
Manu Sporny:  And I think what Mike and Dave are saying is that 
  this is kind of the URL structure that they're expecting in this 
  did come up very early in the BC API discussions I think we said 
  hey look let's not say that this is hard coded that it has to be 
  at the root of your the root of viewer kind of URL path so the 
  root of your domain you should be able to tack the VC API onto 
  the end of stuff.
Manu Sporny:   And I think the use case that was brought.
Manu Sporny:  Had to do with multi-tenancy.
Dave Longley: 
  https://github.com/w3c-ccg/vc-api/issues/267#issuecomment-1055646254
<dave_longley> more comprehensive proposal ^ (but still rough)
Manu Sporny:  So I guess what conversation do we want to actually 
  have here do we want to just talk specifically about the pr or do 
  we want to talk about the issue that was created in talk about it 
  more broadly noting that like we should probably try to get to 
  like some kind of concrete action at the end of the discussion.
Manu Sporny:  On what people want to talk about.
Manu Sporny:  Go ahead and worry.
Orie Steele:  So I think the a couple things and then first we 
  support versions of this API with multi-tenancy already and I 
  agree with Dave that the current API definitions make that little 
  awkward and encourage clients to request things that might not be 
  supported so you'll have no I have no objection to the idea that 
  the API should be.
Orie Steele:  Refined to support multi-tenancy in a way that's a 
  little bit better than what it is today but I do think in this 
  particular poll request the primary concern is actually did 
  method and crypto sweet agility so I wanted to ask you know in a 
  multi-tenant sort of environment is the idea that an issue or is 
  only ever represented by one did method and one crypto sweet or 
  is it that.
Orie Steele:   An issue or as always.
Orie Steele:  Presented by one did method but multiple crypto 
  sweets just love to hear more thoughts around did method and 
  crypto sweet agility as they relate to the pull request thanks.
Manu Sporny:  Go ahead Dave.
Dave Longley:  So I haven't seen a lot of I'm open to from my 
  perspective I'm open to doing a number of ways but my proposal 
  would be to keep it as simple as possible which would be if we're 
  going if we're going to accept that the the party that's 
  configuring this issue or configuring these issuer instances in a 
  multi-tenancy scenario you would have many of these instances 
  that would be configured and in a non multi-tenant scenario you 
  might.
Dave Longley:  You might still configure more than one 
  configuration.
<orie> Hearing that issuer would support only 1 did method and 
  only 1 suite.
Dave Longley:  Fixed for an on-site install but the the idea that 
  we would have any one configuration support multiple sweets I 
  don't know what the advantage necessarily is there if we're going 
  to go to this model that allows multiple configurations to be 
  created so the idea here is that each configuration would be well 
  thought through only the authority needed to use the 
  configuration would be granted to to that particular instance so 
  the.
Dave Longley:   Oh the issuing.
Dave Longley:  Software would only have access to the keys that 
  it needs to have access to for example to issue VCS there's 
  there's an additional consideration in The Proposal added about 
  json-ld contexts because we didn't really cover anything with 
  that with previous VC API I think in the test in the test Suite 
  in the previous interop work we allowed any context to be loaded 
  off the web at any time and I don't think that's a very good 
  security model and we've talked about that at length.
Dave Longley:   Within the various w3c working groups so the.
Dave Longley:  Proposal I offered also included the ability to 
  into upload static contexts to these configurations that are 
  created so that you can only issue BCS from any one of these 
  configurations using well-known contexts that are static copies 
  so you don't have to worry about different versions of those 
  changing or you know any sort of attacks and related to that so I 
  think really the model.
Dave Longley:   Is with this new proposal.
Dave Longley:  Changing from let the client application do try to 
  pick any configuration some set of parameters instead of things 
  that I think might work and send that and see and hope for the 
  best hope that they get a thumbs up and on the other end have the 
  issuer sort of.
Dave Longley:  Decide that it did they make a number of decisions 
  around you know if the client has requested an ed to 5519 
  signature but the previous status revocation list was using RSA 
  what and I'm issuing a new credential what do I issue the new 
  status list under you know the issuer now has to make these 
  bizarre decisions around that and they might create problems for 
  the client applications that are using those issuers and so 
  there.
Dave Longley:   There are a bunch of these these these issues 
  that come up when.
Dave Longley:  Start saying well let's let's let the issuer 
  instances have lots of optionality and let the clients pick I 
  think it would be better to be deliberative and say this 
  configuration of this issue will do exactly this it will sign 
  with this did it will use any any did key that matches the sweet 
  because that's usually a requirement of a client application 
  that's a responsibility and requirement of a client application 
  to know these are the sweets I'm going to issue with because 
  that's acceptable for whatever the use cases but it doesn't need 
  to know the specific key that's.
Dave Longley:   My view anyway.
Dave Longley:  And that allows.
Dave Longley:  The issuer instance to be configured and updated 
  and have those keys be rotated as needed but maintain the 
  signature sweet that's expected and required by the client I 
  don't think having the client parameterize that is helpful and I 
  think it makes it a more complicated thing to implement it and 
  creates decisions that where there's not always a great answer in 
  during run time.
Manu Sporny:  Or you're really cute.
<bumblefudge> orie you're on the queue
<bumblefudge> but i think you're cute and on the queue.
<dave_longley> yeah, terminology isn't great here :)
Orie Steele:  Yeah I agree with everything you said Dave I guess 
  just to clarify you know what I'm hearing you say is you could 
  tell the server to create a new issuer and I think there's 
  problems with using the word issue or there because of the 
  conflation with the VC data model concept of this year but let's 
  say looking at your pull request here I asked for a new issue or 
  to be created and.
Orie Steele:  The issuer gets the idea it.
<manu_sporny> Fixed it.
Orie Steele:  And when I asked for the issuer to be created I 
  asked for it to support date web and E2 5519 that's that issuers 
  life from that point on and it if I wanted to use a new sweet I 
  would have to create a new issue or if I wanted to use a new did 
  I would have to create a new issuer is that consistent with what 
  you're saying.
Dave Longley:  Yeah that's the model that I think is easier to 
  understand and eliminates a lot of these decisions that are 
  fraught with problems it pushes decisions up front that can be 
  made at the time that you create the issuer so you can make some 
  saying decisions around what configurations make sense how to 
  make sure that the Privacy model makes sense for your revocation 
  lists and so on so yes to what you said.
<bumblefudge> maybe issuer SERVICE?
Manu Sporny:  All right I put myself on the Queue I'm wondering 
  I'm wondering if the word is sure this is just a tiny nitpick on 
  language but I think issuer might be misleading people it might 
  be better as instance we're talking about setting up instances 
  you know here with very specific configurations I think maybe 
  when people see issuer here they think like of a single subject 
  or a single entity.
Manu Sporny:   He liked one.
<dave_longley> "issuer instance" and "verifier instance" 
  terminology was used in the proposal i linked to
<bumblefudge> paging Joe
Manu Sporny:  City in that's probably not the right mental model 
  here I don't know how we make it better but I just wanted to make 
  sure that folks weren't getting wrapped around that particular 
  axle.
Orie Steele:  So one of the I think potential sort of problems 
  that related to this is the scheme is for requesting a credential 
  be issued so we're looking at the URL for the issuance and point 
  here but the post body has a schema and that schema is a 
  verifiable Prudential without a proof and some options and one of 
  the things that's difficult there is like does your post body 
  contain an.
Orie Steele:  You were right because if your.
Orie Steele:  As I you know I want you to issue a credential and 
  I want it to have an issuer block that's an object with type 
  organization corporate website blah blah blah then the issuer 
  endpoint needs to inject the issue or ID into that object or it 
  needs to throw an error and say sorry 400 error but the issuer 
  has to be a string and can't be an object so I think one of the 
  sort of key.
Orie Steele:   Things to consider around this is.
Orie Steele:  If an issue or instance or an instance of the issue 
  or API is configured for just one did and just one key associated 
  with it potentially when you're asking for a credential to be 
  issued what are the constraints on the schema that you're 
  submitting for that credential so like for example if you were to 
  include a status list in that credential object right then and 
  there you're going to already have a.
Orie Steele:  Blonde because what if.
Orie Steele:  Point two is under a different Suite so you need to 
  throw a 400 error if somebody asks for a credential to be issued 
  under any status list you probably need to throw a 400 error if 
  the client asked for any issuer to be present in that payload so 
  I was wondering Dave if you could just sort of speak to some of 
  the schema changes that would have to go along with this URL 
  change that you're proposing thanks.
Manu Sporny:  Mahmood you're on the Queue and then Dave.
Mahmoud Alkhraishi:  I think Dave answering first and then I 
  should go after.
Manu Sporny:  Go ahead Dave.
Dave Longley:  Yeah I agree that there might need to be schema 
  changes this to some extent this is not that different from what 
  we were doing before if if there are if there was an issue or 
  that you could not issue from before and you put that into the VC 
  and the payload and sent that to an issuer it would also still 
  need to be flagged and checked so I agree that there are schema 
  things that need to be changed and they might be more 
  specifically tailored to a particular.
<orie> yes, we throw a lot of 400 errors today.
Dave Longley:  To some extent that's not that different from 
  what's Happening Now but there would potentially be some some 
  differences certainly if you had posted a credential status to 
  the existing API today and that was not supported by the issue on 
  the other side you would still be in the same situation you that 
  would have to be dealt with so I see that it is an issue that 
  needs to be addressed but I don't I see it as somewhat orthogonal 
  to the to the issue of sort of doing configuration first.
Manu Sporny:  All right thanks in Mahmood you're next.
Manu Sporny:  Yep you are here and you want to go to the bottom 
  your comment.
Mahmoud Alkhraishi:  Would you mind going back to the pr the 
  there were three points that they have you made it sort of your 
  argument right the first one basically is if you need to rotate 
  Keys then under the current model you to notify everybody that 
  originally was rotated the second model is if you have a 
  credential of one sweet type.
Mahmoud Alkhraishi:   And their vacation is have a different 
  Suite.
Mahmoud Alkhraishi:  Then you will run into problems with issuing 
  the revocation list and every time your new one will be an issue 
  and the last one is the key the fact that this whole idea should 
  have been done by the shore in the first place around the client 
  having to figure that out right is that really what you're 
  saying.
Dave Longley:  Yes that's right.
Mahmoud Alkhraishi:  So my first question is can't this have just 
  been solved by extracting out the requirement for including a key 
  in the current request additional credentials so if we remove if 
  we instead say if so sorry man you can go all the way down to the 
  to my comment.
<orie> yes, verificationMethod is optional today.
Mahmoud Alkhraishi:  So in the existing one that we have right 
  now which is the first liquid that we have we say the 
  verification method is this D ID and then it has this key behind 
  right and that is an optional request if we remove that instead 
  we say we would like you to issue a potential of this type from 
  this D ID and then the idea that you're using would be resolved.
Mahmoud Alkhraishi:   And you'd find out which key and here's 
  that type of.
<orie> this removing an optional field, and implying that the key 
  will be set by the server.
Mahmoud Alkhraishi:  Just issue it that way you would solve the 
  rotate kids problem completely is that an accurate statement or.
Dave Longley:  Yeah I do have more to say in responsive when 
  you're ready.
Mahmoud Alkhraishi:  So my question is I think your biggest 
  response to this on from what I've seen from what you've written 
  is basically we don't even need to go there in the first place 
  instead of just if we do it by the config it would be better I 
  just don't I don't know where or why is it better than than what 
  is currently here that's basically right.
Dave Longley:  Sure and that makes a lot of sense so some of this 
  sort of speaks to two or he's complaint with my with my original 
  approach here which was my original approach was to point out you 
  know if we just remove verification method we can solve some of 
  these problems and I think Corey was responding and thinking well 
  if you're going to start there there might be other problems and 
  if we go down the path of trying to pick the solving each one of 
  these one at a time and take the shotgun approach its it could be 
  problematic.
Dave Longley:   And you know we're going to spin our Wheels a lot 
  trying to solve.
Dave Longley:  A lot of little.
Dave Longley:  And either we would end up with even more problems 
  with the solve eventually or will just wind up somewhere where we 
  could have started from and the main point is we've got some kind 
  of design flow here where we're going in the wrong direction 
  where hat where we have the responsibilities mixed up we're 
  having the client be responsible for things that the client 
  shouldn't be responsible for and if we turn that on its head and 
  say the parties that are setting up and configuring these issues 
  with the parties that know.
Dave Longley:   Know how to make these decisions.
Dave Longley:  What configurations are wholesome and sort of work 
  together then they can make those configurations available that 
  doesn't mean that you know they wouldn't be working in concert 
  with particular Client app providers so you know or whoever 
  depending on the use case to say you know we want to make sure we 
  have a configuration that has this signature sweet for example 
  but the authority is is flows from the party that has access to 
  the Keys and then has access to.
Dave Longley:  That they can provide for revocation and so on and 
  so forth and those configuration should be determined by those 
  parties and made available to client applications and if we if we 
  flip it on its head and go in that direction we will avoid the 
  problems that are raised in this PR and additional problems that 
  have not necessarily been raised directly in any other PR but 
  stem from the same sort of inversion of responsibilities issue 
  that we have.
Dave Longley:   Where the client does not have the knowledge 
  that.
Dave Longley:  Able to make these decisions around what 
  configurations are available because the authority doesn't flow 
  from the client it's the party that has access to the Keys and 
  can say this is what I can issue these are the sweets I can issue 
  from and so on it flows in the other direction.
Manu Sporny:  All right thanks Dave Mahmoud I think that might be 
  an old Q is that right.
Mahmoud Alkhraishi:  Yeah check that out think I'm okay.
<orie> if we are gonna cut, we should try and cut holistically 
  towards a shared vision.
Manu Sporny:  So I guess the I mean I understand the concept 
  right I guess the question is where does where's the line where 
  does it how do you reconcile things that the client asked for and 
  things that are kind of hard configurations on the server so for 
  example let's say revocation list right so when you ask for a 
  credential to be issued.
Manu Sporny:  You're like no no I'm managing the revocation stuff 
  over somewhere else and I'm going to I'm going to specifically 
  State you know the that I want to use revocation list 2020 or you 
  know 2021 I guess what we're saying is that if that is configured 
  server side there's an option there that says allow the client to 
  override or never allow the client to override and always use 
  like status.
Manu Sporny:   List 20 21.
Manu Sporny:  Is is that what we're saying because they're all 
  these different options that could potentially be mix-ins and I 
  think what we're saying is like know that issuers got to set a 
  whole bunch of defaults and then the issuer the person 
  configuring the issuer instance has to set a whole bunch of 
  defaults in they may allow those defaults to be overwritten or 
  they may not.
Manu Sporny:  The mix and stuff work that's it.
Manu Sporny:  Go ahead Ori.
Orie Steele:  So I'm going to try and answer the question I think 
  for this to be successful the schema for the payload the post 
  body becomes much more strict it says you know hey you know 
  credential status it can't be present because that's going to be 
  set by the server so like don't you could you might say hey if 
  you are like sometimes I ask for credentials with revocation and 
  sometimes they don't so credential status as an option I think 
  it's fine.
Orie Steele:  Actual post body credential status would be 
  forbidden because the server is going to provide that value like 
  their server is going to provide the issuance date and the server 
  is going to provide the issuer should the client be able to ask 
  for a backdated issue and state maybe but I think the point being 
  that if you take this approach the schema for the post body 
  becomes much more restrictive you throw a lot of a lot more 400 
  errors saying hey.
Orie Steele:   Client you know servers already going to handle.
Orie Steele:  Parameter like you're not allowed to specify it and 
  that's everything becomes a lot clearer so I think it it is a.
Orie Steele:  Valid direction to take the API but it does sort of 
  change the world view a little bit to the server sort of being 
  the authority and the client not being able to really ask for 
  anything other than what the server is going to going to accept 
  and I think it's a valid path forward but we should make sure 
  that we're communicating Our intention to implement that shared 
  Vision very explicitly and we're taking.
Orie Steele:   You know a group of features.
Orie Steele:  It take us that direction at once if we can just so 
  that we get there a little bit faster and so everyone knows like 
  this is a fork in the road and design principles like we're now 
  going the direction of the server is going to be responsible for 
  this configuration the client is not going to be allowed to ask 
  for any form of optionality the clients going to accept what the 
  server will give.
Dave Longley: +1 To Orie
Manu Sporny:  Okay that's helpful at least it was helpful to me 
  Mahmoud Europe.
Mike Varley: +1 To Orie's comments on making the input schema 
  more strict.
Mahmoud Alkhraishi:  I think what I got from reading the issue is 
  that when I think there's a missing endpoint which is a get on 
  trying to find out what are all the issue where's that are 
  available somewhere here so that I can know if I want to issue a 
  credential of a specific the ID which endpoint on my calling in 
  the first place but I feel like that's you know that's a very 
  straightforward fix right but what I'm trying to understand is.
Mahmoud Alkhraishi:  Server says there are four possible valid 
  configurations and only four possible about configurations if you 
  want a credential issued by me these configurations are for 
  example eat 519 2018 with a revocation of 2020 or a is 509 2020 
  with a revocation list 2020 and that's it we don't support other 
  stuff right and the and then obviously there's a way for you to 
  ask the issuer from what I'm seeing in your proposal to add in.
Mahmoud Alkhraishi:   Another configuration object that's the 
  rough.
Mahmoud Alkhraishi:  Only hope is internalizing that correct 
  first of all.
Dave Longley:  Yes I think so.
Mahmoud Alkhraishi:  Okay so I'm failing to see how.
Mahmoud Alkhraishi:  How a client is able to find out that it's 
  supposed to call this and point to get that credential that like 
  I'm trying to for example I want to issue a revocable credential 
  with a with a specific key type with a specific from a specific 
  the ID if I had if I support like for did methods doing it a 
  different issue or end point for each one and then do I need a 
  different revocation list.
Mahmoud Alkhraishi:  For you like it feels like now.
Mahmoud Alkhraishi:  I've gotten more issue and points than I had 
  in the beginning.
Mahmoud Alkhraishi:  That's really where my confusions.
<orie> you can't ask for a specific did or quite... you can only 
  as a specific endpoint for a credential.
<orie> suite*
Dave Longley:  Yeah so the quick answer is yes you do have more 
  configuration and points than you did in the beginning you have 
  one for each type of configuration that the client applicate that 
  the issuer wants to support in that the client application needs 
  to use and and this some of your questions seem to to remind me 
  of the just some of the discussions we've had around Discovery 
  very often we said you know how our clients going to discover 
  these things that they need to do it's actually and what we found 
  in a lot of those scenarios is.
Dave Longley:   The client is going to be told.
Dave Longley:  Action so a lot of these use cases are you're 
  going to go through some setup bootstrapping process where you 
  can configure an issuer URL is going to pop out and you going to 
  take that URL and put it in your client and that's going to be 
  end of the story as opposed to a client that rent is randomly 
  showing up at some issuing and point and is asking some questions 
  about what it can issue and what it can that doesn't make sense 
  because the problem I'm going to have the authority to do that 
  the clients going to be specifically provisioned and given 
  Authority through either.
Dave Longley:   Are you off to or Z Caps or whatever 
  authorization mechanism is being handed to that client to be able 
  to.
<orie> hmm -1 to most of this attempt to avoid discovery
<orie> you still need to address it
Dave Longley:  Civic issuing endpoint so it's going to have that 
  knowledge through the process of being on boarded and so I don't 
  know that we even need to have any sort of Discovery mechanism 
  because I think the use cases are such that you need to get that 
  Authority and then you going to be told where to go use it and I 
  think that answers your question so I'll let other people in the 
  cute.
Manu Sporny:  All right I put myself on the Queue to try and get 
  us to drive towards a concrete kind of outcome here one thing 
  that I think could potentially work is a PR explaining this new 
  philosophy and a bit more depth so not necessarily changing a 
  mean it could change API endpoints but as as we saw you know this 
  tiny little change has kicked off a pretty big kind of 
  philosophical Direction.
<mahmoud_alkhraishi> the issue has really in-depth stuff i just 
  didnt go through it before this call
<orie> pretty sure I am the only person who reviewed the PR... so 
  I don't know that we need to ask for anything but more reviews.
Manu Sporny:  And so I think we probably need some text in here 
  to explain that these endpoints do have configurations associated 
  with them and they do X and Y and you know the Dynamics between 
  the client and the server needs to be written down so I'm 
  suggesting that as a next next concrete Next Step here or you're 
  on the queue.
Orie Steele:  So I think it's fine to to continue to iterate on 
  this PR and like Dave has given answers in issues I think you 
  know folks should review the pull request and we could can make 
  incremental progress or we can make you know we could push a 
  design document and then try and change the apis I'm fine 
  incrementally changing things as long as I know where they're 
  headed.
Orie Steele:  Modifying my change request to more specific issues 
  that I think aligned with Dave's Vision the point I'd like to 
  make about the discovery thing is you can't get away from 
  discovering the features an issue or supports so if a client 
  wants to ask the server hey issue or one two three what did 
  method is that going to use what sweet is it going to use it 
  shouldn't have to ask for a credential to learn the answer you.
Orie Steele:   I'd be able to learn.
Dave Longley: +1 To Orie, that's discovery at a different layer 
  (i think)
Orie Steele:  From asking the API what did method does issuer 123 
  support and what sweet might it support does it support 
  revocation does it not so this idea that like somehow will avoid 
  Discovery by configuring clients it's it's definitely not going 
  to work like we will have to make get and points and add them to 
  these apis we can't just have it be a collection of post and 
  points that's not a good API design but.
Orie Steele:   Plus one to the idea.
Orie Steele:  You know that maybe Discovery is sort of more 
  resource oriented like which fig configuration does this 
  particular instance resource support and and that that makes like 
  a lot of sense and that's why I like I think it's really helpful 
  at Davis done you know he's explained yes you know I want to take 
  you know I want to chip away at these issues but I also have kind 
  of a boring grander vision for major structural changes to the 
  API and.
Orie Steele:   And you know with that being said I think folks.
Orie Steele:  All requests and they can request changes or 
  approve 8 based on what it's got and what Dave has communicated.
Manu Sporny:  Thanks Horry I'm gonna let's timebox this at my 
  mood and then move on to the next issue just so we can get this 
  other idea in people's heads as well Joe you're up.
Joe Andrieu:  Yeah I think you can hear me okay couple things I 
  think I think we're sometimes talking past each other because 
  we're we stopped using the language of apps relative to the 
  services often when I hear people talk about clients and the need 
  for discovery that to me speaks to the end user who is trying to 
  get the credentials issued they don't have any appropriate role.
Joe Andrieu:  An app controller who is trying to integrate their 
  app with a service wanting to know for a particular configured 
  and point what's the configuration of that so when Orie reframe 
  Discovery in that context that that made sense to me but for that 
  end user in the clients I just keep getting wrapped up in 
  Discovery language when you talk about the client and the way 
  that we haven't.
Joe Andrieu:   That's it.
Manu Sporny:  Thanks Joe I'm going to Europe.
Mahmoud Alkhraishi:  I think my question was basically one I 
  agree with the big picture vision of we absolutely need to agree 
  on a lot of the things here and I'm happy to like have that 
  discussion as we go but there is a question of a very very quick 
  win when it comes to the key rotations and it's just removed the 
  requirement in the my Venture for textual hard requirement right 
  now if the revocation method has a requirement on the key.
Mahmoud Alkhraishi:   But I feel like it shouldn't specify which 
  kid.
Mahmoud Alkhraishi:  First place if you would just ask issue 
  something from this D ID instead that we have the you know very 
  straightforward and I don't think would be big like will see a 
  lot of objections when that we can have keeping in mind that 
  there's a much bigger picture here about you know all the rest of 
  it needs to be.
Orie Steele: -1 To trading vm for did
<orie> not useful
Manu Sporny: -1 To trading VM for DID :)
<manu_sporny> Feel like it's a stop-gap and still "wrong" in some 
  way.
<orie> agreed
Dave Longley:  II do agree that we could one-by-one start 
  shipping these options out and start with the one that was 
  mentioned but it you know there are other approaches people have 
  mentioned I do I got on the cute though to respond to Horry and 
  Joe I agree that we're there's some miscommunication around what 
  the meaning of Discovery is and once or he started talking about 
  finding out the configuration information from a particular.
Dave Longley:   URL you already know about I completely agree 
  with Oreo.
Dave Longley:  That is not what I meant by Discovery I meant 
  having to discover these URLs that you were supposed to have 
  access to in the first place but being able to find out from a 
  URL that from a particular configuration what is your 
  configuration tell me you know tell me the information about this 
  URL I completely agree that you should be able to do that.
<orie> OIDC does discovery very well :)
Manu Sporny:  All right um noting that we only have 15 minutes 
  left in the coal go ahead Mahmud I'm going to move us on to the 
  next issue my my assumption here is that someone Dave you're 
  going to write up some thoughts on that we can add to the spec on 
  this.
<orie> dave just implement my change suggestions and I will 
  approve your PR :)
Dave Longley:  I'm just a jump cue real quick maybe I don't I 
  don't know I don't know where to add that or what would be that 
  part I was a little confused about going in the direction of 
  chipping away or changing the API to some making some statement 
  somewhere.
<orie> don't bother writing anything other than PRs or issues :0
<orie> ; )
Mahmoud Alkhraishi:  I think I'm going to jump back in here I 
  think the issue that you made had a very very like I didn't have 
  a hose on it but it was a pretty clear proposal where we want to 
  go and I think what we need next is reactions to that issue right 
  where people respond to it because I think there's a Clear Vision 
  there.
Dave Longley:  Okay I'm also seeing a chat or he just wants his 
  change I'll look at his change suggestion and we'll work through 
  it there.
Manu Sporny:  Okay all right moving on to the next topic so.
Mahmoud Alkhraishi: +1
Manu Sporny:  Let's see so at a minimum we'll see if Dave you can 
  address or ease concerns and if so then we can modify the pr 
  Mahmud I'd be interested in seeing you know what you think of the 
  modification and then we may want to further document kind of 
  some of the design philosophy around configuration for endpoints 
  and Discovery there was some good stuff said on the call today 
  all right.
Manu Sporny:   Well our next.

Topic: Exchange discovery

Manu Sporny: https://github.com/w3c-ccg/vc-api/pull/268
Manu Sporny:  Is about Discovery exchange Discovery Mike Varley 
  wrote up PR 268 so that's in chat here and I'll bring it up here 
  Mike would you like to give us kind of a quick intro to this PR.
Mike Varley:  Sure so this PR was requested based on the 
  exchanges Discovery where the VC API supports workflows or 
  exchanges and there was some language in that proposal around 
  exchanges that.
Mike Varley:  Did that exchanges could accept a wide variety of 
  input parameters and and output VPR responses which could lead to 
  other protocols and I was concerned that that kind of approach 
  might make it difficult for software clients trying to.
Mike Varley:   A great to the API.
Mike Varley:  And you know what what protocol am I supposed to 
  speak to this exchange with there's input parameters expected how 
  do I know what those are and so on so this PR is a get on the 
  exchanges and point which returns a map of the pathnames 
  essentially and and then a.
Mike Varley:  The Kate's you know a spec that that endpoint is 
  going to utilize its deliberately probably over simplified it's 
  it's very direct and sort of its intention that's to sort of 
  spurn spurned discussion and see where we want to put guard rails 
  on this or or maybe if we even need it the.
Mike Varley:  Point is also that I was not constrained to just 
  VPR related protocols but also you know is there room to indicate 
  that this endpoint uses something like presentation exchange or 
  is there an open ID connect relationship or or you know just an 
  open the spec lives in in a custom defined yambol file and you're 
  expected to go and.
Mike Varley:   Stand the client has.
Mike Varley:  Already sort of understand what that protocol is so 
  this discovery and point is for the client to call understand for 
  this exchange endpoint what is the protocol that I will be using 
  and do I recognize that string in order to fulfill that 
  communication if it if the client does not recognize that string 
  then it can handle that with with the end user saying okay I'm 
  sorry you know this issue actually I'm not compatible with in 
  some way.
Mike Varley:  And and to Joe's point from a developer point of 
  view it can also be useful for you know if I'm going to be 
  building a client and I want to interact with an issuer system 
  that's using this API well I can call the exchanges and point see 
  what the protocol specification is and then code against it and 
  then there's less maybe fewer touch points with the actual owner 
  of the issuer service API on on how their exchanges work.
Mike Varley:  I think that captures it.
Manu Sporny:  Great thanks Mike Joe Europe.
Joe Andrieu:  Yeah my question for you might is is this exchanges 
  family of routes which component is it on is this on the issuer 
  app or the issue or service or my misunderstanding something.
Manu Sporny:  I can I can answer that so it's it can be on 
  anything so you and exchanges can be on an issue or app a 
  verifier app or a holder app it just is a general way to kick off 
  you know presentation exchange like exchanges or just you know 
  presentation exchanging.
Manu Sporny:  Presentation back the sides of things did that 
  answer your question Joe or were you asking a different question.
Joe Andrieu:  I'm if I maybe it was it's one of the apps but not 
  the services.
Manu Sporny:  Correct I believe yeah I believe that's correct 
  Joe.
Mike Varley:  Man I would agree yeah I think it's on the app 
  side.
Joe Andrieu:  Okay cool I think part of my is just figuring out 
  how we start to integrate that terminology into our docks because 
  I don't think we've fully gotten that language in.
Manu Sporny:  Let's seize on the Queue keeps debut on the Queue 
  go ahead.
Dave Longley:  Yeah I was going to say there's there's there's 
  more analogies here to draw with the previous conversation we had 
  and we might want to start talking some of that previous 
  conversation was about there's just going to be State associated 
  with these issuers and verifier instances you know we need to 
  figure out our naming terminal to terminology are but there's 
  some State you know like you need to store contexts we need to 
  store act the capability to use certain keys and we might have 
  the same thing going on here with exchangers or.
Dave Longley:   Or exchange instances.
Dave Longley:  We need some term here where you would create one 
  of these configurations this exchanger thing and upload a set of 
  steps with combinations of vpr's or whatever and in the in the 
  expected in some kind of expected schemas for what gets posted 
  back in response to these things and so we might want to be able 
  to create these instances in the same way that we're talking 
  about creating instances of verifiers and an issuer's so the 
  same.
Dave Longley:   I might apply here.
Dave Longley:  And we could we could potentially reuse that.
<orie> how restful...everything is a resource.
Manu Sporny:  What's the wonder that I did have a couple of 
  comments on this Mike I don't know I don't know how relevant they 
  are because I can't remember what I said.
Manu Sporny:  Um some of this stuff look like it kind of mapped 
  so there's some part of this that maps to VPR right so VPR tells 
  you here ways that you can interact so verifiable presentation 
  the VP requests back has this interact.
Manu Sporny:  Part right to the map inspired interact thing where 
  it says here's the protocol that you talk to and here's the 
  endpoint right in these are typically exchange endpoints or they 
  can be viewed as exchange and points but this is just in the BP 
  R-Spec I think Mike what you're saying is bring it a layer up to 
  the BC API spec and put that directly on exchanges and Dave 
  saying well maybe we can you know Express this configuration.
Manu Sporny:   Duration information in the same way across.
Manu Sporny:  Issuer instances and exchanger instances and 
  verifier instances and in that kind of thing so I think there's 
  the other the other thing of course is that the did spec has this 
  service you know container thing that we could that we should 
  also think about so they so this is this kind of thing is 
  happening in at least three different specs already and we should 
  just be aware of that.
<bumblefudge> service block wildly divergent across specs tho :(
Manu Sporny:  You think that's it the other the other question I 
  had Mike was that when I started trying to think about the use 
  case.
<bumblefudge> sometimes a string, sometimes a huge object, 
  sometimes an exactly-two-prop object...
<orie> yeah, many did methods do not support service blocks
<bumblefudge> also
<orie> a major reason to use did:web !
Manu Sporny:  I couldn't think about where this fits in like I 
  don't understand and I'm not trying to be like you note right 
  here the I don't understand the use case my expectation was that 
  at least with the VP are sorry with let's let's look at 
  credential refresh the discovery for the endpoint that you go and 
  do a credential Refresh on at least in the VC refresh 2021 Speck 
  that is in the VC itself so you do Discovery through the Visa.
Manu Sporny:  I'm wondering what the use case here is do people 
  just randomly hit the exchanges endpoint and then they're then 
  then they get to see like information about credentials that they 
  could get is that the use case here.
<bumblefudge> sounds like a credential manifest use-case 😉
<bumblefudge> (ducks)
Mike Varley:  Yeah okay so for to your first question around 
  structure I think that there are options on structure I'm not 
  married to to the current you know proposal so if you wanted to 
  add in some json-ld context or whatever and and create a 
  structure instead of string you know we'd be open to that the 
  intention though is not to have the specification as part of the 
  discovery it is it is meant to say on this.
Mike Varley:  End point I am going you know this.
<dave_longley> (these service blocks, for example ... are not in 
  DID docs, so +1)
Mike Varley:  Used it to string you should recognize that and and 
  then that's how you know that your communication with this 
  endpoint is is going to is going to be successful other other 
  other you know if we put I'm worried that if we try to put too 
  much of this spec into the discovery then your client has to 
  become very clever in parsing all of that and deciding what to do 
  so anyway like I said it's kind of deliberately simple and like 
  try and keep.
Mike Varley:   With that approach.
Mike Varley:  As for the use case what really I guess inspired me 
  to to address the discovery issue was on the pr for exchanges 
  there's this disrespect allows for any Json object to be provided 
  as input parameters and then that results in a thinking of epr 
  and and it was digital as ours.
Mike Varley:  That you know they may have or they will you do 
  have use cases where input parameters are required just in order 
  to kick off the flow and men and maybe you can talk about that 
  that use case my concern is that as a client if I'm going to you 
  know whatever the name of that end point is if it has a generic 
  name if I'm if I'm expected to add additional parameters to this 
  exchange and point which I thought was for credential refresh but 
  now says I can't deal with you because you actually.
Mike Varley:   Should have provided me with.
Mike Varley:  Some input parameters before we started credential 
  refresh then you can have clients in the wild which which think 
  they're going to be able to work and they and they and they 
  contact a credential refresh in point and then suddenly they 
  don't so you know what the client supposed to do in that in that 
  scenario so that's that's the area in front of address if the we 
  want to have some flexibility in terms of how exchanges get 
  kicked off or.
Mike Varley:   Or how or the protocols used on those.
Mike Varley:  I think I feel strongly that the client should be 
  able to at least find out what is necessary for that 
  communication to be successful before actually kicking it off and 
  so that's that's the use case.
<orie> no free lunch clients should be able to discover how to 
  make valid requests and avoid needing to trigger 400's to learn
Manu Sporny:  Okay great thanks Mike and with that we are at the 
  top of the hour thank you everyone that was a great discussion 
  today I think the next step on this one I think is more 
  discussion Mike on the on the pr in maybe if someone could take a 
  cut at a unified way of expressing these configuration on these 
  end points like we are you know instance configuration for issue.
Manu Sporny:   Sure and verifier it may be.
<bumblefudge> thx all
Manu Sporny:  That might help us think through this you know in a 
  more kind of unified way okay that's it for the call today thanks 
  to turn everyone see you in PRS and issues have a good one bye.
Received on Tuesday, 1 March 2022 22:22:49 UTC

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