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

[MINUTES] W3C CCG Verifiable Credentials API Call - 2022-05-24

From: CCG Minutes Bot <minutes@w3c-ccg.org>
Date: Sun, 12 Jun 2022 22:49:28 +0000
Message-ID: <E1o0WOb-0001nT-4o@mimas.w3.org>
Thanks to Our Robot Overlords for scribing this week!

The transcript for the call is now available here:


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


VC API Task Force Transcript for 2022-05-24

  1. Announcements and Introductions
  2. Should this API define how to host revocation lists?
  3. Issuer API does not expose issuer identifiers and supported 
    crypto suites
  Manu Sporny, Orie Steele, Markus Sabadello, Mike Varley, Mahmoud Alkhraishi
  Our Robot Overlords
  Manu Sporny, Markus Sabadello, Eric Schuh, Dmitri Zagidulin, Dave 
  Longley, Logan Porter, Ananay, Kayode Ezike, Joe Andrieu, Justin 
  Richer, Andy Miller, bengo

<dmitri_z> VC-EDU plugfest: 
<dmitri_z> Original VC-EDU plugfest invitation email: 
Our Robot Overlords are scribing.
Manu Sporny:  All right welcome everyone to the May 24th 2022 VC 
  verifiable credential API call our agenda is here on the agenda 
  today is just a lot of issue processing basically.
Manu Sporny:  Going to talk a bit about revocation lists 
  supported crypto sweets for a Shore endpoints nature being 
  optional has a lot to do just with the issuer API endpoint 
  unsupported issuers and in things of that nature.
Manu Sporny:  Any other updates or changes to the agenda before 
  we get started.
Manu Sporny:  Okay go ahead Eric.
Eric Schuh:  Yeah just been a couple weeks just want to give a 
  quick update on where the use cases team is at so we're still in 
  the process of reviewing the sequence diagrams as part of that it 
  became necessary for me and Joe to reach out to the original 
  authors so it's taking a little bit longer than I had originally 
  hoped but we're through the first three use cases I think for at 
  least a second pass will be.
Eric Schuh:  Continuing with the next three.
Eric Schuh:  If you wrote one of those you will probably be 
  hearing from either me or Joe the email just with any questions 
  that came up and I think the way it's feeling to me is after 
  we're done with that review with authors that will be the right 
  time to bring those back to the group and they'll be at least 
  somewhat stable at that point so going to be another couple weeks 
  I think for that but that's where we're at.
Manu Sporny:  Okay great awesome thank you Eric for the update 
  and thank you for continuing to work on that.
Manu Sporny:  Okay so I guess our next are kind of action from 
  that it's just you're going to let us know when you're when you 
  have them updated.
Manu Sporny:  So I know that there's a you know you've got a kind 
  of a there's a bug with the mermaid diagram renderer thing I am 
  going to be unable to get to that for probably about three weeks 
  or more so my apologies but it shouldn't it just makes it.
Manu Sporny:  Little uglier it doesn't you know it doesn't it 
  just puts more vertical space than I think we'd like and there's 
  some weird CSS things that are going on with it.
Eric Schuh:  Yeah it's mostly a white space issue so do nothing 
  functional that I've found.
Manu Sporny:  Okay great okay well let's go ahead and go into 
  kind of a now we are kind of in announcements announcements and.

Topic: Announcements and Introductions

Manu Sporny:  Anyone need to call anyone would like to introduce 
  themselves or reintroduce themselves.
Manu Sporny:  See on an ace new I don't know if you'd like to 
  provide a provide an intro background on you.
Manu Sporny:  It's fine if you don't and just want to stay quiet.
Manu Sporny:  Okay I think the rest of us the rest of us all know 
  each other we've been on these calls for a while any 
  announcements other than the use cases one we just heard from.
<ananay> Hi, sorry can not open mic rn, but Hi everyone, I just 
  Joined W3c and will be in your care.
Manu Sporny:  Okay if not we can go ahead and get into the agenda 
  before we do that you know apologies I have not well I guess it's 
  for those of you that might have missed the this ECG weekly call.
Manu Sporny:  Oh hey on an ageist introduced themselves can't do 
  a mic right now but just join w3c wonderful welcome and welcome 
  to the group.
Manu Sporny:  As many of you know the the charter vote for the 
  verifiable credentials working group and the data set 
  canonicalization working groups out right now I've been prodding 
  a couple of w3c members in at this point it looks like we have 
  the minimum votes necessary for working group be created I can't 
  say the numbers because those are I think member confidential.
Manu Sporny:   But we're.
Manu Sporny:  Pretty well with you know week to go for the 
  verifiable credentials one and two weeks left in the boat for the 
  rdf dataset canonicalization stuff so that's going well okay onto 
  our issues.

