[MINUTES] VC API 2025-06-24

VC API Community Group Meeting Summary - 2025/06/24

*Attendees:* John's Notetaker, Manu Sporny, Michael Burchill, Parth Bhatt,
Patrick St-Louis, Ted Thibodeau Jr

*Topics Covered:*

   1.

   *Community Updates:* No significant community updates were reported.
   2.

   *Pull Request Review:* The majority of the meeting focused on reviewing
   and discussing several pull requests.
   -

      *PR 487 (Issue 453, 47):* Accepted the 2011 status response for
      exchange and workflow creation. The PR was merged after adding
the location
      header to both 201 and 204 responses.
      -

      *PR 488 (Issue 376):* Modernizing the verify presentation result. The
      PR needed to be revised to reinstate support for proofless presentation
      verification. Changes suggested by Dave and Ted were integrated.
      -

      *PR 489 (Issue 421):* Adding a protocols endpoint for specific
      exchanges. Discussion centered around the interact protocol and its
      integration with the interaction URL, including the iUV query
      parameter and versioning. Further clarification was needed from Dave
      Longley before merging.
      -

      *PR 490 (Issue 403):* Adding the ability to specify a presentation
      schema to the workflow step. This allows verification of input during
      workflows. The discussion involved clarifying the purpose of the JSON
      schema (for verifier/coordinator use in validating presentation
responses),
      its optional nature, and future-proofing considerations for supporting
      schema languages beyond JSON Schema (decided to use a string type with a
      type field for flexibility).
      -

      *PR 490 (Issue 407):* Adding the credential deletion section. This
      included adding details for the delete credential/ID endpoint,
      clarifying the roles of issuer and holder services, addressing
consistency
      in terminology (using "verifiable credential" instead of abbreviations),
      and handling potential conflicts between data deletion requests and audit
      requirements. Discussion included distinguishing between delete
      (revoking the credential) and prune operations (maintaining
      credential ID but removing PII). A use case was presented for maintaining
      credentials despite removing PII. The discussion also touched on the
      potential conflict between data retention requirements (e.g., for audits)
      and right-to-be-forgotten requests.

*Key Points:*

   - The meeting successfully processed several pull requests related to
   the VC API specification, with some requiring further clarification and
   revision before merging.
   - Significant discussion focused on the design considerations for
   handling verifiable presentation schemas and credential deletion, including
   balancing competing needs like data minimization, audit requirements, and
   regulatory compliance.
   - Future-proofing the specification was highlighted as important,
   particularly concerning schema language support.
   - The distinction between a full credential delete (potentially
   revoking) and a prune operation (removing PII but preserving metadata)
   was introduced and discussed.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-06-24.md

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

John's Notetaker, Manu Sporny, Michael Burchill, Parth Bhatt, Patrick
St-Louis, Ted Thibodeau Jr
*Transcript*

Manu Sporny: Hey folks, sorry for being a little late. Had another call
that went over. Looks like it's a pretty small group today. let's go ahead
and hold for maybe two more minutes. And if we don't have more people show
up, I think we'll probably have to cancel a call for today and meet again
next week.

Manu Sporny: All right, we've got four. I think that's enough to at least
review some PRs. we'll see if anybody else can join in the meantime. let me
go ahead and guess pull up the agenda real quick. go ahead and screen
share. All right. welcome folks to the VC API call for today.

Manu Sporny: we have an agenda which is basically kind of reviewing any
community developments that we want to cover and then processing a bunch of
pull requests. and then as soon as we get through those pull requests, we
can adjourn. any other updates or changes to the agenda today? Anything
else we want to cover? All right. if not, let's go ahead and do Any new
community updates that folks wanted to cover? All right. If not, let's go
ahead and jump into PRs.

Manu Sporny: we'll start with 487 accepting the 2011 status response for
exchange and workflow creation. Coyote raised this in I think has made the
modifications we asked on the last call which is putting the location
header on both the HTTP 2011 and 204 responses.

Manu Sporny: I think it was missing from 2011 and now we have it in both
places. and I think let's see 2014. Yeah, we've got it in both places now.
which I think means this is ready. does anyone see any reason why we
shouldn't merge this?

