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

[MINUTES] W3C CCG Verifiable Credentials API Call - 2022-02-08

From: CCG Minutes Bot <minutes@w3c-ccg.org>
Date: Wed, 09 Feb 2022 22:13:54 +0000
Message-ID: <E1nHvDh-0001SV-Pg@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-02-08-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-02-08-vcapi/audio.ogg

----------------------------------------------------------------
VC API Task Force Transcript for 2022-02-08

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0027.html
Topics:
  1. Introductions and Community Updates
  2. VC API - Workflow-Holder Convergence
  3. Controller-style Endpoint Pattern
  4. Workflow IDs and names
Organizer:
  Manu Sporny, Orie Steele, Markus Sabadello, Mike Varley, Mahmoud Alkhraishi
Scribe:
  Our Robot Overlords
Present:
  Manu Sporny, Mahmoud Alkhraishi, TallTed // Ted Thibodeau 
  (he/him) (OpenLinkSw.com), Justin Richer, Brian Richter, Mike 
  Prorock, Adrian Gropper, Dmitri Zagidulin, Kayode Ezike, Mike 
  Varley, Troy Ronda, mike.varley, Kerri Lemoie, Orie Steele, 
  Markus Sabadello, Eric Schuh, TallTed // Ted Thibodeau Jr (via 
  iPhone), Kaliya Young

Our Robot Overlords are scribing.
Manu Sporny:  All right welcome everyone this is February 8 2022 
  this is the verifiable credentials API call let me get our agenda 
  in here.
Manu Sporny:  So our today on our agenda is just this agenda 
  review introductions and any relevant Community updates the next 
  item up is a continuation of our discussion last week which is 
  the VC API trying to converge on the workflow and hold your 
  presentation proposals and then if we have time that's expected 
  to be the majority of the call.
Manu Sporny:  We will spend the remainder on issue processing 
  specifically the controller style endpoint pattern we've been 
  using and if that was bad idea or not or if we want to change it 
  and then workflow IDs and names and anything else that comes up 
  is there anything else that folks would like to cover today on 
  the call.

Topic: Introductions and Community Updates

Manu Sporny:  Okay if not introductions and reintroductions do we 
  have anyone new on the call today I know that at least coyote 
  Troy you guys haven't been here for a while would you mind doing 
  a quick re intro.
Kayode Ezike:  Sure thanks man oh yeah my name is Kyle Diaz EK I 
  have kind of been in this space for maybe two three years now I 
  first kind of got my foray into it the worked out doing with 
  solid while I was in school and then recently started to work on 
  as a species are to support the DCC know what they're doing 
  alongside Dimitri and others and been involved with VCs... 
  thought I'd see that we're doing here and so I figured it would 
  be good to keep abreast with the developments here can promise 
  that I'll be able to take all of these but I'll try my best to 
  and also to follow the issues that are submitted so that's a bit 
  here thinking.
Manu Sporny:  Wonderful welcome as always wonderful to have you 
  here... Troy, you're up.
<dmitri_z> really great to have you here, Kayode!
Troy Ronda:  Yeah I'll just be quick my name is Troy Ronda I work 
  at secure key I lead one of our development teams working on our 
  platform called trust block dealing with verifiable credentials 
  and decentralized identifiers.
<kayode_ezike> thanks for the warm welcome!
Manu Sporny:  Wonderful and welcome always always great to have 
  you here next up our community updates any updates that the 
  community should know about be aware of anything of that nature.
Manu Sporny:  All right I don't have anything for today.
Manu Sporny:  Go ahead and jump into the main topic then.

Topic: VC API - Workflow-Holder Convergence

Manu Sporny: https://github.com/w3c-ccg/vc-api/pull/258
Manu Sporny:  So the topics VC API workflow and holder 
  convergence we have had a pull request out for about a week now 
  that has been getting a decent amount of discussion and I think 
  we're going to try and do today is spend the majority of the call 
  trying to converge on what needs to be changed what we can merge 
  things of that nature with this PR.
Manu Sporny:  Let me kind of do a quick intro to the pr on the 
  last VC API call there was a desire to try and converge the 
  workflow proposal that was in the spec with the presentation 
  exchange flows that have been in there for a while the 
  traceability folks have been using the presentation exchange 
  flows for the traceability work there is a desire to use some.
Manu Sporny:  Points just converts them into two so that we can 
  so one the traceability folks can continue to use those those 
  apis the same shape of those apis for their use cases but we also 
  are in able to do things like credential refresh in other kind of 
  flows through a a converged API so the purpose of the pr is to 
  merge these two kind of approaches which are very close.