Topic: Should this API define how to host revocation lists?

Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/232
Manu Sporny:  First one up is should this API Define how to host 
  revocation lists this is issue 232 and was brought up by Ori 
  actually let me go ahead and share my screen here.
Manu Sporny:  So we've got.
Manu Sporny:  Okay so Ori ask the question.
Manu Sporny:  Currently revocation list 2020 and the status list 
  2021 stuff assumes that the list is hosted somewhere the VC API 
  provides no way of obtaining that credential the the list so the 
  question is should the VC API Define how to host revocation lists 
Manu Sporny:   So I believe.
Manu Sporny:  It's out of scope so maybe we could start with your 
  position Marcus and then we can kind of go from there.
Markus Sabadello:  So I don't fully remember this but I but I 
Markus Sabadello:  My idea was that a revocation list is 
  something that's specific to one type of revocation mechanism or 
  one cadential status Michael is ruined.
Markus Sabadello:  Transferring me to define something.
Markus Sabadello:  That that's specific to one mechanism and not 
  universally applicable but.
Markus Sabadello:  But I don't I don't completely remember that 
Manu Sporny:  All right thanks.
Dave Longley:  So I think there's some later comments on this 
  issue about trying to reduce the having the verifier contact the 
  issuer or hit an endpoint generally to try and increase privacy 
  one of the things that's in the design for revocation lists is to 
  express them as credentials and that would allow a verifier to 
  request when they're requesting It Whatever credential they're 
  requesting they could also.
Dave Longley:   West the.
Dave Longley:  And lest credential at the same time which would 
  allow the holder to pull that information directly from the 
  issuer and they can keep a cache copy or do whatever it is they 
  want to presumably that would this be C would have to be fresh 
  enough / the road whatever the verifier requires but they could 
  respond to a VPR and include the revocation list credential along 
  with whatever credential.
Dave Longley:   Uses it and that would be.
Dave Longley:  To handle the privacy-preserving aspect of this.
Manu Sporny:  If I Had You.
Joe Andrieu:  Yeah for for both the relocation and the refresh I 
  think there was a sense at least I believe I advocated for it 
  that these are points of extensibility but we should probably 
  have one example so that people can see how the whole stack works 
  together like I think a lot of people don't understand how you 
  can do relocation at all without the phone home problem so I 
  think I have had a sense that we there was some agreement.
Joe Andrieu:   Not that it would be good to have at least one 
Joe Andrieu:  Both those mechanisms in scope for us to figure 
Manu Sporny:  Think Joe me any other thoughts on this item.
Manu Sporny:  Go ahead Eric.
Eric Schuh:  Yeah I think it's echoing what Joe is just saying 
  but I was thinking it'd be if we do want to support this very 
  nice to have a use case because currently I don't think any of 
  the identified use cases call-out revocation in any way so if we 
  could either work it into one of the existing ones or if someone 
  could write a good example of a revocation use case that would 
  make use of this that would probably be helpful in framing.
Eric Schuh:   Whether or not it is in or out of school for.
Manu Sporny:  Okay so let's see we do have well yeah right so all 
  that all that's good stuff we do have I think the the hesitation 
  in the beginning was this is a this is an extension point and we 
  don't need Define it let's get the core API you know down and 
  figure it out since then status list 2021.
Manu Sporny:  Tesla's 2021 spec you know exists and there is 
  thought there was maybe there isn't.
Manu Sporny:  No it's the it's the credential refresh isn't it 
  that's the that's the flow that we have refresh we see refresh 
  2021 is the thing that exists.
Manu Sporny:  And I think we have yeah we have like a protocol 
  flow here.
Manu Sporny:  But we don't have a protocol flow for example 
  protocol flow example for.
Manu Sporny:  Status list 2021 I guess.
Manu Sporny:  Okay so what are the next steps here we need to.
Manu Sporny:  Need to wear where should we detail this so should 
  we detail this in status list 2021 and then point to that as an 
  example of.
Manu Sporny:  Revocation or should we.
Manu Sporny:  Should we put this one thing of how you do.
Manu Sporny:  Asian in scope for the VC API noting that there's 
  another argument that we should put this in scope for the 
  verifiable credential base spec like the data model stuff so so 
  the three options are at least three options are put it in the 
  v-spec then we can only just talk about data model put it in the 
  VC API spec as the one normative way of doing status and 
Manu Sporny:   Or keep it in a separate Speck.
Manu Sporny:  And point to it from the VC API specification 
  thoughts on those three.
Dave Longley:  I would think it's going to end up being a 
  combination of those things sorry I didn't I didn't jump on cue 
  go ahead guys.
Manu Sporny:  Since I had it Joe.
Joe Andrieu:  My sense of the the VC API and I obviously we're 
  still teasing out scope here that's the fundamental question was 
  it it's wherever you need an endpoint for exchanging be seized or 
  managing be seized and it seems like both refresh and relocation 
  are part of that set we just haven't formalized a very well so I 
  would question why isn't that endpoint part of the.