Patrick St-Louis: No, it seems to address the last comment from last week.
Socket.

Manu Sporny: I think it's got what we want in there. All right. So, let's
go ahead and prove that and pull it in. All right.

Manu Sporny: and then I'll go ahead and rebase and merge that one. And that
was issue 487 which addressed issue 453 exists and 47 that's been Closing.
All right, that's that issue. ooray. Next one was modernize the verify
presentation result. let's see.
00:05:00

Manu Sporny: There were changes requested by both Dave and Ted. So this PR
was meant to address issue 376 which was how do we structure the response
metadata for verifying credentials and verifying presentations to include
challenge verification metadata.

Manu Sporny: the PR was supposed to clarify what the return value of the
presentations verify endpoint was and we wanted to align it as much as we
could with the credentials verify endpoint. I raised a PR to do that and I
think accidentally deleted the ability to verify a presentation that didn't
have a proof, which we wanted to continue to support. so we want to make
sure that we include that. yeah. So I ended up removing this proofless
verify presentation request thing which was not good I think. don't
remember doing that but proofless verify. So I ended up removing that and I
shouldn't have done that.

Manu Sporny: So, I need to put that back.

Manu Sporny: The other Go ahead, Patrick. Yes.

Patrick St-Louis: It's probably very easy answer,…

Patrick St-Louis: but the proofless verification schema is just a
presentation without a proof as simple as that. Or is there more to it?

Manu Sporny: Nope, that's it.

Patrick St-Louis: Okay. Yeah.

Manu Sporny: It's just a presentation without a proof because not every
presentation needs to have a proof on it. sometimes you can't generate a
signature. Ted has made some suggestions. Thank you, Ted. I'm merging those
now.

Manu Sporny: set of hello for examples in my presentation. So those will go
in and then I need to go and fix the proofless verification stuff. So I
need to not remove this and not remove this which I will do in the next
pass on that PR. So that's 48.

Manu Sporny: next item add protocols endpoint for specific exchanges. this
PR tries to address 421. we were missing the protocols endpoint. this PR
adds the protocols endpoint. and there's some change requests here. looking
at the change requests. So this is the protocol's endpoint here. and then
we have a response a return object here that defines what goes in there.

Manu Sporny: one of the things that Dave Longley wanted added was this
interact protocol which would just be the interaction URL format. can be
used during exchange flows. let's see. Was that for the interact? Yeah, I
think I was wrong. this description, I think Ted was wrong. I was wrong
when I wrote it up. And it's not this at all. It's something else. I think
I'm still struggling a bit to understand how Interact works and Dave's got
some suggestions here. so maybe we implement those suggestions and come
back to this PR. go ahead, Patrick.
00:10:00

Patrick St-Louis: Where does the like was it UVI or…

Patrick St-Louis: UIV query parameter fits in there? it seems like it
should be in there somewhere.

Manu Sporny: It's in the interaction.

Manu Sporny: It's in the interact URL. So, let me try and go to the VC API
spec that Yep,…

Patrick St-Louis: And there are a few examples of exchange there's vapi ID
for VCI. I assume didcom would be another contender that could fit in there.

Manu Sporny: that's right. let me see.

Patrick St-Louis: Yeah. and…

Manu Sporny: So, we can add that if you'd like, Patrick, where here it is.
Interaction URL format. So, it's this URL that we would expect. And this
has the IUV thing in it, Patrick.

Patrick St-Louis: what does IV stand for?

Patrick St-Louis: I don't think it says that anywhere.

Manu Sporny: interaction URL version and…

Manu Sporny: you're right it doesn't Yeah.

Patrick St-Louis: And you need to put a version at the end, right? Okay.

Manu Sporny: Yeah. Or I think Yeah. And the reason for this is a bit weird
in the retail scenarios. point of sale systems scan lots of different types
of QR codes and they have jump tables in them. point of sale systems do on
trying to detect this is this type of QR code so it should go to this
subsystem and so we needed something that would give us a kind of higher
assurance that you were scanning an interaction URL versus that URL