Manu Sporny:   Those one of them is a superset of the.
Manu Sporny:  Into one thing so that we can all you know have 
  basically two end points that we can run all of these 
  interactions off of one of the big things that we mentioned last 
  week was the language around it's probably wrong and we want to 
  use the word exchanges that was suggested by Joe so that wording 
  has gone in there there was a.
Manu Sporny:  I believe micro Croc and my mood that we use you 
  know transaction identifiers and exchange identifier so that has 
  been put in there as well in in there's been a lot of lot of 
  review over the past couple of days there are some misalignments 
  and disagreements still and so I think what we're going to try 
  and do on the call is figure out.
Manu Sporny:   What needs to change.
Manu Sporny:  Are or what needs to come out of the pr for it to 
  be merged let me pause here and see if Mike might pee my mood or 
  or t if y'all want to provide any analysis on the pr before we 
  kind of dive into it.
Mike Prorock:  I can go first and then hand the ball to Horry the 
  I think this is a great in the right direction one and I think 
  there's a lot in there like things like error handling and stuff 
  that we know we already kind of one in across the board so 
  there's stuff like that that I think we could kind of almost take 
  in as is and I think I've noticed that some of the stuff there 
  seems to be broad agreement on in the pr there are still some.
Mike Prorock:  Areas for improvement though right.
Mike Prorock:  For extension so I think if we can get it to where 
  hey here's this common stuff we're ready to go pull in and then 
  you know either myself or someone else can go in and you know 
  issue a second PR to then start hashing out some of the details 
  on some of the other things might you know might be a good path 
  I'm not sure orry I know you've got some direct thoughts you know 
  probably more.
Mike Prorock:  Or is your audio can.
Orie Steele:  All right take me a second to find the browser that 
  I never use make a Firefox I think at this point the fastest most 
  effective way of moving forward would be to merge the pr with its 
  current problems and to have either Mike or mood do a follow-up 
  PR that addresses their specific concerns it seems like we're 
  sort of asking Manu to.
Orie Steele:  What exactly your meaning which he's doing his best 
  at but I'm probably faster if you guys just did a follow up here 
  that would be my recommendation.
Manu Sporny:  I mean I'm good with that Ori my concern was that 
  there was I think your biggest concern was this transaction ID 
  thing or transaction uuid thing I just want to make sure that you 
  don't have like it's okay so let me try and summarize what I 
  think is being suggested so or you're saying just murders the 
  whole thing in Mike you are saying Hey I want.
Manu Sporny:  Let me let me let me.
Manu Sporny: 
  https://github.com/w3c-ccg/vc-api/pull/258/files#r801639710
Manu Sporny:  Fleet of the comments so that other people can see 
  it.
<orie> the current endpoints are broken, but Mike et al can 
  probably fix them faster.
Manu Sporny:  If everyone goes to that link there so Mike you're 
  saying I want the post on Exchange ID transaction uuid to be 
  changed to a point and so I totally get that I can do that in 
  this PR but then Mike you're saying I also want gets to exchange 
  ID / transaction ID and delete.
Mike Prorock:  Yeah I get it in this and actually I think this is 
  worth while speaking about a little bit because I think there may 
  have been just for communications and reading through comments 
  and stuff I think there may be some misunderstandings at least in 
  the while I was looking at this so what I look at like as a path 
  that is an exchanges collection right a collection of exchanges / 
  some type of thing.
Mike Prorock:  Flash than the actual entity that's being.
Mike Prorock:  For to that.
Mike Prorock:  Of key that type of exchange was key in my mind 
  right that I want to go initiate some you know type of exchange 
  around like a reef a credential refresh or a past this a lot this 
  data along someone else or start some kind of a defined flow 
  based on an ID and then the individual elements of that would be 
  referenced by that transaction uid and so that was in my brain 
  the way things were going and I'm not sure that came across.
Mike Prorock:   Ross fully there.
Mike Prorock:  Like if we want to go create an exchange of some 
  type we would do that with a post we may not need that second ID 
  there though depending on how we do this right so and so but 
  basically as a rule of thumb like we're going to want to post if 
  we're creating it and if we're specifying the type of thing 
  that's going to create it we probably want to do that in the URI 
  as well as in the body right and so that was my comment in there 
  that I think you linked to but then if you're updating a.
Mike Prorock:  An absurd or.
Mike Prorock:  Also you have an own ID that's where the put comes 
  into play those kind of implied that you may want to once again 
  write like request to get her off of this right it is this some 
  stateful thing that's being stored on the server and or not and 
  or delete it and that's where you get into things like gets and 
  deletes by an ID right or or to get all types of exchanges 
  matching some known pattern right.