Joe Andrieu:  One of the endpoints we use to manage species would 
  be my question.
Manu Sporny:  Ocean Marcus Europe.
Markus Sabadello:  So monitored until recently argued that these 
  tests which should be more modular and.
Markus Sabadello:  We're not we're not talking about test Suites 
  right was just talking about the API specification because I 
  remember in the test with you you argue that all should be more 
  modular right and there's no it is a separate test suite for Tiki 
  and then there's a test suite for Ed 25-19 2020 and those are not 
  part of the main we see API test Suite anymore so I'm wondering 
  if that would be an argument Falls making this more modular and 
  not make it part of the main.
Markus Sabadello:   The main API specification because like you 
  said it's.
Markus Sabadello:  But I'm not sure I just just a thought that I 
  think about these these are some kind of histories.
Manu Sporny:  Yes certainly my preference would be to keep them 
  separate in molecular there's a tension here right I mean they're 
  good good arguments on either side the the argument for well so 
  ok so first of all Marcus I think you're right you know there 
  there's there's this argument for modularity and it is we there 
  is a way to break this stuff down so all these things are in 
  different test Suite so there's not one monolithic VC API test 
Manu Sporny:   And there's.
Manu Sporny:  Kind of a super focused core test suite and then 
  test Suites for Cryptid sweets in status mechanisms and refresh 
  mechanisms and all those all those extension points so one way we 
  could approach the work is basically say you know their test 
  Suites were all the extension points for a VC in in the VC API 
  has to define the basic end points for doing those things and I 
  think it does today like the exchanges stuff.
Manu Sporny:  I believe supports the refresh credential refresh 
  so we've got that in the VC API spec and then the status list 
  stuff is just any random URL out on the internet can hold the 
  status list or the status list credentials and so managing those 
  things is really kind of a back-end task for the issuer the 
  issuer is the thing that manages those URLs and does things with 
Manu Sporny:   So you know.
Manu Sporny:  All things you know all things considered it feels 
  like keeping these things as module modular specifications 
  modular test Suites in then pointing to them from the VC API as 
  the one example Joe so if we want to provide examples we can say 
  if you want an example of how to use XYZ API or how to do 
  credential refresh or how to do status lists here as a normative 
  specification that you can go off and read.
Manu Sporny:   At least that would be my preference.
Manu Sporny:  Go ahead base.
Dave Longley:  I agree with a lot of that one other thing I want 
  to bring up is that there's been a number of people in the VC in 
  the in the run-up to getting a second PC working group they've 
  mentioned how while we have extension points it would be really 
  good for interoperability for any one of these extension points 
  to have one working mechanism that people can be pointed to and 
  while I agree.
Dave Longley:   We want to try.
Dave Longley:  Modular it would be good to figure out a way to 
  deal with that tension as well and the other thing is there may 
  be some additional work that needs to happen with the VC API to 
  enable more privacy preserving checking of the revocation list 
  and so there might be a piece of for example the verifier API 
  might need to be able to accept the revocation list credential.
Dave Longley:   Well when.
Dave Longley:  When the very whenever whatever party hats that 
  endpoint to verify BC it might need to optionally be able to send 
  the list so it doesn't have to be fetched by the verifier API and 
  that would be something that would go into the VC API test Suite.
Manu Sporny:  See I put myself on the cue but forgot why was that 
  front end of your comment lonely.
Manu Sporny:  Well one way one way you know the so the point is 
  people have been saying Hey would be good to have you have all 
  these extension points you need to Define at least one normative 
  way of doing it I think we can do that we can keep things modular 
  and do that by effectively pointing in a normative way to say You 
  must support status list 2021 for example and then point to the 
  spec right because because specs do that all the time they point 
  to other specs in a very normative way and say you must.
Manu Sporny:  He's back so that's my suggestion if you know to 
  keep things modular we can keep things modular and we can point 
  normatively in the v-spec to say this is the one way of you this 
  is you have to at least implement this replication mechanism or 
  you have to at least specify this sorry status list you know 
  mechanism or credential refresh mechanism the concern I have is 
  the sheer amount of work.
Manu Sporny:   That that might.
Manu Sporny:  Generate for us where we have to move all those 
  things into normative you know all at the same time in inevitably 
  someone is going to show up with you know an arguably more 
  privacy preserving mechanism right and then they'll be a big 
  fight over all right which one you know should we should we use 
  and again there's a trade-off there if you pick one thing then 
  you improve interop.
Manu Sporny:   But you also.
Manu Sporny:  Potentially take other things the working group 
  could have done in the meantime off the table that might have 
  been you know more important so it's a bit of a double-edged 
  sword doing that go ahead tape.
