[MINUTES] VC API 2025-05-13

VC API Community Group Meeting Summary - 2025/05/13

*Topics Covered:*

   - *Community Updates:* Publication of Verifiable Credential 2024 global
   standards scheduled for Thursday.
   - *Pull Request Review:*
      - *PR to remove /credentials endpoint:* This endpoint lacked
      widespread use and was removed. A related issue regarding API component
      overview in the issuer coordinator was identified and a new issue was
      created to address missing interaction endpoints in the YAML files.
      - *PR regarding proofs in credential issuance:* Discussion centered
      on whether the issuance API should allow adding proofs to an
already issued
      credential. The consensus was that issuance should happen only once;
      subsequent calls with the same credential should result in an
error. The PR
      will be revised to reflect this.
   - *Issue Prioritization (Effort Level):* Issues were classified as low
   or high effort for subsequent PR creation.
   - *Diagram and Workflow Clarification:* The current diagram depicting
   the VC API ecosystem was found inadequate for illustrating complex
   workflows involving both verification and issuance within a single
   exchange. A new issue was created to develop sequence diagrams illustrating
   these workflows, specifically focusing on a use case where issuance depends
   on a user-provided verifiable credential. The need to potentially revise
   the existing ecosystem diagram was also discussed, particularly to better
   represent the interaction between coordinators and workflow services.

*Key Points:*

   - The /credentials endpoint was removed due to lack of usage.
   - The credential issuance API should not be used to iteratively add
   proofs; issuance is a single action.
   - The current ecosystem diagram needs supplementary sequence diagrams to
   effectively illustrate complex workflows.
   - A new canonical use case and corresponding sequence diagrams will be
   created to clarify the interaction between verification and issuance within
   a single workflow.
   - The roles of coordinators and workflow services in initiating and
   executing credential exchanges require further clarification and potential
   diagram updates.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-05-13.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-05-13.mp4
*VC API - 2025/05/13 14:58 EDT - Transcript* *Attendees*

Dave Longley, Eddie Dennis, Eric Schuh, James Easter, Joe Andrieu, John's
Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, let's go ahead and get started. Let me share my
screen. the agenda for today is pretty straightforward. we're just going to
be reviewing community developments and processing pull requests. as a
reminder, what we're trying to do here is get the specification in shape to
hand over to the verifiable credential working group. And what we will do
today will be processing pull requests and then classifying issues on how
much effort we feel those things are going to be low effort high effort and
we might leave some of the high effort stuff to the VCWG. are there any
other updates or changes to the agenda? Anything else that we would like to
discuss today?

Manu Sporny: All right. If not, let's, talk about any community updates, if
necessary. I think I don't have much other than the verifiable credential
20 global standards should be published in two days. So, this Thursday is
the official release date. I think everything is on track for that.

Manu Sporny: And that will just happen this Thursday. it'll be followed
with a press release. and that's it. a long time coming. and then after
that, I think we will then be with that behind us, we can fully focus on
getting these other specifications onto the standards any other updates?
Anything else happening as a part of the community? work. All right. if
not, then let's jump into pull request processing. let's see, we have two
pull requests to process today.

Manu Sporny: the first one was raised by to get credentials endpoint. par
Dave and I have gone back and forth a bit in the issue in I think we've got
enough review. So basically what this was was we had this through issue 302
We were trying to figure out what the get credentials endpoint would do and
we did not have anyone using it in any large capacity. So we're going to
just remove it for now. It may come back later when we get a more clear use
case for it. part do you want to take us through the pull request part?
00:05:00

Parth Bhatt: Yeah So for this specific pull request I have updated two
files. One index.html and for that specific I removed the section 3.7.2
precisely I guess which was pointing to get credential endpoint and updated
the summary table for the same. I removed that endpoint details from the
summary table that's pretty much it on the index html file and for the
endpoint details there was the details regarding the endpoints I was
mentioned in the holder file so I basically removed that details from line
71 to 101 or maybe 110

Parth Bhatt: Yeah, that's pretty much it.

Manu Sporny: Okay, thanks Parth.

Manu Sporny: One thing jumped out at me. This issue coordinator section.
where is that API component overview? Is that the only thing in the issue
coordinator?

Parth Bhatt: Yeah, that was the only thing.

Manu Sporny: Maybe this might be a different bug. one second. Just checking
something really quickly. where is this? This expect it to be exposed by Go
ahead.

Manu Sporny: Eric.

Eric Schuh: Yeah,…