Mike Prorock:   One other note of.
Mike Prorock:  Is that my little edit to note about putting the 
  query in the path like I'm totally good with putting aquarium 
  path like I'm actually a fan of that some folks do like to try to 
  put queries in bodies but I what I'm doing gets I generally like 
  a get does not necessarily imply a body to me right and back 
  usually doesn't imply some kind of request body so that's just 
  philosophically how I think about that stuff and we look at other 
  apis that deal with some kinds of State.
Mike Prorock:   A full data that tends to be a pattern that we 
  see.
Justin Richer: +1
<justin_richer> +q rather
Manu Sporny:  Got it Dimitri Europe.
<brian_richter> I'm confused why transaction id is transaction 
  uuid throughout the PR. even in this discussion it has been 
  called transaction id. can it be id instead of uuid?
Dmitri Zagidulin:  But I wanted to clarify is is transaction ID 
  required.
Dmitri Zagidulin:  Or to put it another way is it possible to 
  use.
Dmitri Zagidulin:  For client to use.
Dmitri Zagidulin:  The Exchange ID and point I would know another 
  action.
Manu Sporny:  It's a good question Justin I think you're up is 
  that you rather.
Justin Richer:  I yes so I just wanted to make a quick point for 
  those that don't that are following it the HTTP working group is 
  actually currently working on a new definition for a new verb 
  type which would be a get with a message body because get does 
  not have a message entity body as per HTTP it.
Mike Prorock: +1 Justin - that is a good note - it is not defined 
  yet
<manu_sporny> Finally! (might be terrible, but it's come up so 
  many times)
<mprorock> but we should be aware of
Justin Richer:  So that is something to consider when when 
  looking at the application of put and post to do get like 
  operations this is a known limitation of HTTP and it's something 
  that this as a new API might want to you know earmark for for 
  future use and compare compatibility and potentially join the.
Justin Richer:  Join the conversation in the HTTP working group 
  the current name of that method is query I suggested it be named 
  get fat but that was not accepted.
<mahmoud_alkhraishi> lol
Manu Sporny:  Thank you Justin that's super helpful I'd certainly 
  didn't know that was going on.
<justin_richer> HTTP GET_FAT /foo
Manu Sporny:  Why did I put myself thank you um.
<justin_richer> ;)
<orie> so we can just switch to POST /messages ?
Manu Sporny:  I totally forget okay so just to just to be clear I 
  think so Mike I think what you're all everything you're saying is 
  not a surprise to me so at least I understood that oh I put 
  myself on the queue for do you have to use transaction ID Dimitri 
  I think unknown right now I think I mean take a look at the the 
  OAS file transaction ID.
Dmitri Zagidulin:  Okay just wanted to clarify that got it 
  understood.
Justin Richer: 
  https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html
Manu Sporny:  That you have done a post here and have been given 
  a transaction ID to use or you got it out of band yeah so when 
  you put when you post to exchanges exchange ID you will be given 
  a transaction ID to use for the next step in the process.
Dmitri Zagidulin:  Got it thank you.
Manu Sporny:  That's the that's what yeah I think that's where 
  folks are right now and to be clear the only thing the pr defines 
  are these two things Mike you're suggesting we should do a get 
  you know potentially get here potentially create these are other 
  PRS let me let me just State I think Mike these are other PRS 
  that you're going to write and we will look at.
Mike Prorock:  Correct those would be follow-ons I just wanted to 
  note that like hey if we're talking about things that may have 
  stayed on the server somewhere we've got to go deal with those 
  things because there's a gap on the credential side as well right 
  if we think about credentials as a collection of things right.
Manu Sporny:  Okay good so I'm so I I'm hearing that we have 
  agreements I will I will update this to a put that needs to be 
  done the pr do a put and then I will merge everything and then 
  Mike you're going to follow up with PR's for these endpoint 
  definitions.
Mike Prorock:  Yeah forget errs deletes and I will likely do that 
  PR across the board anywhere we have a collection that may be 
  stapled because we kind of need that so.
Manu Sporny:  Um can you please do those as separate PR's and not 
  one massive PR.
Mike Prorock:  Yes I will do it by the path so it'll be like 
  here's a getting to put you know anywhere like we're missing an 
  implied method that's blocking functionality right I would do so 
  it's a credential thing so it's here's the credential stuff as 
  one PR oh here's this exchange is thing like here's you know some 
  corrections all that and then a follow on PR that adds any 
  Getters or deletes etcetera.
Manu Sporny:  Okay alright okay so I think that's the path 
  forward for this PR I should be able to do those things by the 
  end of tomorrow and put it in there and then Mike you can start 
  basing yours off of that with this PR in I think we have 
  everything that we would need to do the credential refresh stuff 
  and in a couple of other things that are needed.