Patrick St-Louis: Yeah, that's something I brought up myself a while ago,…

Patrick St-Louis: when an application that scans a QR code needs to know a
little bit. Sometime they want to accept more than one kind of QR code. So
it's kind of a hint for that.

Manu Sporny: Mhm. Correct.

Patrick St-Louis: So that's good. and I guess the versioning here signifies
that maybe eventually we'll have another version, but that's probably not
in scope right now.

Manu Sporny: Yeah. we've regret when we've done things and we haven't at
least provided default versions in version 10.

Manu Sporny: We've almost always regretted it. so we're just adding a
version just in case. We don't think we're ever going to need another
version.

Manu Sporny: But yeah. Yep. Yep.

Patrick St-Louis: So the interactions URL is different from the exchange
URL.

Patrick St-Louis: The exchange URL would be in the VC API protocol from the
list of protocol. Okay.

Manu Sporny: That's right. Yep. You got it.

Patrick St-Louis: And what's the slash because in the PR there's the
exchange URL protocols.

Manu Sporny: That is so this interaction URL format what you do is you do a
get on this and…

Patrick St-Louis: Okay.

Manu Sporny: then what you get back is a protocols object but at least I
think in the digital bazaar implementation you can get this object back

Patrick St-Louis: By adding slash protocols on the exchange.

Manu Sporny: by just adding slash protocols at the end of an exchange.
Exactly right.

Patrick St-Louis: Yeah, I think that's…

Manu Sporny: Yep. Mhm.

Patrick St-Louis: what on the VC playground currently. I think okay.

Manu Sporny: Mhm. let's see.

Patrick St-Louis: And so this interaction URL is meant to maybe replace
that behavior and really put the exchange out of this interaction URL.

Manu Sporny: I was trying to parse your question.

Patrick St-Louis: So that this interactions the goal is to replace that
behavior that you have the exchange/protocols or…

Manu Sporny: No, I don't.

Manu Sporny: No, I don't think So, this is where I'm getting this is what I
don't quite understand about what Dave Longley is saying, Patrick. I don't
understand why he is saying we it feels circular to me, Patrick. So, that's
why I'm kind of like

Patrick St-Louis: Now it seems there's two way to do the same thing.

Manu Sporny: Yeah. Correct.

Patrick St-Louis: the only difference is that the exchange doesn't have
that query parameter which this is where the interaction URL becomes useful
because that has this query parameter Seven.

Manu Sporny: Yeah. You could I think the way I'm thinking about it right
now and I don't know if this is correct is that this giant long thing here,
right, is the thing that you query to get this protocols object back. But
this interaction URL thing is like a tiny URL service for the URL, right?
00:15:00

Patrick St-Louis: Okay. okay.

Manu Sporny: because this needs to go in a QR code, we want it super
compact and…

Patrick St-Louis:

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: in order to make it compact,…

Patrick St-Louis: Yeah.

Manu Sporny: we map it and all that kind of stuff. but what we could do is
just provide we could just use this URL with question mark iUV at the end
of it and get a protocols object back.

Patrick St-Louis: Okay.

Manu Sporny: So I think what we're I and…

Patrick St-Louis: And…

Manu Sporny: again I'm just guessing I go ahead.

Patrick St-Louis: yeah the interaction URL is sort of to a way to create
small QR code or…

Patrick St-Louis: shorter footprint link.

Manu Sporny: Yep, that's right.

Manu Sporny: Yep.

Patrick St-Louis: Okay, that would make sense as a framing. Yeah.

Manu Sporny: You don't need to do it, but we're providing a mechanism
because, maybe these URLs can get crazy long and you want a smaller mapping
mechanism. okay.

Manu Sporny: So, going back to the PR, I think I'd like a little more
clarification from Dave Longley about what to make, change. I'll go ahead
and update the PR based on what Dave mentioned and then see if that's
aligned with what he was thinking and if that makes, sense and that sort of
thing. But everything else, I think, should be ready to go on this Any
other comments on 489 before we move on? All right. If not, let's go to
pull request 490. Add ability to specify presentation schema to the
workflow step.