Dave Longley:  Yeah I don't think we need to go so far as to say 
  that you must implement this particular mechanism but I think 
  what people were looking for minimally was if you're going to use 
  this extension Point here is one normative way that you can use 
  that extension point and I think that's different from telling 
  people that they must Implement status this 2021 instead it's if 
  you're going to use the credential status feature in the VC w g 
  data model here is one normative way.
Dave Longley:   It's done if you want to.
Manu Sporny:  Plus 12 that see Joe gave a thumbs up as well.
Manu Sporny:  Um okay so what is the proposal here that we don't 
  Define how to host revocation lists with the VC API but we do 
  point to a specification that does that in the desire there is to 
  say that there is a normative way to do that here's how you would 
  do that and here's how the and that specification says how you 
Manu Sporny:  You can specify the protocol on how you do that is 
  that is that what we were saying go ahead lonely.
Dave Longley:  I think so with the with one addition which is we 
  need to say that that other spec might also Define a hook into 
  the VC API for sending a revocation list credential to the 
Manu Sporny:  Yeah I know dick noting that it's super dangerous 
  to do that unless you're using a heard privacy mechanism like 
  status list 2021 and even then that's frowned upon like ideally 
  it's the holder delivering that status list credential and there 
  isn't a direct verifier to issuer communication.
Manu Sporny:  I see okay.
Dave Longley:  That's the to be clear that is the purpose of this 
  the holder fetches it hands that to the verifier the verifier 
  hits the VC verifier API with that caught it came from the holder 
  that way they avoid pulling it from the issuer directly from the 
  revocation list and point.
Manu Sporny:  In the spec that should say that is the credential 
  status 2021 spec.
Dave Longley:  Yeah we'd be the first version of a spec saying of 
  an extension spec saying what the VC API verifier API needs to be 
  able to accept and so we might also need a section in the VC API 
  we needed to extension point for the verifier so that credential 
  status mechanisms can create these kinds of extensions.
Dave Longley:  It's effectively a way to forward information from 
  the holder to the verifier API so it's hate to use the word 
  bucket but it's sort of a bucket for credential status it meta 
  data or information that a verifier that understands how to apply 
  a particular revocation method or status check method can use.
Manu Sporny:  I miss that last part where would that.
Dave Longley:  So when you when you're making a call to verify a 
  verifiable presentation or credential or verifiable credential 
  you would include additional credential status information and in 
  the case of status list 2021 that would be you can optionally 
  include the status list credential it off to the bear.
Manu Sporny:  In the presentation you're saying in the 
Dave Longley:  If we might want it to be an option that rides 
  along with the presentation so you send the presentation you also 
  send options in those options today you include like a challenge 
  and some other information and we would want a section on for 
  credential status data and you would send the revocation list.
Dave Longley:  Credential or that status credential as an option 
  for the verifier to use.
Manu Sporny:  Okay I see so that you're talking about in like the 
  BP request spec we would do that.
Dave Longley:  There's two pieces there's two pieces to this.
Manu Sporny:  For the video response yeah there's it would be in 
  the presentation right.
Dave Longley:  Well the VP presentation request would ask for a 
  status list credential along with what other credentials you're 
  providing the holder would provide that information to the 
  verifier app I'm not sure if I'm using the right terminology 
  still the app would turn around and send the credentials from the 
Dave Longley:   And I guess would end up.
Dave Longley:  We have to work through the details here but it 
  might end up that that credential is in the presentation itself 
  but what we want to have happen at the verifier service is it 
  knows to pull out the revocation credential from that 
  presentation and use it instead of fetching it directly.
Manu Sporny:  Okay um okay so what so what's the plan here we are 
  going to.
Manu Sporny:  When when the topic of if there's a time where 
  there is going to be a topic about you know revocation in the 
  spec or we should talk about it and we should say hey if you want 
  to do revocation here's a normative way of doing it and then we 
  put a point to whatever the most popular you know mechanism is 
  that day let's just say it's like credential status 2021 and in 
  the credential status 2021 spec the data models defined the API 
  ground Management's defined.
Manu Sporny:   And in we're expecting large chunks of it to be 
  dependent on the.
Manu Sporny:  II or side effects from the VC API and then there 
  may be other instructions in there on how to use the herd privacy 
  credential how holder can prefetch it and how a verifier can ask 
  for it if the holder has it and how the holder can deliver it to 
  the verifier if if they.
Manu Sporny:   Know how to get it you know.
Manu Sporny:  From the issuer so it would require both the 
  verifier in the holder to understand that each other supports 
  this delivery feature and if they don't support that then for 
  example the verifier can just go out to the issuer and fetch it 
  in the in the holder still protected by preferred privacy when 
  that happens.
Manu Sporny:  Did I summarized that plan correctly.
Dave Longley:  It sounded right to me.
Manu Sporny:  Okay would anyone object to that plan or have 
  concerns around that plan Joe.