Manu Sporny:   Brian you're on.
Brian Richter:  Sorry I'll be brief I got a dog barking I'm just 
  wondering how come we're going with uuid I think that specific 
  and say this tidy.
Manu Sporny:  That is an excellent question there was some amount 
  of discussion in here over that I think Cory you suggested look 
  if we're going to do these types of IDs we should Define a type 
  and use it across the entire API where it makes sense to do so 
  like a transaction ID I then suggested well I know that we want 
  to use the multi base encoded 128-bit values and some people want 
  to use uuids so if we're going to have a universal type.
Manu Sporny:   It might contain both of those things.
Manu Sporny:  And I think that there are I mean and then we need 
  to hear from everybody else if people are like no that's too 
  restrictive or like that's really weird why are you doing two 
  different types of ID formats we need to hear from everyone my 
  expectation is someone would have to do a PR I can volunteer to 
  do that PR and then the group would need to jump in and and 
  comment on the pr Brian does that give you at least some amount 
  of that.
Manu Sporny:   It's I think we're we're.
Brian Richter:  Yep doesn't make sense.
Manu Sporny:  Where we're headed let's see Mahmoud you're here go 
  ahead.
Mahmoud Alkhraishi:  I had a quick point so to me transaction ID 
  being a uid or something similar that makes a lot of sense just 
  because this is an instance of a thing the types sorry the 
  exchange ID I'm not sure if that needs to be a uuid or somewhere 
  that could just be like a type of some sort right like one of the 
  examples that I gave was this is an exchange.
Mahmoud Alkhraishi:  Credentials and so would just be a named 
  thing or we would need a way to translate that ID to a name like 
  I think there's an implied endpoint of what are all the 
  transaction IDs that you support as an API that would be 
  basically a get and point and then you can translate those IDs to 
  what that means.
Manu Sporny:  Great thank you Mohammed Mike you're on the queue.
Mike Prorock:  Yeah I that's actually kind of what I queued to 
  ask about because there's a there's kind of two ways we can go 
  here right one is to say hey we've got these exchanges we want to 
  specify the type explicitly in the past so like exchanges you 
  know AG path or ID age verification / then the ID of the actual 
  instance of that thing the other way is if you're just posting to 
  create.
Mike Prorock:  Two exchanges and you're not.
Mike Prorock:  You know perhaps that type is specified by you 
  know VP requests Etc into that like nope nope here's my posting 
  and VP request in there and the type is in handled entirely by 
  that VP request and then in that case that exchange ID just goes 
  away right all we're dealing with this once an exchange created 
  with an ID that ID then gets reference so it simplifies things 
  down a little bit from a passing standpoint but those are the two 
  ways.
Mike Prorock:   Ways we could go there and I would.
Mike Prorock:  Feedback on that you know from Orion my mood as to 
  thoughts on that because like I have soft preferences One Way 
  versus the other obviously leaning a little bit towards like 
  specify the type in the path because that's what I think I 
  suggested in the last meeting or the meeting before that.
Manu Sporny:  All right I yeah so I just put myself on the cube 
  The Exchange ideas Mahmood the current reg EX for it the only 
  thing that we require is it starts with a through z r 0 through 9 
  and then you have at least three characters so the the suggestion 
  is that.
Manu Sporny:   At least digit.
<orie> POST /exchanges
<orie> with some type for defining id.
<orie> its called a "slug"
Manu Sporny:  Our would like the possibility of putting a human 
  readable string in there of some kind where the ID can be human 
  readable it is possible for that to be a legal thing so for like 
  credential Dash refresh we want to be able to do like exchanges / 
  credential refresh or exchanges / credential refresh stat / some 
  kind of transaction ID anyway that's our use case.
Manu Sporny:  Going to your like you should be able to post to 
  exchanges that gives me a little bit of heartburn but you know it 
  would be good to kind of understand what the use case is and in 
  detail there so I don't want to say like no let's not do that but 
  I'm a bit you know concerned about that anyway the Mahmood the 
  point you're making about like yeah their transaction IDs and 
  those are like 128-bit numbers map to some kind of scheme 
  representation.
Manu Sporny:   Dior multi base encoded 128.
<orie> you can use "anyOf"
Manu Sporny:  Those are transaction IDs but the exchange IDs 
  can't be those things or we also need the option of them being 
  human readable strings or you're on the Queue next.