Manu Sporny: this was an attempt to address issue number 403 because we
were missing the ability to specify, what the presentation schema should
look So, the issue here was when you're going through a workflow, you want
to verify your inputs. and this was a way of verifying the input
specifically what was presented during the workflow.

Manu Sporny: I added the option. I think Dave said that he would also like
to see a verify presentation response schema so that when somebody Let's
see what was this. There's a request and a response. We only had it for the
request. We didn't have it for the response, I think. go ahead, Patrick.
Yeah.

Patrick St-Louis: Who is meant to use this JSON schema? Is it the verifier?
Okay. …

Manu Sporny: Yeah. it's the verifier coordinator it's really the verifier
service or it's really the exchange service, is configured to use specific
schemas as it is working as it's moving somebody through a workflow. It's

Patrick St-Louis: because I was wondering why isn't this for example the
query by example, something from the VPR verifiable presentation request
spec.

Patrick St-Louis: And why a JSON schema?

Manu Sporny: So the VPR is the request that goes out to the holder and…

Manu Sporny: then they're going to respond back with a presentation to you
and…

Patrick St-Louis: Yeah. Right. Mhm.

Manu Sporny: this JSON schema is to verify that presentation. So, you're
going to make a request to the holder and the holder is going to respond
back with something and the thing we're talking about is okay, they just
gave you something. How do you validate that that's what you were supposed
to receive? And so, there'll probably be some kind of cryptographic
verification, a step one. and then you'll do a JSON schema verification to
make sure that all the data fields that your system needs,…

Patrick St-Louis: Right. Okay.

Manu Sporny: are there.

Manu Sporny: And then once that verification passes then you will pass it
on to the business logic in your system so that the business logic in can
then kind of execute what it needs to based on the fields that had to have
been there per the ation schema. run again run against the result of
verifying a presentation. And I think what Dave's asking for here is he's
like, "Okay, so you're going to take the response so you're going to,…
00:20:00

Patrick St-Louis: Mhm. Yeah.

Manu Sporny: you're going to use a VPR.

Manu Sporny: You're going to query The holder is going to return a response
to you. You're going to use the presentation schema to ensure that that's
wellformed. And then either before or after you do that, you pass it to the
VC API to do the actual verification. And you're going to get a result from
that back that you're expecting to have certain properties. for example,
you in your JSON schema, in the call to the VC API and what you get back,
you are going to expect that there's a status list and it was checked and
it's valid.

Patrick St-Louis: And this ties to the other PR about modernizing the
presentation response that Yeah. Okay.

Manu Sporny: If that makes sense. Yep, that's all right.

Manu Sporny: You don't have to use it.

Patrick St-Louis: And these are optional because JSON schema is one way to
validate this but this is doable with just code and classes and…

Manu Sporny: Exactly. Yep.

Patrick St-Louis: yeah okay yeah this is a sort of a explicit standardized
way Okay.

Manu Sporny: You got it. So, it's basically like if you want to offload
some of this to the API, you can do that. But if you're like It might be.

Patrick St-Louis: And what is the point of having a type that says it's a
JSON schema? I think Ted put a comment to that. What's the type of the
purpose of having a type that says JSON schema if the property is called
JSON schema?

Manu Sporny: So in the future. The presentation schema doesn't have to be
Jason schema.

Manu Sporny: could be like shackle or…

Manu Sporny: I don't know some shape language or some other custom thing
that your implementation does like YAML schema or…

Patrick St-Louis: Right. Okay.

Manu Sporny: whatever. I think that's the thinking here. But I think Ted,
your question. yeah,…

Manu Sporny: Ted, this is a good question and say it's the same kind of
question that Patrick has if it's not Jason schema? What if it's something
else?

Manu Sporny: Yep.

Patrick St-Louis: should be called just schema and…

Patrick St-Louis: then whatever you put in the type defines what the
schemas should be expected.