Eric Schuh: so these are the tables I put together just to index all the
end points and who is expected to be calling them.

Manu Sporny: Mhm.

Eric Schuh: I just wanted to also mention that this was an open issue to
resolve the I guess ambiguity in the expected caller field for this
credentials where it appears both in this issuer coordinator and you can
see at the bottom also in the issuer service. so that…

Eric Schuh: if we're just getting rid of the slashcredentials endpoint,
that issue might just go away in the PR I was working on just might not be
needed anymore.

Manu Sporny: You mean …

Manu Sporny: if we merge this then this goes away? I'm trying to figure out
it's the API component overview for what? this is for sure coordinator
service verifier holder workflow.

Manu Sporny: Yeah.

Eric Schuh: It was just to have one spot…

Eric Schuh: where all of the end points were indexed.

Manu Sporny: I'm just surprised that we have nothing else for a short
coordinator. That's the thing that's feeling wrong to me, but that this
might be true.

Manu Sporny: Go ahead, Dave. Okay.

Dave Longley: Yeah, I think the only thing that would appear on issuer
coordinator would be the new interaction stuff there.

Dave Longley: It should be possible to fetch the interaction protocols from
the issuer coordinator. So that seems to be perhaps what is missing there.

Manu Sporny: So, for a different PR and since the interaction stuff is new,
I think we just merged it. go ahead, Okay,…

Eric Schuh: Yeah. …

Eric Schuh: so I could probably take this on, but it would just mean that
the new YAML files need the X dash flag that I added so that they would be
correctly parsed in the tables.

Manu Sporny: got it. and…

Manu Sporny: I don't know if we have new YAML files. yeah,…

Dave Longley: Should we just leave the table as empty instead of removing
the whole section…

Dave Longley: because we're just gonna have to put it

Manu Sporny: that probably is the right thing to do. and we need to raise
an issue because I don't think I added the end points to the YAML. I think
I added this section but not the interactions endpoint. So that needs to be
added.
00:10:00

Manu Sporny: And where do we add that? In the exchanges.l file. Yeah, we
might need a larger refactoring of these files. Eric,…

Eric Schuh: Can do

Manu Sporny: do you mind raising an issue to add the interaction endpoints
to the YAML and then add those endpoints to the issuer coordinator?
Awesome. Thank you. And then what we could do here is just change this so
that it's not deleting the section. you can't change suggestions for
deleted lines. Interesting.

Manu Sporny: Go ahead, Par. Okay,…

Parth Bhatt: Yeah, you can just comment on 813 line,…

Parth Bhatt: the one that is not deleted, and I'll make sure I basically
get back all those lines. Yeah.

Manu Sporny: I can just leave a comment here. let's not delete this
section. we'll need it for the interactions endpoints. For now we can just
delete the slashcredentials value from the data API path. Okay.

Manu Sporny: So, we just need to make that change and then we can merge
this. And as soon as you make that change path, we'll go ahead and merge
this. unless anyone has any objections to this All right. If not, thank you
for The second you make those changes, we will go ahead and merge this.
Okay, next PR I just put in PR for this we had issue 337 which asked can a
credential contain a proof property when you go to issue a credential
basically do you what happens in that case the group discussed this quite a
bit and we said a PR needs to be raised

Manu Sporny: that realizes the four bullet points in the specification.
this R does that in a very rough way. We probably need some rewarding. so
it says that the endpoint is used to attach one or more proofs to a
verifiable credential And then after the API is described, we have two
paragraphs that are added. and I tried to make the language say that it
should attach all proofs during a single call. and then it should append
proofs if existing proofs exist.

Manu Sporny: and it should convert, a single to an array of proof values if
necessary in saying that it may be configured to return an error. so
basically not the default behavior. go ahead Dave.

Dave Longley: So, I'm questioning whether or not we should do this now I
assume a lot of time has passed. We've gotten some implementation
experience with this. I think it might be a little bit odd to reissue the
same credential and I think it would be hard to implement properly since
issuance involves a number of different things, especially if you had
status and so on. I think would be really challenging to issue something to
implement something that would work properly like this. It seems like it
should be all or nothing. if there already proofs on it, then it's probably
already been issued and you shouldn't be trying to reissue it again, but
instead that might just be an error case.

Manu Sporny: What about the use cases of notaries or…

Manu Sporny: witnessing

Dave Longley: I don't think you're issuing a credential when you do that…