Orie Steele:  Yeah so you can use a nanny of representation and 
  open API specification you know 3 that would cover your slug 
  human-readable possibility it would also cover patterns for 
  recognizing uid V4 or whatever other types you wanted to make 
  valid for that parameter Beyond just specifying a string so you 
  can do all of those things and provide good examples.
Orie Steele:   In the API documentation for all.
Manu Sporny:  Yeah plus one are doing that and I tried to do that 
  in this PR mic Pro Rocky on the queue.
Mike Prorock:  Yeah I guess the agree with what we just said I 
  guess the question is because I saw Orion the chat suggested just 
  having it as like exchanges as kind of the root path and then ID 
  to refer to the instance I think Manu the way that that would be 
  like if you wanted to get exchanges of a certain type like 
  credential refresh you would do a get with a query that says I.
Mike Prorock:  Need things that match this particular.
Mike Prorock:  Json example that I just gave you that happens to 
  include the specification of credential refresh right in you 
  would get back all those credential refresh items so I think 
  that's the philosophical question is do we want the ability to 
  specify that type you know of exchange that's occurring in the 
  URI in the path itself or do we want a more generic system that 
  says I it's just we're handling exchange data.
Mike Prorock:   Data and type.
Mike Prorock:  Find as you know a subtype of the VP request back 
  or whatever is getting passed through so in the SI I know get is 
  not but yeah creating one right there so if you're posting and 
  saying yep I want to fire starting exchange instead of saying I 
  want to start an exchange / credential refresh and therefore I'm 
  posting to that I create a credential refresh path that starting 
  up basically is that is that fact that it's credential refresh is 
  that specified in the body of the post.
Mike Prorock:   Store is that specified in the path and that's.
Mike Prorock:  Philosophical question there and I saw Orion the 
  chat like I said just say no it's basically we want to specify 
  that typing in the body whereas what was initially proposed and 
  it is in this PR right now is to say oh that type is specified by 
  an exchange ID in the way that PR is now in the path itself and 
  then you're getting an ID back does that does that make sense or 
  did I just model things.
<orie> your exchange-id has no example... which would probably 
  make it clearer.
Manu Sporny:  I think I and I think I understand what you're 
  saying Mike but only because I have read all the comments in PR 
  258 just to be clear that the one of the use cases we gave so 
  digital Bazaar has a use case where we're processing these things 
  you know at scale so the true age program it's you know 60 
  million you know of these types of calls per day in the way.
Manu Sporny:  A lot of load balancer.
<mprorock> POST /exchanges/credential-refresh
<orie> ^yep
Mike Prorock: +1 Manu
<mprorock> which is why i wanted it in the path
Manu Sporny:  You know as your gcp and AWS work is that if you 
  can look at the URL to do the load balancing that is way more 
  effective than if you have to go and look into the body meaning 
  that if you have to invoke a jsonparser to go and find something 
  in a Json thing figure out where you're going to direct this 
  request many.
Manu Sporny:   Balancing Frameworks do.
<orie> good reason, but you can still define the URL parameters 
  fully.
Manu Sporny:  Or that they just support it based on the URL I 
  will also note that get in query parameter style stuff is not a 
  use case for us you know we just have this fairly simple 
  collections thing you've got exchanges it's a collection of the 
  types of exchanges so you have types of exchanges in there and 
  then you know we want to be able to post to the that a certain 
  type of exchange to initiate a very specific.
Manu Sporny:  Okay just a close this PR out though I think we 
  have a clear path forward I haven't heard anyone object to kind 
  of merging in the pr modifying that post to a put and then Mike 
  working on top of that so let's go ahead and do that and then 
  move on to our next next item let me pause for maybe.
Manu Sporny:  15 Seconds for someone to object and then we'll 
  move on.
Manu Sporny:  All right we are on to issue processing 10 minutes 
  ahead of schedule.

Topic: Controller-style Endpoint Pattern

Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/257
Manu Sporny:  Just great means we actually agreed to something 
  issued to 57 is the next item up I will put this in.
Manu Sporny:  Okay so this this one's kind of a bigger 
  conversation that we're going to get to any kind of resolution on 
  it on the call today but a while ago like a year and a half ago 
  we had decided on this control style and point naming pattern and 
  so you know basically what that means is we have try and pull up 
  the BC API just to provide an example.
Manu Sporny:  So in the spec today.
Manu Sporny:  What's it what's a good example of this.
Manu Sporny:  Let me find a different one.
Manu Sporny:  Maybe it's the maybe this right so correct me if 
  I'm wrong my Quarry my mood but this is the controller style and 
  point naming its kind of got a verb so you've got your kind of 
  collection and you've kind of got a verb at the end of it and 
  that's viewed as a legitimate way of doing some of doing this.