Manu Sporny: That's one way that we could do this. Yeah. I think that's a
legitimate way of doing that. I guess then it's like because JSON schema
can be a JSON object. whereas if it was YAML, it would just be a text
string. So all of a sudden this thing stops being an object and then what
is it?

Patrick St-Louis: Yeah. Yeah,…

Manu Sporny: What is it? Right? Is it just a string?

Manu Sporny: You see what I'm saying? Mhm.

Patrick St-Louis: definitely.

Ted Thibodeau Jr: It does make it more complex to handle more ways of doing
it,…

Ted Thibodeau Jr: but the more ways of doing it exist and so there has to
be some kind of handling of them.

Patrick St-Louis: I don't know

Patrick St-Louis: if the schema should just always be string that's
serialized depending on the type. Is that too complex? I mean JSON schema
like I agree it's nice because it just is making a string complicating this
for nothing? yes,…

Ted Thibodeau Jr: I think it's future proofing. It's

Manu Sporny: Yeah, that's a good question.

Patrick St-Louis: Yeah. But if we want to do other format, I think it makes
sense that even if it's a JSON schema to just stringify it,

Manu Sporny: Mhm.

Patrick St-Louis: I know it can get a bit funny sometime with the escape
characters and stuff, but that's just the way it is.

Manu Sporny: Yep. I don't have a strong feeling one way or the other. I
think they're good arguments to either but if we decide, so the question
is, do we want to future proof this meaning that in the future, maybe we're
hard coding it to JSON schema now…

Patrick St-Louis: Mhm.

Manu Sporny: because that's what we expect to be the primary use, but in
the future, we could just add a, YAML schema or…
00:25:00

Manu Sporny: a JCR schema or something. and each one of those would decide
whether it's an object or a string something. That's one way that we could
future proof. The other way is to just say there's a type in a schema and
it's always a string and the type determines how you parse that string.

Ted Thibodeau Jr: I think that's the easy way,…

Ted Thibodeau Jr: even though it seems more complex.

Manu Sporny: So I think we have agreement Michael's plus oneing that as
well.

Manu Sporny: Part as All So, we will go that route unless we get any push
back. yeah.

Patrick St-Louis: And the route is going with a string,…

Patrick St-Louis: right? Okay.

Manu Sporny: I think the rat's going with the string.

Patrick St-Louis: What about would the data URL be overkill here?

Manu Sporny: The change the name to schema and the type to string.

Patrick St-Louis: Does that make sense?

Manu Sporny: I don't know if all schema languages have a corresponding
media type is the only thing I hesitate at.

Patrick St-Louis: Yeah. Yeah. No, I think string makes sense. because yeah,
it's simple. You read the type string and…

Patrick St-Louis:

Ted Thibodeau Jr: It could…

Manu Sporny: Mhm. Yeah.

Ted Thibodeau Jr: then be coerced into whatever else they want.

Ted Thibodeau Jr: And this allows experimentation and evolution without us
having to change it on spec. That's

Patrick St-Louis: Yeah. …

Manu Sporny: And it's not B 64 encoded. That's the other downside of making
it a data URL.

Michael Burchill: Yeah, I agree.

Manu Sporny: All right. good. Okay.

Patrick St-Louis: another question just quickly these different types like
JSON schema. Okay, we can get a guess what this is, but is there going to
be an official sort of if I get something like Typescript …

Patrick St-Louis: what am I expecting to have code in the schema or…

Manu Sporny: I mean,…

Manu Sporny: who knows, I mean,…

Patrick St-Louis: Yeah. So these types Yeah.

Manu Sporny: meaning we don't know, but the thing that has to exist is
there has to be a spec that defines what the type is and how to exactly.
So, it'll either go in the VC API spec or…

Manu Sporny: there'll be an extension spec that defines a different schema
language that you can use with the VC API. Does that address your concern,
Patrick? All right.

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: Yeah. That's exactly it. Yeah.

Manu Sporny: So, based on that, I think we'll make this change up here to
use just a schema as a name and string.