Dave Longley: unless it's a brand new credential which references a
different credential. So and I think we've had conversations around that as
well. attaching an additional proof to something is not issuance on its
own. Issuance is the act of actually creating a credential which you
includes putting proofs forth on it. But I think adding a proof to
something that already exists is not the same thing as issuing
00:15:00

Manu Sporny: All So, what we need to do here is we need to go back to the
original issue and state that the PR was raised but the group felt that a
different approach should be taken. and PR 478. So it should be modified to
do the following.

Manu Sporny: The issuance of a credential that already contains a proof
value on what? Topmost object…

Manu Sporny: because we want it.

Dave Longley: Yeah, I'm trying to think through I mean is there a use case…

Dave Longley: where you have attached a proof of some other kind but you
are issuing the credential for the first time. I feel like we're perhaps
conflating things. So you wouldn't reissue a credential. That doesn't
necessarily mean that you couldn't issue a credential for the first time
where that credential happens to include proof information. And so maybe we
need to make it clear that that's what this does. If you submit a
credential that has a proof on it, that proof could be about by anyone for
anything about whatever, we don't really have to care. But I think what we
want to say is you don't issue a credential twice. So if you make a call to
issue, you only do that once ever with a given If that credential happened
to have proofs on it already, that I don't think that that's necessarily
relevant.

Dave Longley: I don't think it's in my first comments on this call was that
sounds like an error case but it might actually not be I'm changing it a
little bit.

Manu Sporny: Okay, hold on.

Manu Sporny: So, you're going back on the initial thing you said. Okay.

Dave Longley: So my initial comments that I'm keeping are issuance happens
once. we need this PR to say issuance only happens once. So you would not
make multiple calls to issue with the same payload to try and issue the
same credential multiple times. That's not What is valid is submitting a
payload that might have proofs on it already cause that thing to be issued
as a VC. So maybe there's some use case where you attached a proof to the
thing you want to issue as a credential and that's fine. I don't see why
that's a problem.

Dave Longley: I think one of the confusions here is thinking that the act
of adding a proof to something is the act of issuance which They're Adding
a proof to something is part of issuance. If you're going to issue
something, you do need to add a proof to it. But adding a proof to a
document does not mean that you're Issuing a credential involves
potentially adding a status record…

Dave Longley: if you have status and a number of other things.

Manu Sporny: Yeah, I'm trying to figure out…

Manu Sporny: what language that looks like.

Manu Sporny: And if it's just going to be confusing.

Dave Longley: One thing we can talk about in terms of errors is…

Dave Longley: if you tried to reissue the same credential twice, already
and you were keeping track of status. The issuer would have a record of
that credential and it would result in generating an error. And that would
happen regardless of whether they're proofs or not. That doesn't matter. So
that's really what triggers whether or not it's a duplication. So if your
issuing instance is keeping track of duplicate credentials,…

Dave Longley: then it will throw an error and that'll happen whether or not
you have proofs. The proofs don't matter.

Manu Sporny: Yep. …

Manu Sporny: issuance of a specific credential only happens once through
this API call. Trying to reissue the exact same credential twice must
result in an error. so don't make multiple calls to issue to try to issue
the same contra. That's weird. yeah,…
00:20:00

Dave Longley: I also don't think that second bullet point is accurate. You
can create an issuing instance that doesn't keep track of credentials. It's
not an illegal use of the API.

Manu Sporny: I tried to say exact same.

Manu Sporny: yes.

Dave Longley: Even that is not an illegal use of the API. what we don't
want people to do is create systems where you make a call to issue as if
the issue endpoint is for adding a proof. That's not what it is. That's the
semantics are incorrect. It's for issuing a credential.

Manu Sporny: API isn't meant to be additive. Is that what are those type of
APIs?

Manu Sporny: I don't know. Yeah, this is not an ad proof API.

Dave Longley: Yeah, I don't know…

Dave Longley: if that's the right statement either. I think we're just
trying to eliminate the confusion that some people have that issue means
add a proof. that's not what it is. Yes.

Manu Sporny: This is a issue credential API.

Manu Sporny: and we say which must include the addition of one or more
proofs in a single call to the API.

Dave Longley: If you have an issuing instance that just wraps a verifiable
credential in an envelope,…

Dave Longley: then it would not include a proof. So, we can't even say that
necessarily.

Manu Sporny: Yeah, you can't say much of anything in this case other than,…

Manu Sporny: don't use it to just add roofs iteratively.