Orie Steele:  It maps to function invocation logically the verb 
  as a function and its post body as their arguments its Network 
  responses the output of the function and you can have side 
  effects or no side effects that that's the idea behind the 
  controller style naming convention.
<mprorock> it is not an either or - it is more method specific
Manu Sporny:  Yep so this is what we picked the the first time 
  through and you know we had consensus and we've marked the whole 
  whole thing up like this but one of the things that I think has 
  been brought up lately was do we want to do that like isn't 
  credentials the collection and do we want to give credentials 
  specific IDs in that collection so do we want to go that route 
  and if we do.
Manu Sporny:   How do we map.
<orie> you can mix controller and collection style endpoints
Manu Sporny:  All of the endpoints over to that right so this is 
  this is just a conversation about that do we want to keep the 
  controller style in point naming or do you want to at least look 
  at proposals for what it would look like to do the the other 
  pattern Mike go ahead you're on the queue.
Mike Prorock:  Yeah I think it and I think or e note of this as 
  well in the chat but it's not a it's not an either/or it's more 
  of a which for which right so when we look at a method like you 
  know credentials derive right and you're posting that you're 
  saying here's this body that says I want to go create a new thing 
  that's derived from some other credential right cool that makes 
  sense for controller style and point but if I want to go get a 
  credential right from a collection of credentials to.
Mike Prorock:  See if it was revoked.
Mike Prorock:  You're not.
<orie> or you can use a POST and wait for the HTTP WG to 
  implement QUERY :)
Mike Prorock:  Then I want to get credentials / the ID of the 
  credential I'm trying to get in order to go retrieve that exact 
  credential and say yeah let me look at some things about this 
  right assuming I'm authorized to do that and so I think that's 
  the thing is it's not so much that it's an either/or it's a you 
  know are we using the right things appropriately in the right 
  places does that make sense so like for instance post credentials 
  issue makes sense to me because it creates.
<mahmoud_alkhraishi> i think post credential makes more sense 
  than post/credential/issue
Mike Prorock:  Whereas in the case of credential post credential 
  status there it's already issued it probably has an ID so we 
  probably want it to be a put there right um you know potentially 
  right it depends there's arguments on this right but those are 
  things that we need to be thinking about.
Manu Sporny:  Go ahead Orie you're up.
<mprorock> and good note on privacy manu
<mprorock> that is why we have to be careful with this
Orie Steele:  Yeah so you know with respect to using path 
  parameters right you need to think about what is the domain of 
  the path parameter you know are you going to do you have IDs that 
  are URLs in which case you're sort of nesting a URL inside of 
  another URL that happens a lot with linked data and really nasty.
Orie Steele:  Oftentimes you want you know to you know encode 
  that kind of thing with a query parameter or do some other kind 
  of approach so I think the thing you know if you're going to mix 
  collection first of all I would say collection style and points 
  are generally only work when you are the resource server operator 
  and you are assigning the ID if you need to build an API that 
  handles things that are identified with IDs that you didn't 
  create the ID.
Orie Steele:   D the collection style naming.
Orie Steele:  Will get in your way all over the place because 
  you'll be trying to take an ID that somebody else made and put it 
  into your path but they made their idea URL.
<mprorock> e.g. a GET /credentials/{id} might specify that the id 
  MUST not be derived from sensitive data, but people will get lazy
Orie Steele:  So like you have to think about what is the 
  structure of the data that you're going to be building this API 
  around and I didn't you know my experience with the controller 
  style naming convention is very flexible because you're dealing 
  with Json arguments you know so you can you can handle things 
  like you know URL reserved character collisions really really 
  easily but it does sort of make the entire endpoints sort of look 
  like a function function sort of method style interface instead 
  of like.
Orie Steele:  In oriented interfaces that's it.
Manu Sporny:  Yep so like all all good points.
<orie> GET /credentials?id=http://...
Manu Sporny:  So we digital sorry I had tried collection style in 
  points for credentials and quickly hit up against what Ori is 
  mentioning meaning that the second we had an ID that was not you 
  know issued by us all of a sudden we had really ugly ugly URL 
  encoded things being put into the collection so that's certainly 
  a concern the other concern.
Manu Sporny:   I had to do.
Manu Sporny:  Privacy so you know in some cases URLs are logged 
  pretty aggressively in server logs and you kind of leak what's 
  happening you know when you do that there's an upside to that 
  right which is the whole like load balancing Frameworks not 
  having to reach deep into the HTTP message to pull out you know 
  where to load balance to if they even have that capability so 
  there are benefits.