Manu Sporny: And then we'll add the other feature that Dave wanted which
was to a schema to verify the result of the VC API call that does
verification a cryptographic status list challenge that sort of thing. and
so we'll get those changes in and look at this again next week. All right.
last pull request is add the credential deletion section. this is issue 407
which said that the details of the credentials the delete credential/ ID
endpoint should be added.

Manu Sporny: We discussed this and said that we should add a section that
covers the delete credentials ID endpoint in the issuer service and the
holder service. And then we should explain why delete services are needed
to support things right to be forgotten. I raised a PR to do that. so
here's where we add the expected call callers as the issuer coordinator and
the holder coordinator to the delete service. I also had to go in and add
some definitions for issuer service and…

Ted Thibodeau Jr: That's

Manu Sporny: verifier service. We didn't have those. I'm going to scroll
back to your change requests. Ted, Yeah, this is doing all the service
modifications. and then is this still doing changes to the workflow? here
here and then it adds the delete specific credential section and links to
and adds the kind of API detail section there. Okay.
00:30:00

Manu Sporny: going back to the change requests, Ted, you had mentioned that
we should clearly be consistent in how we talking about verifiable
credentials versus VCs and all that kind of stuff. I totally agree with
you. This section was written and is totally not consistent with the rest
of the specification. I'm going to suggest that we follow a pattern that
allows us to easily link to the terminology which means spell out
verifiable credential completely use the square bracket equal sign syntax
for it and don't abbreviate anywhere that's what we do in I think all the
other specs so to keep that pattern again to reduce

Manu Sporny: the number of AC u acronyms that we're using in the
specification. let's see there is a link to webkms…

Ted Thibodeau Jr: Where is it being done? Wow.

Manu Sporny: but it is going to stay non-normative for a very long time. So
I hesitate to pull that in though we do talk about it here. webcams in
theory the CCG CCG we haven't touched this spec in four years right but it
specifies all of the ways to integrate with a web-based key management
system including the HTTP APIs the general

Ted Thibodeau Jr: That's kind of important stuff.

Manu Sporny: generate wrap keys, things like that. And the problem is that
the HSM industry is incredibly insular and they don't like standardizing
stuff because it ensures that people stay locked into their weird APIs. so
we've had a big challenge trying to get HSM vendors to try and standardize
on something that would increase competition in that space. because all the
HSMs these days are either PKCS11…

Manu Sporny: which is like what 15 20 years old at this point and pretty
long in the tooth.

Ted Thibodeau Jr: Yeah. I'll buy that.

Manu Sporny: Or a AWS is like no we're totally fine with people using
proprietary AWS APIs to access our proprietary AWS HSM. so I think this is
the webcams spec is I think a matter of picking the battle at the right
time and we've got many other things that we're trying to get done.

Ted Thibodeau Jr: But it means that we shouldn't link to it either. I mean,…

Manu Sporny: Yeah. Yeah.

Ted Thibodeau Jr: or find some way to say this thing that is very immature
and going to stay that way, but is a useful reference.

Manu Sporny: And so I think we can just…

Manu Sporny: then delete the last part here,…

Ted Thibodeau Jr: Yeah, that will work for me.

Manu Sporny: All right. So we'll do that. this is fairly straightforward
grammatical changes. So Ted, I didn't ask Is it okay if we just use spell
out verifiable credentials all lowercase and…

Ted Thibodeau Jr: Yep. Consistency is the big thing and…

Manu Sporny: use the All right. I'll try to make a pass to do that.

Ted Thibodeau Jr: I don't care what the consistency is.

Manu Sporny: All right. Sounds good. we'll do that. business rules. yep.
I'll make these changes. Yep. That looks good. To that one. Okay. All right.

Manu Sporny: So all the editorials that you had Ted look good to me and…

Ted Thibodeau Jr: No worries.

Manu Sporny: I'll try to integrate those. I'll merge them down and then
I'll do another pass to expand the Cs into verifiable credential. And then
finally Dave Longley is wondering about a prune operation. And so not a
delete where you delete absolutely everything but a prune where you
continue to remember the credential ID which should have no PII in it in
status information so that you remember the minimum possible necessary to
at least flip the status bit.
00:35:00