Dave Longley: I mean, it's generally just bad practice to make a call to an
issue endpoint with the same credential m multiple times. There might be a
corner case use case where you're not tracking credentials and your
connection is severed and you want to make the call again. Even that sort
of setup is potentially problematic, but that might be okay.

Dave Longley: So I think we have to figure out a language that makes that
clear.

Manu Sporny: I mean it's just boils down to this one statement…

Manu Sporny: then right okay …

Dave Longley: Yeah, in general you should be making this call once.
Subsequent and depending on your issuer instance implementation subsequent
calls might result in a duplicate error.

Manu Sporny: then what about this should change to a must Then right.

Dave Longley: It's all proofs that the issuing instance cares about. When
we say all proofs, it's not clear what that means. Maybe you have a
pipeline that added a bunch of proofs before you get to the issuance stage.

Manu Sporny: Yeah. Yeah. Yeah. I'm trying to figure out how to say it cares
about differently.

Manu Sporny: Okay.

Dave Longley:

Dave Longley: Issuance related proofs. I don't know if that helps. I see we
can have because the leading sentence says if a use case requires the
issuing instance to attach multiple proofs, it must attach these proofs
during a single call. Yeah.

Manu Sporny: If a use case requires an issuing instance to attach. So
that's that statement.
00:25:00

Dave Longley: You're going to change the should to a must, right? And…

Manu Sporny: Yeah, I thought I did.

Manu Sporny: It must attach these during a single call. Yeah.

Dave Longley: then that is okay. yeah, I think that's probably all fine.

Manu Sporny: and issuing instance must not we say this up above right we
say it must be added

Dave Longley: Yeah, I think we've covered our bullet point with the first
statement.

Manu Sporny: So, that's it.

Dave Longley: Yeah, I think that's it actually.

Manu Sporny: All right. I'm going to leave this out there for another week
for people to think about it and then I'll leave it out for the rest of the
week if people have comments on it. Does anybody have any other comments on
this item? All right.

Manu Sporny: If not, we'll merge that at the end of this weekend. So, if
you have any comments on it,…

Dave Longley: I do have a comment.

Manu Sporny: please. Okay.

Dave Longley: So that adds a paragraph at the very top that says exactly
what we don't want to say. The endpoint is used to attach one or more
proofs. That is not what this does. This endpoint is used to issue a
verifiable credential.

Manu Sporny: To issue Okay.

Dave Longley: Yeah, that's

Manu Sporny: I'll do all right. We'll leave that until the end of this
weekend and if we don't get any more or more comments, we'll merge it in at
the end of the weekend. Okay, that's it for pull request processing.

Manu Sporny: Let's go back to our issues and start processing them on level
of effort. last week I think we ended up on 405. what we're trying to do
here is we're just trying to figure out what's the level of effort to write
a PR. What's going on here? …

Dave Longley: I don't think you submitted that comment.

Manu Sporny: It's cancel. No, Is that what I'm trying to do? There we go.
All right. 406. Okay. Recommend coordinators to expose the same endpoints
as services.

Manu Sporny: We talked about this highlight the notion that workflows are
used to exchange credentials across trust boundaries with issue
coordinators and verify coordinators. I think this is probably effort low.
it just needs some explanatory text. Anyone disagree? All right.

Joe Andrieu: May maybe …

Manu Sporny: And then all right.

Joe Andrieu: what I…

Manu Sporny: Another sentiment I think…

Joe Andrieu: what I didn't get from your summary is are we in fact doing
what they asked for or we responding with another sentiment. Okay, that
just raised the flag but I was away from the desk and

Manu Sporny: what they're asking us to do is expose these backend service
endpoints on the coordinators and…

Manu Sporny: we specifically do not want to do that. That's why we have the
whole separation if I understand correctly.

Joe Andrieu: Yeah, agreed.

Joe Andrieu: So, okay, cool. I just wanted that eye. Thank you.

Manu Sporny: No, that's a good call out. I'm just going to make doubly sure
that that's where we were here. Go ahead, Dave.

Dave Longley: Something that has been noticed with that diagram is you
don't necessarily see and maybe we want a different diagram for this but
you don't necessarily see how these things communicate like a verifier
coordinator communicates I don't know if this is a good example but I know
I was just going through this diagram with someone recently and it wasn't
clear how some of these components communicate with one another. I don't
know…
00:30:00

Manu Sporny: All right.