Joe Andrieu:  What gave me pause is the your language here that 
  the verifier just goes to the issuer which is generally a pattern 
  we have not been a bracing.
Manu Sporny:  Yeah and that's why I hesitated a bit when they 
  first said that because I know that people might look at that and 
  go like we are never supposed to do that and in some cases it's 
  kind of sort of okay like in the hard privacy case right status 
  list 2021 was designed for that being the the the way people 
  would just default to doing it with the more complex protocol 
  that lonely just outlines being the best practice right.
Manu Sporny:  Um but we know that something.
Manu Sporny:  Are lazy and.
Manu Sporny:  Well I don't know if that's a good argument but you 
  know implementers can be lazy and and they're going to do the 
  thing with the path of least resistance and we have to at least 
  protect the holder in those cases and then the hope is that we 
Manu Sporny:   Put a.
Manu Sporny:  Not light on there being a better way to do this in 
  the future and and you know make that something that wallets 
  compete on is we're being better about the way we you know.
Joe Andrieu:  Right so so if our intention is what you just 
  described and we I think we should have stronger language than 
  verifier just goes to the shore and should be something along the 
  lines of the verifier should use the Privacy respecting mechanism 
  or something that avoids phone home right we should we should I 
  think we should have a should in there about a privacy respecting 
  mechanism rather than language that some people will see that oh 
  they can just contact the issuer and they'll go build.
Joe Andrieu:   That workflow.
Manu Sporny:  Yep yeah I mean we could go as far as basically 
  saying you should not the verifier should not contact the issuer 
  in should use this other privacy-preserving mechanism where the 
  holder delivers the credential to the verifier.
Joe Andrieu:  Yeah as long as we can get Shades in there I 
  understand that it can't be a must because there are use cases 
  that need that but should do it through a privacy respecting 
  intermediary layer is I think important.
Manu Sporny:  Okay all right any concerns are objections to that.
Manu Sporny:  Group are to go ahead.
Kayode Ezike:  Here's a quick one so I guess this means that the 
  holder would have to have whiskey would have to communicate with 
  the verifier more often in order to get the more up-to-date 
  version of the status list now that now that we know we're not 
  relying on just verify being able to just update whatever is 
  hosted at that link now we have to kind of have a way for the 
  holder to then make sure that they're.
Kayode Ezike:   You know constantly in sync with.
Kayode Ezike:  If I select is a thoughts on on how frequently 
  that that should be happening this putting that out there.
Manu Sporny:  Go ahead Dave.
Dave Longley:  I think that's going to be a matter of policy for 
  the verifier and wallets are going to have to be responsive 
  they're going to look at ideally they would look at a VPR that 
  would have that information in there that says the credential 
  needs to be at least this fresh and the wallet would need to go 
  fetch it if it did not have a cached version that was that fresh 
  and because it's really going to be the verifiers policy we can 
  put we can suggest.
Dave Longley:  Time frames in the spec but it's going to be a 
  business rule.
Manu Sporny:  All right one second way while I type this up so 
  the proposal is talk about status revocation the VC API in point 
  to a normative status replication mechanism from the spec spec 
  that is pointed to as a concrete example of how to implement 
  implement the feature the spec that is pointed to.
Manu Sporny:  All the data models and the protocols hired to 
  implement the location mechanism as well as guidance to maximize 
  privacy when possible ideally the.
Manu Sporny:  Are should not contact issuer to check status 
  information and should get that status information from the 
Manu Sporny:  To implement this is wellcome.
Manu Sporny:  In the VC API and.
Manu Sporny:  Okay so I think this one's ready for PR any other 
  thoughts before we move on to the next thing.
Manu Sporny:  All right that was a good solid discussion on this 
  item thank you everyone okay.
Manu Sporny:  Next item up the should start getting easier in 

Topic: Issuer API does not expose issuer identifiers and supported crypto suites

Manu Sporny: https://github.com/w3c-ccg/vc-api/issues/266
Manu Sporny:  Okay so does the issuer API that you sure API does 
  not expose issue are identifiers and supported crypto sweets this 
  kicked off a long discussion between Horry and Dave and Marcus 
  chimed in as well it also spread into other repositories and the 
  traceability work.
Manu Sporny:  What I remember this kind of sort of has to do with 
  Discovery and whether or not we need it I think the current.
Manu Sporny:  The current set of discuss the current set of 
  conversations we've had in the group have basically said that 
  they're going to be issuer issuer URL in points just base in 
  points that are configured with very specific credentials in very 
  specific crypto sweets in very specific issue or IDs and those 
  are not optional things that are sent anymore or rather 
  implementations can can provide kind of options to switch those 
Manu Sporny:   Up but one way of a.
Manu Sporny:  Plex City here the N by n complexity here is to 
  just make it so that issuer and points are locked into a very 
  specific issue or crypto sweet and possibly credential.