Manu Sporny:   Drawbacks there's night.
<orie> what mime types will the api support?
Manu Sporny:  Like to I think all of us know there's no clean 
  there's there's no clean decision we can make right now unless we 
  know every single endpoint that we're going to have in the API 
  and that none of them are going to fall victim to you know one 
  one one downside of the other so you know I but I think I'm not 
  hearing people objected leasing some proposals.
Manu Sporny:  And then just kind of going from there right 
  because we already I think if we pull this PR in this merge PR 
  the workflow holder API or holder exchanged workflow PRN we have 
  we have a demonstration of a collection now where the server is 
  in control of the naming and maybe that can be the rule that we 
  use.
Manu Sporny:  All the end points.
<orie> the server assigns the ID?
Manu Sporny:  We're if it is something that the server is control 
  has control over maybe at that point of collection based endpoint 
  makes sense.
<mahmoud_alkhraishi> i think that makes sense, if server is 
  responsible of generating id then it uses collection otherwise it 
  doesnt
Manu Sporny:  And if it is something where the server does not 
  have control over that URL meaning it's just could be another URL 
  that may be a good argument for the kind of object function style 
  interfaces.
Manu Sporny:  Thoughts go ahead Ori.
Orie Steele:  So we added get credentials to the trace in our own 
  profile because you can't actually test revocation without them 
  and point so we support you know a get style interface which is 
  of the form credentials / credential ID and it returns a json-ld 
  verifiable credential that is a revocation list or 50 credential 
  and this is sort of required to actually test end to end.
Orie Steele:  The concept of the.
Orie Steele:  Status feature which is in the current API that 
  we're looking at here so I'm just sort of saying stating the 
  obvious like you can't really use revocation lists if you can't 
  get them and if you're using a URL to identify them then you need 
  to get them by that URL.
Manu Sporny:  Yeah I think that's an excellent point Ori.
Manu Sporny:  Go ahead Mike Pro Rock.
<justin_richer> that's not a url for the credential, right? the 
  CRL has a separate URL?
<manu_sporny> yes, true Justin, but it's also a VC...
Mike Prorock:  Yeah and I was going to note because I think the 
  there's a couple of things like I think it's easy to think that 
  were like you know ABS few kading potential privacy leakage by 
  hiding stuff out of the URI you know as far as URLs go and stuff 
  like that or IDs the reality is I think anyone that we would 
  really be concerned about is looking at far more than just the 
  URI logs and scanning through a lot more than that we also can do 
  sane.
Mike Prorock:  Things like specify that it might.
Mike Prorock:  An ID that you're getting an issue and you know 
  when you issue a credential and you hand back some ID that you're 
  going to go look up there are ways to specify that that's not 
  leaking information etcetera right so I think there are things 
  that we have to think through cleanly here we also do reliably 
  need a way even if it's just defined for internal use or 
  authenticated use only you know to be able to check the 
  replication status stuff as already mentioned.
Manu Sporny:  All right so Justin would you mind vocalizing what 
  you said in the chat Channel because I think it's important and 
  then we can go into next steps here.
Manu Sporny:  If you want to.
<orie> GET /credentials/{id} makes sense when the issuer hosts a 
  revocation list at that URL.
Manu Sporny:  Let's go in the next steps then.
<orie> but its not to say its the only solution to that problem
Manu Sporny:  So it sounds like the next step is the group is 
  open to the possibility of having collection style and points and 
  if someone feels strongly about having a collection style and 
  point or changing one of the endpoints we have right now to a 
  collection style and point they should make a proposal.
<orie> its just the only one documented in the CCG work items for 
  revocation lists.
Manu Sporny:  Would anyone object to that characterization.
<mahmoud_alkhraishi> sounds correct to me
Manu Sporny:  All right I will make a note of that.
<mprorock> that could also be GET /credentials/status/{ID} where 
  ID is the id of the revocation list
<orie> justin_r here is an example from the spec: 
  https://w3c-ccg.github.io/vc-status-rl-2020/#example-2-example-revocationlist2020-credential
Manu Sporny:  Okay so with that should we close the issue.
<mprorock> if we are strictly limiting to status checks, but that 
  breaks some of the flexibility of current approaches there
Manu Sporny:  Many objections for closing the issue because 
  that's kind of the resolution there.
Manu Sporny:  If folks want to do collection style naming 
  conventions submit a PR and we'll think about it any objections 
  to closing.
Manu Sporny:  Hearing none closing the issue.

Topic: Workflow IDs and names

Manu Sporny:  All right next item up is workflow IDs and names we 
  might have actually made some progress on this bike.
Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/256
Manu Sporny:  The link is in our see this is PR 256 or sorry 
  issue 256 should workflow IDs and names to be provided in the URL 
  or the post body there's been quite a bit of back and forth here 
  I think we already kind of sort of talked about this and the 
  conclusion seems to be that we're okay with allowing.