Dave Longley: if we can bring up the original whatever's on the spec today,
but I think that there we might need another diagram if we don't want to
make this one too complicated. But I do think that so the workflow service
for example does not have any arrows showing that it communicates with a
verifier service to perform verification or with an issuing service to
perform issuance. We don't have arrows like that. And I don't know if this
diagram is just going to get too complicated if we started adding stuff
like that. But it is if people are trying to figure out for example…

Manu Sporny: Mhm.

Dave Longley: how a workflow works and how it does its communication and so
on what it talks to that's not present in this diagram.

Joe Andrieu: Yeah, we used to have more arrows to the workflow service…

Joe Andrieu: because that's what any authorized party shows. but it talks
to its coordinator does it have outbound services to other components?

Dave Longley: Yeah, those are the arrows coming into the workflow service.
But how does the workflow service do its job? And it does that by talking
to verifier and issuance services for example. no I wouldn't. Yes. Yes. The
workflow service has an outbound if you were doing an let's say just as an
example a workflow that involved verification followed by issuance.

Dave Longley: The way that would work is any authorized party would use the
exchange to talk to a workflow service and then the workflow service would
make an outbound call to a verifier service to verify whatever was
presented and then it would make a outbound call to an issuing service to
issue something new.

Joe Andrieu: But those are two different things.

Joe Andrieu: One is you're verifying and then separately you're issuing,
right? That's not the same workflow.

Dave Longley: It is the same workflow.

Dave Longley: There's a single step in a workflow.

Joe Andrieu: So whose workflow service owns that?

Dave Longley: Yeah. Go ahead.

Joe Andrieu: The holder coordinator, the issuer coordinator, or the
verifier coordinator?

Dave Longley: In this case, I think it would be an issuer coordinator. Yeah.

Joe Andrieu: So, I just heard you say that the issuer coordinator is
talking to the verifier, which they do not do that during issuance. They
may do it as a precursor to their own evaluation of evidence. But it feels
like there's a use case of verifying the evidence that's different than the
use case of issuing

Dave Longley: So there are workflows today that involve that an issuer just
without putting components on the end of that some entity in the role of
issuer the workflow would involve requiring a very specific credential to
be verified and…

Joe Andrieu: So right now we don't have an authorization expectation that
the workflow that is yellow for example for the holder has the authority to
talk to any service outside the holder's domain.

Dave Longley: then followed by issuance and that would all happen with a
single workflow.

Dave Longley: So I'm not quite following that. So I don't know how we would
so to give real world example. holder would have The wallet would be
connected to a workflow service and…

Dave Longley: during an exchange the holder would use their wallet to
present a credential and then receive a newly issued one. That would all
happen through a single workflow. And so I'm not sure how to fit that into
this diagram, but that is a real world use case.

Joe Andrieu: But I don't think the holder So,…

Joe Andrieu: I'm confused. So, you're saying when the holder contacts the
issuer to get a credential, it does it through a workflow service. So hold
on that is the issuer.

Dave Longley: Yes.

Dave Longley: So if you want to walk through the whole thing, for example
the holder would use an issuer coordinator website and initiate a workflow
there. The work the Yes.

Joe Andrieu: The issuer is the only one who has the authority to
instantiate a workflow on its workflow service. So the holder is not
actually talking to that workflow service.

Dave Longley: Yes. Yeah.

Joe Andrieu: start talking to the coordinator.

Dave Longley: That they haven't talked to the workflow service yet. So step
one is they talk to the issuer coordinator.

Joe Andrieu: Okay. Mhm.

Dave Longley: The issuer coordinator creates that exchange which is on this
diagram with their workflow service and then they hand over that exchange
URL to the holder somehow and the holder gets that to their digital wallet
somehow and then their digital wallet communicates with the workflow
service using this exchange.
00:35:00

Joe Andrieu:

Joe Andrieu: The issuer workflow service.

Dave Longley: Yes, that's right.

Joe Andrieu: Yep. …

Dave Longley: And in doing that, the first step of that workflow is a
request from the holder for a particular credential. The digital wallet
provides that. It gets verified and then the wallet receives an issued
credential from that same workflow as at the end of the step. Yeah, I
wouldn't use the word jamming…

Joe Andrieu: what you're doing is you're jamming in a VC presentation of a
different VC into this flow. Am I understanding that right?

Dave Longley: because that's how we've designed VC API exchanges is it's a
channel of sending verifiable presentations and…

Dave Longley: receiving verifiable presentations as many times as necessary.

Joe Andrieu: But my point is the request for a VC in order to issue is not
part of the issuance flow.