Manu Sporny:  Okay so thoughts on that from folks that are 
  implementing go ahead Dave.
Dave Longley:  Yeah I'm a big fan of creating specific 
  configurations on issuer software that are bound to as narrow a 
  set of things for eliminating an option ality as much as possible 
  ideally completely so the way I'm imagining these things to work 
  is the party that wants to be able to issue credentials using the 
  issuer API creates a new issue or.
Dave Longley:   Since which.
Dave Longley:  The configuration has a configuration that they 
  want to support it that endpoint that would be a crypto sweet or 
  Advocate status list or a credential status mechanism if they're 
  using Z caps for example they would provide Z caps to allow 
  access to use a certain key to sign the credentials they might 
  also use oauth credentials to provide access to particular keys 
  for signing.
Dave Longley:   Something along those lines and.
Dave Longley:  Once you create that configuration that it that 
  endpoint using that in point should not require.
Dave Longley:  Sending any kind of options and so when you post 
  to that endpoint you send the the credential you want to have 
  issued and if that's a supported credential I think I missed this 
  you would also want to configure the credential types that are 
  supported at that in Point if you send something that's valid for 
  that configuration then you get a credit you get issue to an 
  appropriate credential.
Dave Longley:   I do.
Dave Longley:  I just don't think and you know responding this 
  discoverability concept I just don't think that there's it makes 
  sense to have an API where a client could iterate over all the 
  issuer's provided in an endpoint find one that has a 
  configuration that they like and then just send something to it 
  presuming that they even have the credentials to hit that 
  endpoint I don't think that that really matches I don't know what 
  use case that matches and it I don't think.
Dave Longley:   Really makes any sense to do it that way I think 
Dave Longley:  It's going to be the process for setting up an 
  application for issuing credentials is going to be to create and 
  configure in issuing configuration and then add that to your 
  software and hit that endpoint whenever you want to issue 
Joe Andrieu:  Yeah it it seems to me that the I think I'm with 
  Dave I mean it's the issuer app which will be talking to the 
  issue or service and that issue our app is the one who has 
  encoded the business logic is written to drive that service 
  endpoint it knows what that service is doing on behalf of the app 
  like that was part of.
Joe Andrieu:   Of standing up the whole.
Joe Andrieu:  So I'm not understanding the use case in which the 
  issuer app would need to do some sort of Discovery because the 
  issuer service was configured to support the app so it seems to 
  me it's a configuration time thing and not an interactive thing.
Manu Sporny:  Yep plus one is that all that makes a lot of sense 
  to me I think the the concern I have is that or he's not here in 
  Mike Farley is not here to argue why they feel like Discovery is 
  you know such a strong you know use case for them go ahead Dave.
Dave Longley:  Yeah I agree it would be good to get their 
  feedback again but my my feeling is that that original design 
  came out of creating a system that's going to work with a test 
  suite and it made writing test Suites easier but a whole lot of 
  things were risk were relaxed and didn't you know don't really 
  match real-world use cases with the test Suite I think create 
  creating a demo site or a test Suite site that anyone can hit.
Dave Longley:   It will sign with any key you know in.
Dave Longley:  Your configuration options was a really good way 
  to quickly bootstrap showing some of the features of this API but 
  when you get down to real world use cases it's not going to ever 
  function that way and and and I think we just need to modify how 
  we would go about you know doing the test Suites where you 
  provide specific configurations for the specific tests that you 
  want to run and that that matches how you would also set up 
  applications in the real world.
Manu Sporny:  All right any other input on this item so the 
  original issue was the issuer API does not expose issuer 
  identifiers and supported Chris crypto sweets the argument is yes 
  and it doesn't need to be in clothes the clothes the issue.
Manu Sporny:  Yeah please go ahead Andy.
Andy Miller:  I think my new this is Andy from one attack just as 
  a little context I don't I'm not I don't have any input on that 
  specific way the issues specifically worded but I do I did want 
  to share that we have two specifications that support Dynamic 
  client registration.
Andy Miller:  That's LT I.
Andy Miller:  Badges and the the use case are the scenario is 
  that a in the case of an open badges one that you have your 
  badges hosted somewhere you've been collecting them out on what 
  we call a host which probably more be called a wallet these days 
  and but you want to move them yeah I want to move them to this 
  other service that I that I have come across or I just prefer.
Andy Miller:   For some reason.
Andy Miller:  And the through with Dynamic client registration if 
  both sides support that then the application I music can reach 
  out and discover the endpoint that the other host that I want to 
  move to what it supports and can facilitate the actual exchange 
  of all the registration information that.
Andy Miller:   It's needed for.
Andy Miller:  And and then and then start the actual process of 
  helping you move your badges over to this new host so it's it's 
  really the use case for us in both cases is where person wants to 
  do something with their data move it to a different or use it or 
  move it to a different application that.