Manu Sporny: I think the functionality that we'd need here is that if you
deleted a credential with a status bit that it would maybe be delete, maybe
the status bit would be flipped in the process. go ahead Patrick.

Patrick St-Louis: That's what I feel is missing. deleting the credential is
one thing but in my opinion it should also include deleting any related
information about that user potentially if it's the right to be forgotten
the credential is one thing but there's other user information in the
system and I would think that I don't know but I would think the credential
would also be revoked maybe I'm wrong maybe that's

Patrick St-Louis: not the right way to go about it. if a credential is to
be deleted yeah I don't know maybe there's too many scenarios to configure
to make that bold statement but yeah

Manu Sporny: Yeah. Yeah.

Manu Sporny: Yeah, I guess the delete operation would provoke and the prune
operation would not. I think if I follow Dave's suggestion to I think the
logical conclusion is, I think that's how it would work for at least the
revoke versus not re and then you make a good point, Patrick. What do you
do if there's any linked information?

Manu Sporny: It feels like that part of it might be business logic, meaning
it's something the coordinator needs to deal with. It's not something the
issuer deals with because the issuer doesn't really know about more complex
like credential relationships and other things of that nature. Michael, you
raised your hand. Thoughts? Okay.

Michael Burchill: You hit on it there right at the end, so I took my hand
down. Don't worry about it.

Manu Sporny: Sounds Okay. So, let's see. The group discussed some of this
on the call.

Manu Sporny: 256 24 call six 24 call. and came to the difference between
delete and rune is that the ladder does not revoke revoke.

Manu Sporny: credential former let's see the difference between does not
the former revokes the credential deleting any higher level linked
information is the responsibility of the issuer coordinator and…

Manu Sporny: not the issuer service. go ahead, Michael.

Michael Burchill: Yeah,…

Michael Burchill: I just wanted to add we over at Creative Vera actually
already see a use case for this because we do a lot of high-risk workplace
and if we were to say remove the person's personal information, we might
still need that credential to exist on an inspection report. So we couldn't
actually get rid of the entire credential.

Manu Sporny: Got it.

Michael Burchill: So this is great.

Manu Sporny: Okay, that's a perfect use case for why we'd need this. So,
thank you for that. Patrick, I think you had your hand up. Okay.

Patrick St-Louis: No, it's fine.

Manu Sporny: Let's see. deleting might not be a good option if there are
audit requirements especially due to regulatory burdens. Okay.
00:40:00

Manu Sporny: So, I'll make a pass and…

Manu Sporny: update those things. Go ahead, Patrick. That's right.

Patrick St-Louis: Does that mean that a audit requirement would take
precedence over right to be forgotten?

Patrick St-Louis: Meaning if a individual wants to be forgotten, they will
still need to keep some of his information for auditing.

Manu Sporny: Yeah, that's typically how right to be forgotten works is that
regulatory burdens override right to be forgotten.

Patrick St-Louis: Yeah.

Manu Sporny: And in some cases the conflict happens in a really nasty way.
U meaning it's not a very clear answer on what the organization holding on
to that data should do because they're going to be in trouble both ways,
right?

Manu Sporny: they've got a request and the person's saying they're
insisting right to be forgotten and then the regulations say sorry you have
to hold on to that data for seven years and then the individual is sues
anyway because they're like I don't agree with the regulation and then it
becomes the poor company's trapped in the middle of that and then legal
teams need to come in and…

Patrick St-Louis: No.

Manu Sporny: provide a legal opinion about which one overrides and that is
something that they leave up to the courts to decide. so it ends up
becoming a very expensive question to answer. All right. I think that's our
last PR for today. Are there any other items Any other business folks want
to discuss today?

Manu Sporny: All right. If not, really appreciate everyone's attention
today to the PRs and PR processing. we'll try to raise a couple more PRs
for discussion next week and clean up these current ones and then get them
merged over the next week or…

Ted Thibodeau Jr: All right.

Manu Sporny: so. All right, thanks everyone. Have a wonderful rest of your
week and we'll talk again next week. Take care. Bye.
Meeting ended after 00:42:17 👋

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