Joe Andrieu: It is a prerequisite for that issuer. And so I think it's a
different use case. You are in the middle of your issuance flow. You're
going to a subsequence. That's a different flow.

Dave Longley: Yeah, I don't know…

Joe Andrieu: I Yeah,…

Dave Longley: how we want to, use the language around it, but that is a
real use case and the UX does demand that it be essentially part of that
same exchange.

Joe Andrieu: it's trick Okay, I think I understand the problem. I don't
know how to resolve it, but I see parses on the queue.

Parth Bhatt: Yeah, if I understand correctly the flow what they've
mentioned, I think that subsequence of requesting VC is basically verifying
the identity of whoever is the requesttor or the holder coordinator
basically and then once that identity is verified or let's say through VC
after that whatever the initial request of issue me some credential until
that process basically resumes back in. Is that a fair understanding? Mhm.

Dave Longley: Yes, but I think it might be more specific than is necessary
for the use case. it's not necessarily just about identifying another
party. that there's a workflow that's designed where you need to present
some credentials in order to be issued some credentials.

Parth Bhatt: Makes sense.

Dave Longley: And the UX requires that all happen through a single exchange.

Manu Sporny: So, going back up the stack, we'll need to change something in
the diagram, but we don't quite know what it is just yet. this was a
request to expose some things that we don't want to do, Because the holder
coordinator doesn't directly get credentials or any of that stuff. and Joe,
I take your point that this is not a loweffort thing. Maybe or I think we
need to raise another issue. that specifically speaks to that flow we just
talked about.

Manu Sporny: the thing that's in the back of my mind right now is just kind
of like we do this where do we had some diagrams somewhere right? maybe it
was here. Yeah, we had these diagrams on what actually happens during a
presentation or an issuance. And maybe the place to explain what we just
talked about is in a sequence diagram like this and is not in an overall
ecosystem diagram. there is something wrongish I think about the center of
this diagram. or rather something that just leads to it.

Manu Sporny: when Dave was talking through it, it didn't go like you
couldn't follow it by looking at this diagram. And it may be that a
sequence diagram is probably the best way to understand those workflows. go
ahead Dave.

Dave Longley: Yeah, I think this diagram sort of assumes that issuer,
verifier and holder are different parties but those are also used as
different roles and in the flow I was describing the issuer is playing the
issuer and is at different times playing an issuing role and a verifying
role but they're the same party using their own same workflow service and…
00:40:00

Manu Sporny: Go ahead, Joe.

Dave Longley:

Dave Longley: so that this particular diagram doesn't really lend itself
too well to understanding that setup.

Joe Andrieu: So I agree this diagram is problematic…

Joe Andrieu: if what we're trying to do is have one workflow service do all
of this. But it seems to me that the request for the VC that's going to be
verified could be done on the workflow service and the fact that it is the
software running on the same box in the same, operational center sort of
doesn't matter. The role in that case is as a verifier. So I do think a
sequence diagram is one way to clean this up.

Joe Andrieu: I'm just not sure that thinking of those two workflow services
as the same service helps when we have delineated by role in this diagram.

Manu Sporny: Yeah, I agree with that.

Manu Sporny: I don't want to lose this diagram. I think this diagram is
helpful. for certain things I don't think the diagram is helpful for
walking us through what actually happens during the workflow, So I think we
need to figure out what do we remove here so that people don't try to run
through a workflow using this diagram or I mean it may be that we provide
less information on here. food thought for later. Go ahead Joe.

Joe Andrieu: I just want to suggest I think Eric and I have been doing some
sequence diagrams that are these and we've had them back in conversations
with you and Dave trying to understand that we really understand it.

Joe Andrieu: So maybe there's a version of those sequence diagrams we could
make as a second sort of example of let's walk through a use case. cool.

Manu Sporny: Yeah. Yeah.

Manu Sporny: And specifically if people ask in the future we don't go to
this diagram and try to step through something. We just say you're
interested in issuance where somebody has to present a credential and then
they get back a new credential based on what they presented. Here's the
diagram that does that. Right.

Joe Andrieu: So, here's the task I'll take on, which is I think we need to
write up the canonical use case. That is interesting. to this. We know that
we want a VC that the issuance is dependent on a VC provided by the user.
We can come up with a use case for that and we'll vet that with you and
then we'll Eric and I will make a sequence diagram that walks through that
use case visually.

Manu Sporny: Yeah, that sounds great. so if let's go ahead and add that as
an issue as well.