Andy Miller:  The current platform is not aware of yet and they 
  don't want to go through the whole they in fact can't go through 
  that whole process or there's no easy way to go through the whole 
  process of getting the two platforms to talk to talk to each 
  other call each other on the phone exchange email blah blah blah 
  blah blah that's a facilitates all of that and it can happen 
  almost instantly.
Andy Miller:  And by the way Dynamic so that even a registration.
Justin Richer:  And fight but I never sold out.
Andy Miller:  Is used to stand the service Discovery as part of 
Justin Richer:  I don't have a way of doing the Cuban like to do.
Manu Sporny:  All right Justin you're on right after Dave who's 
  on the Queue I will add U + Justin thank you Andy that is that a 
  super helpful service Discovery babe you're up next.
Dave Longley:  Right so just do want to quickly respond to what 
  Andy said and then I was on the queue for different reason I 
  would say and he's use cases of you know really important one but 
  it doesn't follow it does not fall under the issue or API because 
  I don't think that the way that use case was described as not 
  involve having all of your badges reissued and I don't know that 
  you would even be able to do that because you would have to 
  contact each individual issuer you can't just ask.
Dave Longley:   Ask some other service.
Andy Miller: +1
Dave Longley:  Sign all of your badges over so I think what 
  you're really talking about there is is as you mentioned you have 
  this concept of a host or a holder a wallet and you want to move 
  your existing badges to a different location to have those stored 
  I think that's a totally valid use case but not related to what 
  the issuer API is going to do and the comment I got on the Queue 
  to make was I wanted to tweak what you said Manu it's not that 
  we're going to say.
Dave Longley:  Need to express any configuration information at 
  these endpoints it's that I think it's fine to create a git and 
  point for any one of these configurations so that any party 
  that's able to access that endpoint can load and see what the 
  configuration information is but we don't need to do that in 
  support of some kind of Discovery API and nor do we need to make 
  it so that these endpoints are highly optional.
Dave Longley:   So I think it's totally fine to have an API.
Dave Longley:  Configuration and if you called get on it later as 
  some party that's authorized to hit that in point you could find 
  out what that configuration information is but that's the the use 
  case there is not two to browse this an endpoint a bunch of 
  issuer instances and pick one and hope that you can issue 
Manu Sporny:  Right thanks Dave Justin Europe.
Justin Richer:  Yeah so I just wanted to point out One support 
  for what Andy is is discussing in terms of its use case and to 
  just point out that the arguments that Dave is making are 
  ultimately hunting the registration and Discovery questions down 
  to another step and that has a benefit to cases which do have a 
  static configuration of which there are many and you know many 
  reasonable practical ones out there but the ability to have.
Justin Richer:   Have machine-readable.
Justin Richer:  Parameters for engaging with the system really 
  like you can't downplay that and pretend that the only way that 
  people are going to use it is in this you know open world lengths 
  lay where I don't know anything about you so I'm just going to go 
  through this entire catalog and hope I find something that 
  matches because what's really going to happen realistically is 
  that you'll have a handful of things that you do and a system 
  that you're trying to talk to and you're trying to find the 
  overlap of that.
Justin Richer:   For right now.
Justin Richer:  Yes exhibit a that with with automation that is 
Justin Richer:  This is I will also point out that this is not 
  really in conflict with Dave's idea of having an instance of this 
  be locked down to a particular set of parameters it does however 
  although that does though is push this question to some other 
  endpoint that hasn't been defined that gives you a list of 
  different configurations that you can that you can.
Justin Richer:  True thank you Justin.
Manu Sporny:  Awesome thank you Justin so good points all around 
  go ahead Dave here on the queue.
Dave Longley:  Yeah I wanted to to a certain extent I agree with 
  what Justin said it's if we wanted to I think the way that this 
  would work if people wanted to in a machine driven way create 
  these configurations the way would work would not be that they 
  would search for an existing configuration they can use is they 
  would hit an endpoint on the issuer service that would list all 
  of the possible support all the supported features of that 
Dave Longley:   At form.
Dave Longley:  They would use that to create their own 
  configuration from that dynamically and then use it and I think 
  that's that's all that all matches that all lines up with my view 
  of the system and I think that matches with Justin says.
Justin Richer:  Yes what you've just described is.
Dave Longley:  Right and it's but it's the thing that we were 
  missing before I think was we were trying to fit that into a box 
  where you would look at existing configurations and pick and 
  choose one and instead what we want to do is discovery of all 
  possible features that aren't particularly that aren't bound to 
  something so and I think what's key here is we don't want to get 
  a list of all the features and then choose all those options and.
Dave Longley:   Send them to some particular.
Dave Longley:  Point because that does not but we discovered is 
  that does not work with we know that these end points need to be 
  stateful in some way especially if they're going to be doing 
  status lists and and revocation mechanisms and so on and so it's 
  important that we have this step where you're creating the 
  configuration that it has some level some kind of state 
  associated with it and then we're using it and so I think what's 
  key is breaking these things apart so that what word I guess what 
  I guess what was confusing.
