- From: <meetings@w3c-ccg.org>
- Date: Tue, 3 Feb 2026 19:02:56 -0500
- To: public-credentials@w3.org
- Message-ID: <CA+ChqYcDQ5EvLdcwNJq+_n4UMa+2p6sxMSq0ZZcWf6oKPGZWPg@mail.gmail.com>
Meeting Summary: W3C CCG VCALM
*Date:* 2026/02/03 *Time:* 14:58 EST
*Attendees:* Dave Longley, Elaine Wooton, Eric Schuh, James Easter, Joe
Andrieu, John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Patrick
St-Louis, Ted Thibodeau Jr
Topics Covered:
-
*PR 584: Add links to component tables*
- This PR adds links to component tables within the specification to
improve navigation and cross-referencing to endpoint definitions.
- A minor suggestion was made by Manu Sporny to improve the link text
formatting for better readability, which Eric Schuh agreed to test.
- The PR is dependent on a corresponding PR in the OAS respect repo.
- Eric Schuh was added as a maintainer for the respect-vc repository,
along with Patrick St-Louis and Joe Andrieu.
- The merge of this PR will be held until the dependent PR is merged.
-
*PR 573: Managing list for the status list service*
- This PR adds non-normative text to the specification regarding the
management of status lists.
- The text has been moved from an appendix to within the
specification itself, clearly marked as non-normative.
- Discussion included whether certain aspects of the status list
management (e.g., updating status) could potentially become normative in
future versions.
- A point was raised about the response for creating a status list,
with suggestions to consider returning a 204 with a location
header instead
of the full list, mirroring other spec patterns.
- The discussion on the exact response for the create status list
endpoint will be deferred to a new issue.
- The PR will remain open for review, with a potential merge next
week if no further objections arise.
-
*PR 575: Refactor of Accepted Crypto Suite and Accepted Envelope Fields*
- This PR addresses inconsistencies in how accepted crypto suites and
envelopes are defined, allowing for arrays of strings and objects.
- The field "authority" has been changed to "accepted issuers" to
better reflect its purpose.
- The PR was approved and merged after a clean commit history was
confirmed.
-
*Draft PR: Support for different versions of OID for VP*
- This PR aims to support multiple profiles of OID for VP within a
single implementation, accommodating different parameter requirements.
- The open_id field can now either contain all parameters directly or
include a client_profiles field for defining different configurations.
- Outstanding items include the addition of presentation_definition
and dcql related fields, and the inclusion of examples.
- Dave Longley suggested that the presentation_definition and dcql
fields could be added in this PR, with examples deferred to a
separate PR.
- The redirect_uri field will be retained as it is considered
customizable and necessary.
- The PR will remain open for further review and discussion on
outstanding items.
-
*Issue 575: Explicitly specifying Verifiable Presentation in a step*
- This issue proposes documenting a feature to explicitly specify the
Verifiable Presentation to be included in a particular step,
rather than it
being implicitly generated.
- This allows for the inclusion of out-of-band credentials or
credentials issued through other means.
- The discussion highlighted that this change aims to make the VCOM
spec more compositional and explicit.
-
*Issue 583: Explicitly specifying Issue Requests*
- This issue proposes making issue requests more explicit within a step,
allowing for control over where issued credentials are stored or
delivered.
- This enables greater composability, allowing for credentials to be
stored for later use in other steps or delivered via out-of-band
processes.
- Both Issue 575 and 583 are related to making the VCOM spec more
compositional and explicit. These will be further discussed and
potentially
addressed in future PRs.
Key Points:
- The meeting began with a brief technical issue regarding screen
sharing, which was resolved.
- Elaine Wooton introduced herself, sharing her background in identity
documents and standards from her time at DHS, and her current interest in
verifiable credential barcodes and the broader spectrum of physical to
digital identity.
- The W3C Verifiable Credentials Working Group charter vote was
mentioned, with a call for W3C members to vote.
- Discussions on PRs focused on improving the specification's clarity,
navigability, and composability.
- There was a recurring theme of making aspects of the specification
more explicit and allowing for greater flexibility in implementation.
- The meeting successfully closed one PR and identified two more that
are nearing completion.
- The introduction of Elaine Wooton and the discussions on PRs 584, 573,
and 575, along with the introduction of issues 575 and 583, indicate
progress in the specification development.
Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-02-03.md
Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-02-03.mp4
*CCG VCALM - 2026/02/03 14:58 EST - Transcript* *Attendees*
Dave Longley, Elaine Wooton, Eric Schuh, James Easter, Joe Andrieu, John's
Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Patrick St-Louis, Ted
Thibodeau Jr
*Transcript*
Patrick St-Louis: Hey, Ted.
Ted Thibodeau Jr: Good day. How are you?
Patrick St-Louis: Pretty good. How about you?
Ted Thibodeau Jr: Keep Keeping on.
Patrick St-Louis: Can you remind me what time zone you're in? Are you
Eastern?
Ted Thibodeau Jr: I'm Eastern. Yep.
Patrick St-Louis: So, good afternoon then. Welcome Parth and Elaine.
Parth Bhatt: Hello global greetings.
Elaine Wooton: Hi everyone.
Patrick St-Louis: Elaine, would you be comfortable when the meeting start
to introduce yourself? I'd be curious to learn more about what you're
working on. I've seen you attend the call in the last few weeks and I'd be
interested in learning more about you.
Elaine Wooton: You bet.
Elaine Wooton: Just tell me when.
Patrick St-Louis: Yes. Yes.
Patrick St-Louis: We'll get the call started that we'll give a few minutes
for people to come in and we always have a little sort of introduction
section at the beginning. So We're just going to wait one or two minutes,
let people trickle in.
Patrick St-Louis: Welcome Eric, Dave, James.
Patrick St-Louis: Welcome to the call.
Joe Andrieu: Thank you.
Joe Andrieu: Hello everyone.
Patrick St-Louis: We'll get started in a minute.
Patrick St-Louis: Okay, let's get it started. If people keep joining, they
should be able to catch give me one second. Just going to open the page for
the call. I forgot to do share my screen. Okay.
Patrick St-Louis: Welcome everyone to the W3C credential. my browser is not
happy with my screen share. Give me a second. I don't usually have this
little error notification.
Elaine Wooton: No,
Patrick St-Louis: Let's try again. Can anyone see my Something went wrong
when screen sharing. Try restarting your browser. I will be right back.
Hopefully won't kick anyone out of the call. I will just restart my
browser. I apologize for this. It's the first time I see this error. If you
get kicked out of the call, please just join back.
00:05:00
Patrick St-Louis: hey u. I'm getting a screen sharing error and Chrome is
telling me to restart my browser. So, I will If it kicks you out, just join
back and we'll get it restarted. Sorry for this.
Joe Andrieu: Patrick is still having problems.
Eric Schuh: I suppose I could start going through the PR I put in if we
wanted to just get something moving while we wait for Patrick to get back.
Joe Andrieu: Sounds like a lot of support for that. Eric
Eric Schuh: Yeah, one second.
Eric Schuh: Just getting my screen share set up. Okay, so the PR I put in
today is this add link links to component tables number 584. this is in
response to this open issue.
Eric Schuh: Sorry.
Dave Longley: Just for front matter,…
Dave Longley: Eric, we probably want to say this is a CCG call for BCOM
that it's recorded and…
Eric Schuh: Yep. sure.
Dave Longley: autoranscribed and follows the community guidelines. I don't
remember any other front matter that anyone else can remember to repeat.
Joe Andrieu: Yes. just that if you do not want to be recorded, this is your
chance to speak up.
Joe Andrieu: If you continue with the call, we will accept that as
confirmation that you're okay with the recording.
00:10:00
Eric Schuh: Okay, hearing no objections at the moment.
Eric Schuh: So this issue was opened a while ago when I updated the
component tables last. Monu, I think it was you that suggested we might add
links in these tables to each of the endpoint definitions. So you'll see
here I've added a link to all of these tables. I've gone through all of
them and clicked. we can do it on the call, but you'll see it takes down to
the further sections. in terms of how this looks, it's fairly
straightforward. I did just want to go over a couple of things in the
changes. Yeah, whoever raised their hand,…
Eric Schuh: go ahead.
Manu Sporny: Yeah, that was just me.
Manu Sporny: This is great. Thank you very much for doing the One
suggestion is for the last column, I'll put this in the change or the
comments. we might want to say at the top section or defined in or
definition and then we can use the triple square bracket notation to name
the section in which it's so it would read 311 issue coordinator you get
endpoint expected caller and…
Manu Sporny: then it would say defined in section 4.5 interactions or
something like that.
Eric Schuh: Okay. …
Eric Schuh: Yeah, I guess that's probably touching on part of what I wanted
to go over. I think Monu in terms of the way I was able to get this working
which the best so because each of these sections is just listed in the
index.html as a header for right as you can see this get a specific
credential I believe is linked to from
Eric Schuh: right here. Yeah. So, because these names were specific just
header fours, couldn't find at least I didn't see a great way in respec to
generate these links from the existing YAML. So, I ended up coming in and
having to add an extra X dash component to each of these. in terms of the
formatting and the respec which I had open I thought right here yeah right
now I am just using an href. So I think updating this I'm not sure how your
suggestion monu would actually work. I guess I'd have to look at it some
more. but if I there might be an easy way to do what you just suggested.
Eric Schuh: Go ahead.
Manu Sporny: Yeah. …
Manu Sporny: yeah, thank you. I totally forgot that we're using code to
generate the spec here, which complicates things. I think you might be able
to just in that code bracket just use three square brackets before the hash
and…
Eric Schuh: Mhm. Yeah.
Manu Sporny: then three square brackets after the curly brace and that
should work. It should be a fairly simple change and…
Eric Schuh: I can revert to this and…
Manu Sporny: it should be fairly simple to test. And if it doesn't work
then it's like exactly. Yeah. it's just a minor nit
Eric Schuh: yeah. Yeah,…
Manu Sporny: if it becomes difficult forget it right what you have is fine.
Eric Schuh: if it's that simple and people are willing to just be patient
for a moment, I think I might be able to do that real quick, just give it a
test.
Eric Schuh: Okay, I'm not dealing with any caching issues.
Eric Schuh: Because I left that. Sorry.
Joe Andrieu: Manny, did you mean to use the curly or…
Joe Andrieu: the square brackets as the text of the link tag?
00:15:00
Joe Andrieu: Is that their brush?
Manu Sporny: No, what…
Manu Sporny: what it should do is respspec should come in and take the
anchor, go and look up the human readable text and then insert the human
readable text as the section section 3.4.5,…
Manu Sporny: 4.5, that should work in theory. but it's probably caching
something somewhere. yeah.
Eric Schuh: Yeah, I opened up a new private browser,…
Eric Schuh: so I was hoping that that would prevent the casting problem,…
Manu Sporny: Yeah. I wouldn't worry too much about it.
Eric Schuh: but yeah,…
Manu Sporny:
Manu Sporny: I mean,…
Eric Schuh: I can test this later.
Manu Sporny:
Manu Sporny: we can go in and I mean, I think that overall what you did was
fine and we can just go in and change it later as an editorial thing.
Eric Schuh: Yeah, definitely getting cached somewhere.
Manu Sporny: Yeah, there you go.
Eric Schuh: I'll give that a try, Monu, and if it looks good in the table,
I'll make that change to the OAS respect PR.
Manu Sporny: Yep. Great. Thank you.
Eric Schuh: Yeah, that is the entire PR.
Eric Schuh: I think that my main question for the group in terms of
discussion for this is whether or not this pattern of sorry adding another
xdash component to support these tables is worth the overhead in the YAML.
I'm not sure how convoluted these YAML files might be read but yeah, I
think that's my only question to the group is this worth the overhead for
those links? Go ahead.
Manu Sporny: I think it's fine. I mean, we are abusing OAS, to a certain
degree here. So, I think it's fine. because regular tooling won't pick it
up and use it. And it's just something we're doing to make it easier to
cross link everything.
Manu Sporny:
Eric Schuh: Okay. …
Eric Schuh: I guess I'll give space for any other opinions real quick. the
one last change just wanted to go over is that I did add a comment before
each one of these headers. Just noting that if we update the headers, we
then need to go into the OAS file and change the corresponding endpoints
link reference. Ted, I did want to thank you for catching my copy paste
error and then taking the task of going through the TDM of updating all 20
something of these. but yeah, I think that is this entire PR.
Eric Schuh: So any final comments, questions, or concerns? …
Patrick St-Louis: I just want to say I'm back. perfect.
Eric Schuh: then I think I can hand it back to you, Patrick. We just went
through PR 584.
Patrick St-Louis: So I was there for a good part of the overview. does
anyone have any further comments to the PR about adding links to the
component table or is there any objection to merging this? Okay. So, I will
go ahead and merge it.
Joe Andrieu: Hold on.
Patrick St-Louis: Is my Yes.
Joe Andrieu: Were we going to try and…
Joe Andrieu: change the link text or we're going to do that as another
issue?
Eric Schuh: I'd say either or.
Eric Schuh: Patrick, I think the one reason we would not want to merge
right away is because the pull request in the OAS respect repo needs to
also be accepted for this to work.
Eric Schuh: Which I think Manu or Dave, I think you two have that repo
under,…
Manu Sporny: We need Yeah,…
Eric Schuh: right? Okay.
Manu Sporny: We need to put you on in control of that thing so we don't end
up blocking you. so let me try to
Eric Schuh: So, I think Patrick maybe hold off on closing this right now
and then once I test out this one change, the one change Monu suggested,
I'll either push to both I'll either mark both of these as ready for merge
or just do it myself if I have the ability.
Patrick St-Louis: Thanks. Yeah,…
Patrick St-Louis: sounds perfect. Sorry, I totally missed that part about
the dependency.
Eric Schuh: Yep, you're all good.
Patrick St-Louis: So, we'll wait until this is addressed and then review
next week. So, let's do this are we good on this?
00:20:00
Patrick St-Louis: PR
Manu Sporny: Real quick,…
Manu Sporny: I added you, Eric, as a maintainer for respect VC. Joe, do you
want that as well? I'm happy to add anyone that wants to take on the
maintenance burden there.
Joe Andrieu: Yes,…
Joe Andrieu: we may as well. I'm dealing with some other mermaid issues.
trying to understand how we're using mermaid and…
Manu Sporny: Okay. Yeah.
Patrick St-Louis: Could you add me?
Joe Andrieu: respec is so
Joe Andrieu: Yes. heat.
Manu Sporny: All Added you and Eric have maintained priv.
Patrick St-Louis: I'm thinking about code examples, and I think we had some
ideas of maybe finding a way to represent these in respect.
Manu Sporny: Yep. Yep. There you are.
Patrick St-Louis: Okay, perfect.
Manu Sporny: Maintainer as All three of you have been added.
Patrick St-Louis: Sounds good. Okay, let's carry on. So again, I'm really
sorry guys. don't know what happened, but we are at the mercy of the
software that we use and nothing quick computer restart couldn't fix. So, I
was hoping to so I was talking to Elaine right at the beginning of the call
and I was hoping maybe a quick introduction. I've noticed you've joined the
call in the last few meetings and I'm interested in learning more about
what you're working on and yeah are you comfortable Elaine to give a brief
introduction? No.
Elaine Wooton: Yeah, you bet. I'm even gonna turn the camera on. but
there's no camera, so let's see. Okay, there we go. all right. So, I'm
Elaine Wooten. I was a Department of Homeland Security employee for 33
years. I retired last year. I worked in a crime lab. I dealt with identity
documents. I worked on standards for forensic science quite a bit, so I'm
familiar with working on standards. At some point, I got sucked in by
Anneil John and Manu.
Elaine Wooton: and so while I was still at DHS, I did a little bit with
verifiable credential stuff. but I intended when I retired to do a lot
more. So I put in to be an invited expert. My main interest is in the
verifiable credential barcode because it ends up on the physical documents.
But I've sort of pivoted and I'm interested in the entire spectrum from
physical to digital and sort of what we do in between. And the reason I'm
jumping on as many of these calls as possible is that in Coobe I did
volunteer to do the editor for verifiable credential barcode in the
recharter and I'm trying to figure out how this works. So I'm just getting
on all of the calls and seeing how the process works. and some of the calls
I'll stick with and some of them I may not.
Elaine Wooton: But I'm hoping, I'm cramming for how to do W3C.
Elaine Wooton: That's it. And I'm glad to meet the people I haven't met
before. I was in Coobe, so I have met some folks. And I also go to IIW, so
I've met folks there, too. thanks for the welcome. Yeah.
Patrick St-Louis: Interesting.
Patrick St-Louis: We probably saw each other at IW without, introduction
because I went there a couple of times. congratulation on your retirement.
it's always a great milestone, I would assume. yeah, this is very
interesting. I'm assuming at some point so right now we're kind of working
on workflows and so on, but at some point there will be discussions more
catered around barcode or some specific sort of element. Definitely. yeah,
thank you. Yes, Mario.
Manu Sporny: Yeah, on that while we're there and of course welcome Elaine,
wonderful to see you on so many calls. on the barcode stuff, there is a
part of the API that we've been using to issue the verifiable credential
barcodes. but I wanted to also mention the next verifiable credential
working group charter is It's out for charter vote and it's a 30-day voting
period. I did send this to the credentials community group yesterday.
Manu Sporny: so if you know of a W3C member who hasn't voted yet, please do
get them to vote. we're looking, you try to get around 25 companies to vote
in favor. right now I think we're sitting at 12 after a couple of days. So
it's okay, but we really want to get those numbers up there. So hound any
W3C member company to get them to vote for the charter because that's the
charter that has verifiable credential barcodes firmly in scope and then
the verifiable credential API work firmly in scope. that's it.
00:25:00
Patrick St-Louis: Yeah, since you bring this up. So I did have a look at
this yesterday. I get this message here, but I don't see anywhere that I
can sign in. So I'm trying to figure out Okay.
Manu Sporny: W3C members can vote.
Patrick St-Louis: That's okay.
Manu Sporny: So if you're an invited expert, you can't vote because
fundamentally they're like you're not paying dues and…
Patrick St-Louis: Okay. Yeah. Yes. Yes.
Manu Sporny: because of that yada yada.
Patrick St-Louis: Yes. Yes.
Manu Sporny: But right…
Patrick St-Louis: I had one question when I was reading is this the right
name here?
Manu Sporny: but both you and Elaine I think are invited experts in the
next group. So you don't have to worry about that.
Patrick St-Louis: API for life cycle management. I feel like there's maybe
something missing in there or…
Manu Sporny: Yeah, they missed the VC part of it. I guess we all missed
that.
Patrick St-Louis: Okay.
Manu Sporny: But it's fine. I think everyone…
Patrick St-Louis: Yeah. Yeah.
Manu Sporny: because the charter specifically links to the specification.
it's very clear what document they're talking
Patrick St-Louis: Yeah. Yeah. that's good. Just because I was googling
there's other sort of API management at W3C that are not about credentials.
So, okay. I just wanted to highlight this. Seems like it's so yeah, let's
continue. I had a brief suggestion of a topic, but I think since we're
already quite late in the meeting, maybe I'll defer to the next meeting. I
wanted maybe to touch just about offline use case and where the things are
at for these use case when it comes to VCOM. but I will defer to probably
next week so we can keep processing PRs. So let's resume with the PR
reviews. There are a few
Patrick St-Louis: let's go in the order that they are or are we okay if we
jump to 573 which is one of the oldest one that I did update. so yeah let's
just go with this one. So this one was about manage adding some
non-normative text about managing list for the status list service. so we
had a few back and forth with this PR. we had moved the section in
different places. The last thing we landed on was to actually have it not
as an appendix but put it in the specification but make it a sort of a
non-normative text. So I will go over the latest version that I've just
updated today.
Patrick St-Louis: so if we look at the status service, I've just made these
change, so maybe people didn't have enough time to review. However, I think
it's kind of sitting where it needs to be. So all the normative text was
replaced with, action focused sentences, instead of, the normative
keywords. And there's a bit of context as to why this is non-normative.
since there's a lot of things to consider and it's divided in these three
operations. So getting a list setting a status. one thing that is
highlighted here which we were not sure if it made sense to include it here.
Patrick St-Louis: think it's worded in a pretty nice way is just to remind
issuers that it's good if the status list securing mechanism matches the
sec mechanism of the credentials that will be issued and will be assigned
an index on that list that can make it a bit more easier for sort of
interup with verifiers. yeah and then it goes into the other section about
getting a list updating the status. probably now that I see this maybe
there could be another section about assigning a status entry. otherwise
yeah I don't know if anyone would like to comment.
00:30:00
Patrick St-Louis: do we feel this is now at the right place? the examples
are not updated but I did change the URLs for Dave's suggestion to clearly
separate the route. So it's now status credentials instead of credential
status. yes, Manu.
Manu Sporny: Yeah, I like this PR. I think it's going in a very good
direction. I have not had a chance to read it yet, but I'm, skimming
through it now and it looks good as is. I wanted to comment on …
Patrick St-Louis: It's okay.
Manu Sporny: how we expect this section to potentially change through time,
I think it's a useful section. I'm glad we're putting it in here. I have a
feeling people are going to ask us to make it normative at some point,
which is totally fine, right?
Manu Sporny: I suggest we don't make it normative in the first version but
in a version 1.1 we might put language in here where we might say hey we're
probably going to make this normative in time we just want to make sure
that we get enough implementation feedback for multiple impleers before we
make it all normative.
Manu Sporny: So I want to see if that's my gut instinct on this. I don't
know if other people think the same or…
Patrick St-Louis: I think this makes sense.
Patrick St-Louis: I think what I would see is maybe part of it will be
normative. But I think the whole status list creation maybe less but to get
a status list, that seems like something that at least some part of it
could be normative. and…
Manu Sporny: Mhm. Yep.
Patrick St-Louis: updating the status maybe is the one I could see as being
normative. I think updating the status is also the one that had I think it
was in the issuer section. it already had a sort of endpoint and a data
model. it's too bad it doesn't render the examples in this preview but this
one was the one that was already defined. but regarding what you mentioned
about maybe starting with the non-normative and see what the ecosystem has
to say we can see how it goes but especially if we want to test this right
because this would make sense I know when we were writing the bitstring
status list test suite we had difficulty testing it because there was just
no endpoint to test and update dynamically updated status so it
Patrick St-Louis: kind of difficult to test these things beside just
testing the data model. it was hard to test the actual revocation process
like go from a non-revoked to a revoked credential because it was just
defined endpoint that the test client could interact with. That was one
thing that was difficult. So that's why I mentioned maybe the update status
could be made sort of as a more normative implementation. yeah. So any
other comments?
Patrick St-Louis: Yes, Dave.
Dave Longley: I didn't get a chance to really look at it…
Dave Longley: until now. I did leave a comment on the PR just with a list
of properties from our implementation for the create schema. And so we
might want to consider that or otherwise everything looked okay to me.
Patrick St-Louis: And And I remember something that get started. So there
was a status list plugin contributed by province of Ontario for API and we
had a brief look and from what I remember you had made a comment Dave that
it seemed very similar to your implementation.
Dave Longley: Right.
Patrick St-Louis: So I can take it to review this and go compare the
plug-in and highlight the difference and then we can decide what we want to
put in the spec regarding this if we even want to put stuff in there. We
could very much create an issue and iron out the details of the request at
a later stage especially if it's non-normative for so okay so from what I'm
understanding we'll leave it open for people to review and next week if
there's still no objection we can look at merging this in. Does that yes
Manu
Manu Sporny: Yeah, that sounds like a good plan. I had a comment about the
create status list response which I think returns back the status list
itself, The encoded list itself. I'm wondering I don't think we do that for
an update. I don't think that makes sense to do it for an update. flipping
a bit. and I'm wondering I can't remember do we have an option that
basically says don't return the credential back to me. the reason I ask is
because the encoded list I mean it's a status list. It could be multiple
megabytes in size.
00:35:00
Manu Sporny: What do we think about that? Is that something that we always
want to return or do we want to have an option where this is on the create
example lines 850 here.
Patrick St-Louis: on the update or…
Patrick St-Louis: on the create what…
Manu Sporny: Excuse me.
Patrick St-Louis: but wouldn't you just return the whole credential?
Manu Sporny: You want to that's…
Patrick St-Louis: wouldn't it be very similar to issuing a credential in a
sense that you are signing the initial credential or are at least that's
how I would
Manu Sporny: I guess that's what I'm asking here. If we look at I just put
a link in here. yeah. And Dave's saying we send a 204 with a location
header for the new list.
Dave Longley: Yeah, I can voice.
Dave Longley: Yeah, I was going to voice that.
Manu Sporny: Yeah. Go ahead.
Dave Longley: That our implementation after you create the list, we just
send a 204 with a location header. And I think that mirrors what we do in a
lot of other places in the spec. We might,…
Dave Longley: allow both things to happen. But if you just do a 204 with a
location header, it keeps the place where you get the list to just one
place. You just do a get on that list.
Dave Longley: If you want the list,…
Patrick St-Louis: So you're saying on the creation we should return 4 with
a location header instead of returning the credential itself.
Patrick St-Louis: And we potentially want to have a flag if the user still
wants to receive the credential.
Dave Longley: yeah, I mean, if that's something people want, I don't think
we need that. But if somebody wants to optionally do that,…
Dave Longley: I don't know that it's a problem. I think the minimal support
should be a 204 with a location header for the new list.
Patrick St-Louis: Maybe consider having an options field for returning the
credential as well.
Patrick St-Louis: Sorry, 204. Does it make sense to have a response body on
a 204 with the location header?
Dave Longley: 204 is no content.
Dave Longley: I mean that's what it means. You could do a 2011 created and
have some content body if you wanted and we could spec that and that might
be some we'd have to decide what we want that content body to look like.
That's also an option.
Patrick St-Louis: Yeah. …
Patrick St-Louis: would it make sense to just always do 2011 even if
there's no body and still use the location header and,…
Dave Longley: Maybe I think we've done 204 in the VCOM spec in a number of
places.
Patrick St-Louis: leave 204 behind?
Dave Longley: I don't The only thing with doing a 2011 is…
Patrick St-Louis: Okay. yeah,…
Dave Longley: then we have to define what that body looks like.
Patrick St-Louis: I just mentioned probably my initial gut reaction would
be to the same as the issue credential what it returns a verifiable
credential and the credential is the statusless credential.
Ted Thibodeau Jr: You don't actually have to return a body with 2011.
Dave Longley: Yeah, but you couldn't with 204 is my point.
Ted Thibodeau Jr: Truth. Yeah,…
Patrick St-Louis: …
Patrick St-Louis: review it up to for Yeah.
Ted Thibodeau Jr: you don't have to define a body shape because you don't
have to return a body. It's an optional thing. 204 does restrict you. So,
you can't return a body. And that m might be a restriction that we don't
want to have. I'm just thinking out loud.
Dave Longley: Right. Yeah.
Dave Longley: We could decide to not define what the body is. and say you
can send a 2011 and it's noninoperable.
Patrick St-Louis: And…
Dave Longley: People can incubate and decide what they want there.
Patrick St-Louis: regardless 204201 there was always be something created
like that's the point of that end point. so 2011 does make a lot of sense
from what is happening point of view. This is one
00:40:00
Dave Longley: So, one possible path forward is you always send a location
header. You can send a 204 to indicate no content or you could send a 2011
and send whatever content you want and then we can leave that open to
require specific content in the future.
Manu Sporny: Yeah, I know this is a detail work, but I'm concerned that
we'll end up in a non-interoperable scenario if we don't specify what the
content is, people will deploy whatever they want to deploy and they will
of course because we did not define it be totally different from each other
and then
Patrick St-Louis: Yeah, I think…
Patrick St-Louis: if we are to have a response, we definitely should define
what this looks like. I think this needs to happen. agreeing with what you
just said, Lanu. And okay, I think my gut feeling is that some of these
details might be addressed in a different PR. so let's leave this here.
Patrick St-Louis: Let's see next week if there's further comments and then
we can decide maybe to open a new issue for sort of refining create
endpoint and these calls. Does that make sense? Okay, perfect. So I have
this let's review
Patrick St-Louis: next week issue for that. There we go. So, this one will
stay open here.
Patrick St-Louis: You any preference to these ones? Let's go by the oldest
one first. I think that this kind of makes sense. and this one we already
started to discuss it the last time. So maybe we want to hopefully be able
to close this. So do you want to take us over what's been changed since the
last time and maybe refresh us a little bit on what was added?
Parth Bhatt: So I have addressed almost all the requested changes in terms
of making accepted crypto suit and accepted envelopes to accept array of
strings and array of objects and there was a discussion about the term
accepted issuers. So for that one I have raised an issue that the group
needs to discuss on that one and yes that's the issue and that's where we
are at rest everything adding the media type to the accepted envelope was
also finished in the PR.
Parth Bhatt: So everything is ready.
Patrick St-Louis: Yes, I think the main point was to make these different
access field a bit more consistent.
Patrick St-Louis: enabling a sort of object with key values. Crypto suite I
remember media type and then issuer and also potentially accepting strings
for backward compatibility with some current implementation. I'm pretty
sure we had did something as maybe we want to nudge people into adopting
the object sort of model since some crypto suite could have other things
that you want to put besides the crypto suite in there.
Patrick St-Louis: yeah, at a first glance it looks great and we always have
the option to refine it once it's merged. is there any further comments or
any objection to merging this in its current state?
Dave Longley: So, it changes authority since it was in the c, the property
name authority, it changes it to accepted issuers based on our conversation
last week and that's related to the issue that was, So I want you to
everyone to know that if we merge this accepted that will change to
accepted issuers.
Dave Longley: We can of course change that again if we want to, but I think
that's an improvement over leaving authority in the spec.
00:45:00
Patrick St-Louis: Yes. Yes.
Patrick St-Louis: Authority. I think from what we discussed it was sort of
a DAW concept. having read the DAW sort of presentation there's the
authority which is used to list issuers. and I think the accepted model is
probably a bit more consistent here. also putting accepted instead of
trusted also makes a lot of sense. So last call for objections.
Patrick St-Louis: Can you remind me, which one we want to do? Rebase.
Correct.
Manu Sporny: Depending on check the commits these commits are clean and so
if you've got a clean commit history you want to do a rebase. Correct. Yeah.
Patrick St-Louis: Yeah, they seem pretty descriptive. They've got nice
little concise. And there's nothing.
Manu Sporny: Yeah, if you go all the way up to the top and hit the commits
tab, you'll be able to see it more clearly.
Patrick St-Louis: And there's only,…
Manu Sporny: And yeah, these look really good and…
Patrick St-Louis: …
Manu Sporny: nice and clean. Yep. Yep.
Patrick St-Louis: there's not 50 commits here. So, let's do a rebase and
merge. That's great. So, we managed to close a PR, which is very fun. I
will let you part to go around and see if there's any issues that need to
be updated or closed related to that. is that okay if I leave that to you?
Parth Bhatt: Sure.
Patrick St-Louis: So let's go to the next one which will probably be the
last one on the call. so this is a draft. you want to take us through this
Kayode Ezike: So, this is related to issue 527. Just put it in the chat
here. the idea here is that there's basically want the need to be able to
support different versions of OID for VP and allow for multiple different
profiles of oid for VP in a given implementation because they all require
different parameters. And so the main difference here is that basically
it's a few things. the open ID field now can either have all of the open ID
configuration parameters defined directly within it which is what makes it
backward compatible.
Kayode Ezike: And then the other option would be to add a client profiles
field within the open id scope and then within that basically you can
define a dictionary of different configs for the different profiles and so
that's the main difference there. I think the things that are outstanding
so there were a few questions I had that they responded to and also some
suggestions that I have since responded to. There's a few things that I'm
still working on. One of them being things like fields that we debating
whether or not we should add or not. For example, presentation definition,
which is somewhat of an artifact now, but I think for backwards
compatibility, I'm going to add that. And also a DCQL related field as
well. And then I think another thing that would be really useful would be
examples.
Kayode Ezike: So example configuration if it doesn't take up too much
space. so those are the main outstanding things. so yeah feel free to
review. I only put draft because I had those outstanding questions. I'm
just kind of going through and adding some of the responses. Go ahead Dave.
Dave Longley: Yeah, I would say if we add the presentation definition and…
Dave Longley: DCQL_ query fields to this, I think we could wait to get
examples in another PR.
Patrick St-Louis: Anything else you listed as outlining items?
Dave Longley: This would get the definition for it in there. I don't think
we have to put it all together. the presentation definition field and…
Kayode Ezike: Fair enough.
Kayode Ezike: I'll soon guess.
Patrick St-Louis: I heard examples the CQL field. I thought there was a
third one. Or was that it?
Dave Longley: then go ahead.
Kayode Ezike: Yes. And…
Patrick St-Louis: Presentation field.
Kayode Ezike: then off the line. I haven't pushed it yet, but the response
URI I'm going to be adding. there's another field that I have up there now
that I was wondering if we should keep. It's the redirect URI field. I only
proposed that because I thought that was what was meant in the issue, but I
think it also actually was meant to be response UR. So I was wondering Dave
is that if I should keep that or as it wasn't in the issue itself.
00:50:00
Dave Longley: Yeah, the redirect URI is a URI you can send at the end of a
oid forbp thing and…
Kayode Ezike: Okay.
Dave Longley: we want to keep that there so that can be customized.
Kayode Ezike: So I'll leave that then.
Kayode Ezike: I think those are the main things to left. Look, it's
something
Patrick St-Louis: …
Patrick St-Louis: there's a few outstanding items. I want to make sure that
it covers everything that was in the issue. and then, we can see next week
what's going on with the example, see where the PR is at, and if we want to
separate them. anyone else has comment? I'm not too familiar with Open ID.
Kayode Ezike: f***.
Patrick St-Louis: I'm starting I know there was again an Acupite plugin
that was worked on with a previous draft and I might look at updating it
fairly soon. So, I'll surely, kind of look at what's being worked in here
to understand the difference between different drafts. Any other comments?
Very good. so we'll leave this one open. The last one, I didn't change this
yet. So, this had to do with adding pseudo code. when I get to it, I might
just, have a quick look at the respec and see if there would be a nice way
to support having pseudo code in there.
Patrick St-Louis: Dave. Yeah.
Dave Longley: If you're done with the PRs, I was going to ask if we could
introduce a couple issues I filed. one today and one I don't know a couple
weeks back. I just wanted to draw people's attention to them if they wanted
to take a look.
Patrick St-Louis: Any issue number in particular you'd like us to go over?
Patrick St-Louis: Maybe we can have time to go over one or…
Dave Longley: Yeah,…
Patrick St-Louis: two. Okay,…
Dave Longley: 583 and then 575. Yep, that one.
Patrick St-Louis: Let's go with the older one first. I think this kind of
makes sense.
Dave Longley: So this would be documenting a feature…
Patrick St-Louis: Five. Hold on. Okay, This one. I just want to make sure
I'm tabs. Okay, take us.
Dave Longley: where you could specify the verifiable presentation you want
to include in a particular step instead of having it be implicitly
generated.
Dave Longley: And this also allows you to do interesting things like
include credentials that might have been issued out of band for delivery
along in an exchange either on their own or…
Dave Longley: in combination of additional VCs that are issued. And so
that's all that this is.
Patrick St-Louis: So this has to do a bit with the verifiable presentation
templates.
Patrick St-Louis: I would assume it kind of plays at that level. Okay.
Dave Longley: Yeah, it's related to that. So in any given step that's going
to issue deliver VCs a verifiable presentation is handed over and this
allows you to be explicit about what is in that presentation what its
format is and allows you to put anything additional in there that might
have come from some other outofband process.
Patrick St-Louis: Can you and…
Dave Longley: This is kind of also related to trying to make sure that the
VCOM spec is compositional.
Dave Longley: So you can, plug different parts in to other parts.
Patrick St-Louis: can you clarify to me how is this not already the case? I
had a quick look at the step and all you define these things. There was a
sort of inline template option and a way to reference another template.
what makes this not usable right now?
Patrick St-Louis: What kind of change would there need to be?
Dave Longley: So today there's standard place in a step that says this is
the verifiable presentation I would like you to start with when you're
going to deliver credentials.
Dave Longley: It's just patients generate an empty one using whatever
version they want whether it's version one or version two and whatever else
so it's all sort of implicit. This allows it to be explicit and you can
also put other items into that verifiable presentation when you create an
exchange. So you might have issued some VCs in some other step or…
Patrick St-Louis: And When you say version one,…
Dave Longley: some other of the VC.
Patrick St-Louis: version two, are you referring? Yeah. Okay. that Okay,
sounds good. someone raised their hand.
Kayode Ezike: Yeah, that's me. I think you may have answered this, but just
to be clear, does this prevent basically having non-bear credentials, but
credentials that are bound to any for example, because it's already defined
what's in there or, we can change it any way we want. just the foundation
of the VP or something. Okay,…
00:55:00
Kayode Ezike: I guess that would mean that it can't be signed maybe I'm
trying to think how that would allow for the case where a user wants to
present their date to get down to the credential that's issued.
Dave Longley: So you can still do that use case.
Dave Longley: This just defines more or less the foundational starting VP.
If you add things like issue requests to your step then the processing
rules which we also eventually need to do a better job of defining the spec
would be start with the verifiable presentation,…
Dave Longley: issue anything and then add those to that presentation. And
whatever got issued could include things that you did off for example.
Kayode Ezike: Okay, he's got
Patrick St-Louis: Super. Is there any other questions for this issue?
Patrick St-Louis: We'll probably take maybe assign it next call and go into
proposing a solution. very quickly, do you want to take us over this?
Dave Longley: Yeah, I'll try to be fast here that yeah,…
Patrick St-Louis: Maybe a minute or two. Yeah.
Dave Longley: this is in the same vein of making things a little more
composable and explicit. in a step, you can specify issue requests to issue
specific credentials during a step and again implicitly where do those
credentials go when they are issued? they, get stored. They get put into a
verifiable presentation that's then delivered. And this allows you to say,
I don't want that implicit behavior. I want you to store these ria in the
exchange so you can later use that in another step. Or you could end the
exchange and the coordinator read the credentials out of it and then
deliver them through some other out ofband process.
Dave Longley: So it makes everything a little bit more compositional. Yep,
that's right.
Patrick St-Louis: such as it did come out of ban invitation maybe.
Patrick St-Louis: Interesting. So yeah, these two seems to be kind of
related. One is for presentation, the other one is for issue requests. I
have more questions but I think I'll save them for next time because
knowing myself I think we'll leave it here for today. hopefully next week
we can get to iron out maybe a proposal for these which are probably going
to be following one another. very good. So thank you everyone for attending.
Patrick St-Louis: good progress today. We managed to close one PR and I
think we have two PR that are going to be ready next week to also be
closed. so, with that being said, I'm going to join the meeting. thank you
for attending and I'll see you again next week. Bye-bye.
Meeting ended after 00:58:19 👋
*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*
Received on Wednesday, 4 February 2026 00:03:05 UTC