Manu Sporny: Go ahead Dave.

Dave Longley: Not trying to cause too much trouble here,…

Dave Longley: but the other part with this diagram that we still might want
to change is I think the more common flow is that the issuer coordinator.
So if we look at issuer coordinator, it's going to arrow out to issuer
service and it might be the more common flow that it only creates an
exchange with the workflow service and then the workflow service talks to
the issuer service. And then the same would be true on the verifier side.
that's something we might want to change in this diagram. that is yes.

Manu Sporny: So you're saying the issuer coordinator only talks to the
workflow service and…

Joe Andrieu: First right. Sorry.

Manu Sporny: the workflow service is the one that's actually connected to
these backend systems. So

Dave Longley: I didn't take it that far. I do think that the workflow
service should be talking to the issuer coordinator is then going to manage
other stuff. but when you're doing issuance through a workflow, you're
going to depend on the workflow to talk to an issuer coordinator is going
to start this interaction. It's going to hand it off to the workflow
service and…

Joe Andrieu: Yeah. Heat.

Dave Longley: then the workflow service is going to talk to a digital
wallet, which is in effect a holder coordinator.

Dave Longley: So the way that this makes it seem like that's not what
happens. And that really is what happens. But the issuer coordinator is
still going to be talking to these other services, com doing this the
storage service whatever this is for a spe specific issuer will have some
specific database.

Dave Longley: It needs to bring that information together, but it will then
use that information to create the exchange. And then the exchange itself
will talk to the issuer service when it's time to do the issuance.

Manu Sporny: Mhm. Okay.

Manu Sporny: So, work to be done here. I'm sure we'll probably have to have
another discussion about this specifically. so let's go ahead and raise an
issue. Joe, I don't know if you want to raise the issue about redo the
diagram or…
00:45:00

Joe Andrieu: Okay, I'm writing that up as a new issue.

Manu Sporny: it's not redo the diagram. it's create sequence diagrams for
workflows specifically that, have a focal use case around issuance that
requires a verification of something.

Manu Sporny: Thank you. all that I'm change. So, going back to issue 406
though. this is this one's low effort. Those other two are This one is just
if you want to exchange credentials across trust boundaries, you use issuer
coordinators or verifier coordinators to do that. So, I'm going to still
stick with it's a loweffort this specific one is a loweffort one.

Dave Longley: I'm going to be annoying again. the comment you just made
about if you want to exchange the credentials, you do that credentials
across trust boundaries, you use the issuer coordinator. I think the issuer
coordinator or…

Manu Sporny: In order to exchange a credential across trust boundaries.

Dave Longley: a verifier coordinator in they initiate the interaction, but
then the actual exchange is handed off to a workflow service. So the
coordinators coordinate, they pull in data from Then they hand you off to
where you need to go to do the exchange, which is the workflow service.

Manu Sporny: The exchange is initiated via contact with an issuer verifier
coordinator and the actual exchange is then handed off to their respective
workflow services. Is that a fair statement?

Dave Longley: Yes, I don't remember the language we landed on for create
versus use exchange. I don't know if we're conflating any of that here
because I don't remember what we landed on, but that's my only nitpick.

Manu Sporny: In order to exchange a credential request, the exchange is

Manu Sporny: We don't say workflow in here at and an exchange is created as
a part of kind of a workflow, there's loose use of the English language up
here that doesn't use our terminology and then it gets very specific and
uses our terminology. I think that's the problem. receive a credential
across trust boundaries.

Dave Longley: You could say created after contact with

Manu Sporny: The process is initiated via contact with an verifier
coordinator. and…

Dave Longley: I think that's good enough.

Manu Sporny: off there.

Manu Sporny: All going to try to get more specific, but that's fine. try to
performed by their expected workflow services.

Dave Longley: You could say the actual exchange is performed by their
respective workflow versus

Manu Sporny: All right.

Manu Sporny: So now is it low effort?

Dave Longley: I don't think that changed the effort level.

Manu Sporny: Meaning it's still low effort. this should be something
hopefully that's explained in a paragraph.

Dave Longley: Yep.

Manu Sporny: that says effectively this thing.

Manu Sporny: All right. That's that item. And let's see. on to the next
one. Details of delete credential ID should be added. we only probably have
time to discuss this one.
00:50:00

Manu Sporny: what does this endpoint do? is it clear what this endpoint
does? I remember us having a debate over what this endpoint should do.
should it revoke the credential if it deletes it? for example, do we even
have this anymore?