Manu Sporny:  But we need PR's with concrete suggestions let me 
  pause there or you were involved in this discussion you know Mike 
  so were you what thoughts on this one.
Mike Prorock:  Yeah I think we kind of hashed it out and the 
  review of that last PR right which is that we kind of want the 
  IDS and whatnot or at least especially the idea both you know / 
  kind of normal conventions there and so subsequent PRS to clean 
  things up might refine this but that when we're representing a 
  core ID that you know we're doing some kind of 128 bit you know 
  conforming to a scheme etcetera right there are.
Mike Prorock:  Ways to attack that.
Mike Prorock:  That seemed to be amenable to folks and when there 
  are items that may we may want like a human readable for in some 
  cases like / credential refresh you know off of exchanges that 
  there may be others who might say yeah but I want that explicitly 
  not human readable or based on some uid and that's also okay 
  right so depending on what it is I think we've got some 
  flexibility to not paint ourselves into a corner here I see or 
  you just commented.
Mike Prorock:   But so I don't know if he has further comments 
  but I think as long.
Mike Prorock:  Specifying the types in the open ID specification 
  were okay.
Manu Sporny:  You're on the case.
Manu Sporny:  And I think you meant OAS specification yeah okay 
  Ori thoughts.
Orie Steele:  I think my covered it you know we're defining an 
  HTTP API the post potty Json structures the endpoint definitions 
  We should strive to be as precise as we can so that we can rely 
  on good validation tools you know pero Los so when we say it's a 
  string it's not very helpful because you know there's lots of 
  valid strings out there right is it allowed to be a script tag.
Orie Steele:   No let's be clear right so I think.
Orie Steele:  That's them.
Orie Steele:  In the point I'm trying to make is we should try 
  and be as clear as we can but when we reach the edge of consensus 
  when somebody wants human readable and somebody wants definitely 
  not human readable we can sort of support both of those things 
  with schemas that we Define concretely.
<mprorock> @mahmod - types of exchanges you accept would 
  typically be returned by a GET to /exchanges
Manu Sporny:  Okay and I'm I'm I'm hearing us all agree I type 
  something up so the group discussed this on the February telecon 
  the group is open to placing IDs and names in a URL but require 
  PRS to explore the specific use of ID or name for particular use 
  case it is expected that any path parameters need to be very 
  clearly defined with generous examples in the PRS.
Manu Sporny:  Making that are finding in closing the issue.
Orie Steele:  I mean I think my moods comment here probably 
  deserves a separate issue but I think I think he should open a 
  separate issue then we should close this this particular issue.
Manu Sporny:  Plus 12 that Mahmood would you mind opening an 
  issue.
Mike Prorock: +1 Separate issue, but I think i will handle in my 
  follow on PR
<mprorock> so tag me please ;)
Manu Sporny:  Some thank you all right I'm commenting on this one 
  and then closing this one and then my moods opening a new one to 
  address his.
Manu Sporny:  All right let's see.
Manu Sporny:  That exhaust the issues that we had scheduled we 
  have 10 minutes left looking at.
Manu Sporny:  Are there any other issues that folks feel are high 
  priority like we should definitely talk about them today 
  otherwise I'm just going to hunt and hunt for something that 
  looks.
Mike Prorock:  The only request I would have would be a five 
  minute break between now and five o'clock Eastern time or 
  functionality reasons it's been a long day.
Manu Sporny:  Okay so yeah yeah now got it um how about let's 
  queue up a discussion for next week we really should talk about 
  the credential status thing I think like I are the traits folks 
  concerned about this endpoint.
Manu Sporny:  Or does it okay all right so let's put that on the 
  agenda for next week and then Mike if you have your PRS ready we 
  can talk about those on next week as well.
Mike Prorock:  Yeah and your you said you're planning on merging 
  what like tomorrow Thursday sometimes something like that.
Manu Sporny:  When's yeah I'm going to try for tomorrow.
Mike Prorock:  Okay I should be able to knock them out over the 
  weekend I think so.
Manu Sporny:  Okay all right I'll try try early in the day 
  Wednesday but we'll see how that goes okay then with that that's 
  it for the call today any last words before we end the call.
Manu Sporny:  All right thanks everyone again great progress 
  we've been making a lot of progress over the last two weeks 
  appreciate that let's keep up the pace and get those PRS and all 
  right thanks everyone and have a great rest of the day chat with 
  you all later in the week and if not next week bye.
Received on Wednesday, 9 February 2022 22:13:55 UTC

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