Dave Longley:   Two people was what we are discovering we're not 
  discovering an existing.
Dave Longley:  Can use we're discovering the features that are 
  available on the issuing system so that we can create a 
  configuration to use it.
Manu Sporny:  All right so where do we go from here the original 
  issue was that the issuer API does not expose issuer identifiers 
  in supported crypto sweets I think what Dave is saying is it 
  could publish a static configuration in by doing so you are not.
<dave_longley> publish a list of features (not a particular 
<dave_longley> those features can be combined to create a valid 
  configuration (issuer instance)
Manu Sporny:  Invalidating the whole dynamic registration kind of 
  Discovery use case and I think what Justin in India are saying is 
  that don't pump that use case down the road because they're 
  legitimate use cases they're in we will end up needing some form 
  and in some form of Discovery will be useful in the future 
  because we've seen this happen before.
Manu Sporny:   For you.
Manu Sporny:  Their systems is that a fair summary.
Dave Longley:  I would just nitpick on some of the terminology 
  there I think what's being published as the list of features that 
  can be used to create a valid configuration or issuer instance 
  and then you can use that issue or instance once it's been 
  created to issue credentials.
Justin Richer:  Every that so far.
Manu Sporny:  Okay just an indie any concerns about that like is 
  that so far off or.
Justin Richer:  I my only concern is that too big to adopt Dave's 
  language it would need 22 and issue or instance creation API 
  definition in order for that to make any sense and.
Manu Sporny:  Would it be enough to point to an issuer instance 
Manu Sporny:  Like a like just making this up but like / issuers 
  / 1 / config and then saying.
Manu Sporny:  Config has to follow this this data model it's just 
  like a Jason key value pairs on this is the issuer and this is 
  the crypto sweeten this is a revocation mechanism is that the 
  minimum arm that would need to be hit Justin.
<andy_miller> No concerns. We have a discovery document which  
  describes the supported features, endpoints, etc. The actual 
  registration is formed using the information in the discovery 
Justin Richer:  It's Robert it's that the critical part of that 
  we could just as my understanding of what Mike Farley and have a 
  steed I believe so about that is at least we're wired for that 
  use case unfortunately with Mike not on the call like and you 
  know and I do not speak authoritatively for that but I think that 
  that's at least a good start make sure my gets taxed so we.
Justin Richer:  So let's go.
Manu Sporny:  Okay so let's let's try that.
Justin Richer:  And I'll bring I'll bring this up with him when I 
  be with him later.
Manu Sporny:  Okay thanks Justin all right so let's try that the 
  current proposal is to expose a configuration for an issue or 
  endpoint and note the issuer ID crypto sweet allow mobile 
  credentials Rebecca.
Manu Sporny:  Is and other relevant details to provide the basis 
  for discovery for that in point it is unknown currently how that 
  particular configuration in point is discovered.
Manu Sporny:  Another issue so AP are describing the issuer and 
  points configuration is welcome which may or may not overlap.
Manu Sporny:  The discovery and points that vast provided.
Manu Sporny:  Any concerns about that being the path forward.
Manu Sporny:  Push back on that.
Dave Longley:  Miami pushback is its conflating the a little bit 
  that clean separation that we brought to light on the call so 
  it's we have two different things going on we haven't decided 
  whether or not we want to create an endpoint that exposes the 
  features that are available on each Wing system but if you wanted 
  to do Dynamic configuration creation you would hit that endpoint.
Dave Longley:  Decide to create a configuration from that and 
  then what we have here with the current proposal to expose the 
  configuration is that part's fine but we're not going to be ever 
  I don't think discovering that particular configuration that's a 
  you created that configuration following your discovery of 
Dave Longley:   That the issue.
Justin Richer:  I know that we were taught.
Manu Sporny:  I know that we were time and Joe I see your hand up 
  and Justin you're unmuted and we got to let people go so how 
  about so we're going to continue this discussion in the issue and 
  I'll just say I'll tag Mike Farley and we'll try to get further 
  here this was a good good discussion here today for this 
  particular issue was suggested that a.
Manu Sporny:   I'm here.
Manu Sporny:  But there were or concerns looking to save Longley 
  like barley Justin here the others to continue the discussion 
  here okay all right then that's that's that that one that's some 
  good data okay that's it for the call today thank you everyone 
  for joining I'm going to be on.
Manu Sporny:   Travel for the next two.
Manu Sporny:  So if you would like to volunteer to run this call 
  please let me know and if not we just won't have the calls thanks 
  everyone have a wonderful rest of the week and we'll see you at 
  some point in the future.
Received on Sunday, 12 June 2022 22:49:28 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 12 June 2022 22:49:29 UTC