Dave Longley: I think the short answer to that question would be no because
that's the status service responsibility. But it does sort of leave this
end point as a potential foot gun and…

Dave Longley: but maybe that's just needs to be documented.

Manu Sporny: We mean you say that here.

Manu Sporny: It seems like…

Dave Longley: Yep.

Manu Sporny: what she just said, I think. So, we're okay there. so I think
we just need to document. we do showing we do that here.

Manu Sporny: It's really here. And really, all we need to do is link this.
I think this was added or at least any detailed API spec is not written. I
guess we don't have that.

Manu Sporny: Yeah, we just don' have a section for we don't have a section
for delete credential or even delete presentation. I don't know what
deleting a presentation does. So, a PR should be raised to add a section to
the specification that covers the delete credentials endpoint.

Manu Sporny: Go ahead, Joe. It's on the issuer endpoint.

Joe Andrieu: What component is it on?

Joe Andrieu: And who gets to call it?

Manu Sporny: At least it's on the issuer service.

Manu Sporny: So you can delete issued endpoints. One second. I'm looking

Joe Andrieu: I don't have any presumption that the issuer is retaining
credentials.

Dave Longley: The issuer needs to retain credentials in the case of status
for a number of different reasons.

Joe Andrieu: It doesn't need the credential though. It needs to know about
a credential for the status like

Dave Longley: That's mixed. one reason you might need the credential just
has to do with basic cap theorem. you've got partitioned systems and you
could lose a connection in the middle of something and the credential would
have to be completely reissued if it couldn't be fetched. And then there's
a number of other considerations there around the status information that
you need on a credential, especially if you have many different status
methods.

Dave Longley: You might do there might be some setup where you could retain
only some partial status information over time.

Dave Longley: But certainly right at issuance just to handle the fact that
you have partitioned systems you need to retain credentials at least for a
short period of time minimally.

Manu Sporny: There's also the right to be forgotten implementation details
like…

Manu Sporny: even if you don't store the entire credential even retaining
that you issued The credential might be something that you need to delete
and write to be forgotten. did that answer your question,…
00:55:00

Joe Andrieu: Yeah, that's a good argument for needing to delete even…

Joe Andrieu: if there's not storage.

Manu Sporny: Joe? I think it's on the issue service. because that's the
thing that would trying to figure out…

Joe Andrieu:

Joe Andrieu: Yeah. Okay. I mean the holder service should have a delete …

Manu Sporny: if we delete.

Manu Sporny: I mean,…

Joe Andrieu: because the holder UX may be talking to its back end and
saying hey I don't want this credential anymore delete it …

Manu Sporny: yeah, that's a good point. yeah.

Joe Andrieu: which is why when we went to issuing I was like wait that's
the inverse of the mental model I was thinking hold our service.

Manu Sporny: So, we need multiple things here in this PR. appear should be
raised that adds a section to the specif issuer service and the wait what
is it holder?

Joe Andrieu: I think

Manu Sporny: Yeah that's what my gut's saying.

Manu Sporny: I'm trying to Where's the what happened to the diagram H?

Joe Andrieu: Yeah,…

Joe Andrieu: that's weird.

Manu Sporny: It's on my local system. Something's weird. issuer service and
the holder service. okay.

Manu Sporny: Explain.

Joe Andrieu: …

Joe Andrieu: almost orthogonal to this, but it's the workflow that's the
caller here, not the coordinator for many of these cases. So, I think we
have some general errors where we were presuming the coordinator is
directly making the call. This is what Dave mentioned earlier. we need to
revisit all that…

Joe Andrieu: because I think the primary flow is now the expectation is the
coordinator will set up an exchange and it's actually the workflow talking
the service potentially to do this delete. I don't know if even that goes
through the workflow or not, but I think that's just reiteration of what we
already know. We need to update that diagram in some way.

Manu Sporny: Mhm. Okay.

Manu Sporny: All So, noting we're at time, I'll just go ahead and I'll mark
this as effort low. I think it shouldn't be too difficult to at least raise
a PR. all right. with that, we are at time. Thank you everyone for
wonderful discussion. As always, we will continue to go through and process
the issues to see if it's effort low or high.

Manu Sporny: And that certainly helped me pick an issue to try and tackle
more easily. we'll meet again next week. thanks everyone. Have a wonderful
week and we'll chat again next week. Bye.
Meeting ended after 00:58:43 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*