[MINUTES] CCG VCALM 2026-01-13

W3C Credential Community Group (VC CG) VCOM Meeting Summary - January 13,
2026

*Attendees:* Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton,
Eric Schuh, John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt,
Patrick St-Louis, Ted Thibodeau Jr

*Topics Covered:*

   - *Requesting Predicates in Presentation Requests:*
      - The group discussed how to express predicates (e.g., "age is less
      than or equal to 21") in presentation requests, particularly within
      query-by-example formats.
      - Possible solutions included using specific values in fields that
      can be parsed as expressions, introducing a "query by predicate" type, or
      extending query-by-example with special markup or richer objects.
      - The need to consider future cryptographic advancements beyond
      integer-based predicates was acknowledged.
      - Patrick St-Louis proposed adding a "restrictions" field to
      query-by-example to handle predicates and other constraints.
      - An issue will be raised to further track this discussion.
   - *Interaction Scheme Format PR:*
      - A Pull Request (PR) was reviewed that adds a section on the
      "interaction scheme format" to the specification.
      - This new scheme format, interaction:, is intended to trigger
      applications to handle interaction URLs, rather than just
opening them in a
      web browser.
      - The use case is primarily for same-device invocation, like
      launching a digital wallet app from a website button.
      - The scheme format is distinct from the query parameters within the
      interaction URL, which are still relevant for QR codes and other
non-scheme
      invocations.
      - Concerns were raised about the complexity of choosing the right
      invocation method (interaction scheme, QR code, DC API, etc.) due to the
      current fragmented state of the industry.
      - The registration of the interaction scheme with IANA was discussed,
      with a consensus to potentially pursue a provisional registration later.
      - The PR is expected to be merged after addressing a rebase.
   - *Appendix for Minimum and Other Workflow Examples PR:*
      - A PR was reviewed that adds a new appendix containing minimum
      viable examples of workflow steps and credential templates, addressing an
      outstanding request from issue 439.
      - It also includes more complex workflow examples provided by Dave
      Longley.
      - The need for annotations on the complex examples was identified,
      and a separate issue may be created to track this.
      - The PR was discussed in relation to another prior PR by Kayode
      Ezike that also contained workflow examples. It was agreed that
Eric Schuh
      would review Kayode's issue to see if they can be combined or if the
      current appendix covers the needs.
      - The PR is approved for merging.
   - *Status List Management Appendix PR:*
      - A PR was reviewed that adds a non-normative appendix on "Status
      List Management."
      - The appendix outlines how to create and manage status lists,
      including example API endpoints for creating and retrieving status lists.
      - Key discussion points included whether the language in the appendix
      was too normative ("must" statements) and if the OpenAPI (OAS)
definitions
      should be included.
      - The consensus was to adjust the language to use "should" statements
      and potentially move the content to a main section of the spec,
rather than
      an appendix, to avoid normative statements in non-normative sections.
      - The distinction between status list management (setup for an
      issuer) and updating individual credential status was highlighted.
      - The PR will remain open for further changes and will be revisited.

*Key Points:*

   - *Predicates in Presentation Requests:* A clear mechanism for
   expressing predicates in presentation requests is needed, and multiple
   technical approaches are being considered.
   - *Interaction Scheme:* The interaction: scheme offers a new way to
   invoke applications for credential interactions, particularly for
   same-device scenarios, but its adoption is complicated by industry
   fragmentation.
   - *Workflow Examples:* Providing clear, minimal examples of workflows
   and credential templates is crucial for adoption, and the group is working
   to consolidate and expand these examples.
   - *Status List Management:* The management of status lists is an
   important aspect of issuer setup, and the specification needs to clearly
   define how this is handled, potentially with a distinction between
   management and dynamic status updates. The current approach of using a
   non-normative appendix with normative language needs to be resolved.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-01-13.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-01-13.mp4
*CCG VCALM - 2026/01/13 14:57 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Eric Schuh,
John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Patrick St-Louis,
Ted Thibodeau Jr
*Transcript*

Patrick St-Louis: Welcome everyone. We're going to wait a couple minutes
and then we'll get started.

Patrick St-Louis: Okay, let's get the meeting started. So, welcome everyone
to the W3C credential community group VCOM meeting. the date today is the
13th of January 2026. So, this is our first meeting of the new year. I hope
everyone had a good time over the holiday. so this being a W3CCG meeting
all W3C policies are into effect for this meeting for the agenda today. So
we'll start with some introductions and community announcements.

Patrick St-Louis: We will then look at some PRs that are open do some issue
assignment and I believe we have a couple discussion topic to go over
today. so is there anyone new to the call that wants to introduce themsel
or anyone wants to do a reintroduction? Now is the time to introduce
yourself. And if there is any significant community announcements that
anyone would like to share, now is also the time to do so.

Patrick St-Louis: or if there's any new topics that we would like to cover
during the calls today, please let us know as well. Yes, Dave.
00:05:00

Dave Longley: I don't think this is necessarily new because it's on the
agenda for PR review, but there was a particular PR I wanted to make sure
we discussed which has to do with the scheme for interaction URLs.

Patrick St-Louis: Sounds good. We can make sure we start with that if we
think there's some discussions to be had. Yes, Coyote.

Kayode Ezike: Yeah, I just want to say that there are a few comments I made
on open issues before the holidays that I think are already being
addressed. And so at some point, maybe I don't know if this has to be
today, but we potentially can be reducing our issues with those two
comments.

Patrick St-Louis: Okay, we'll try to take some time to get to that today.
Any other community announcements people would like to share. Excellent.
before we get into review I put on this topic I believe we had discussed it
at some time. I do not think we had a clear solution.

Patrick St-Louis: my main topic I'd like to discuss is this concept of
requesting a predicate and a presentation request when using the VP request
query by example mostly or any other presentation request language. I had a
look at the CQL and could not find any way to signify or predicate in a
presentation. And a predicate meaning you provide the holder an equation
that they need to prove that they meet based on some claim.

Patrick St-Louis: So these are at least in my ex experience mostly relevant
when it comes to dates any other numeric values when you want them to prove
you that said value is lower or equal than another value. so I'm curious to
know where do we see these requests fit in the current spec and if there's
been any attempt at doing so.

Patrick St-Louis: I had raised the topic of presentation request
translation a while few meetings ago and there were other participants who
had went through this exercise of translating presentation request and one
of the feature that I had a hard time translating are these I know working
with anon creds predicate is a key component of presentation requests and
I've not found a way to signal this.

Patrick St-Louis: We add expressed a way to request selective disclosure
with query by example which is when you include a property you want
revealed but you include a empty string as the value meaning I want you to
reveal me this property in your credential. however, I'd like to if anyone
has any insight on how predicates could be expressed in something like a
query by example. Yes, Dave.

Dave Longley: One quick response to this is so in query by example, you can
also instead of just using an empty string which is treated as a wild card,
you can put a specific value in that field. And I wonder if this only
applies to integer fields. I don't know that there is any use case at least
numerical fields for strings for performing some kind of function in zero
knowledge to prove some string does something. And perhaps it could be the
case that if a field is known to hold a numeric value and a string is used,
then the expectation and a non-mpy string is used. and the expectation is
that value either parses to an exact integer value or to an expression
greater than 21 for example as a age field.
00:10:00

Dave Longley: So it seems like that might be a place where we could put
expressions and if we can limit it to numeric fields. I see Monas on the
queue.

Patrick St-Louis: Thank you.

Patrick St-Louis: I'll have some response to that. I want to hear what Manu
has to say first and then I can probably share my thoughts. Manuel.

Manu Sporny: Plus one…

Manu Sporny: what Dave said. that is one option. When we've talked about
this before, we were also thinking maybe there's a query by predicate type
for the query language that we could benefit there is we could do really
complex things there if we wanted to and it wouldn't overload query by
example. the drawbacks of course being yet another query language but we
kind of predicted that would happen. meaning we predicted it and it's
totally fine if that happens, I mean who knows how many different quer I
mean there's more than one database query language. There is going to be
more than one credential query language. There already is and it's just
going to probably grow until it settles down.

Manu Sporny: so that's another potential is a query by predicate query type
what that would look like real quick let me share my screen here we have
type query by example here we would just create a new type to do predicate
type queries but I think I like Dave's suggestion more there are other
things that we can do introduce special markup into query by example to say
that this is a predicate expression. to just be explicit about it. that
would require what's the markup syntax and what's the escape syntax for the
markup in case you have a string that starts with two double curly braces
or something like that. Right? So that's another option.

Manu Sporny: And then a third option is that we could extend query by
example or this new query language to have a more rich object that says
that this is a predicate query and this is the type of predicate query it
is. I don't know Dave if we should make a presumption that it is only
integer values. I think that's true today. I'm wondering if in the future
when we have some of this more like cryptographic circuit braced approaches
that you'll have more than just integer based things you can prove in zero
knowledge…

Manu Sporny: but that's so far in the future. I'm kind of like I don't know
if we really need to think about that right now. That's it.

Patrick St-Louis: Yeah, I mentioned integr base just…

Patrick St-Louis: because that's what I concretely used and it's what I
like I haven't seen anything else. obviously I'm aware that as things
advance obviously there's more things will be possible in the future. this
was just a way to be a bit more pragmatic. I did think about using the
actual value field and query by example instead of giving a value you give
an expression that needs to be met. another idea I had was to add a new
field in the query by example type called restriction.

Patrick St-Louis: which these are just a bunch of restrictions would need
to be met where one of these restriction could be a predicate. So it stays
outside of the example of the query by example and the query by example is
only there just now you also have a list of restrictions that you need to
meet and the way you meet these restriction obviously is going to depend on
the crypto suite that is used to secure the credential because that is what
enables the predicates and have this I forgot the term that was used but
the new domain clature that needs to be used for predicate could only apply
to this new field. So this was where I landed in and restrictions could
also enable other things to be met.

Patrick St-Louis: something else that is possible with anon and some
different status method to request was this credential valid at this point
in time. that's something else that is difficult to express with query by
example. It's also not something I've seen used often. but I'm sure there
are some very valid use case for this. yes, Dave.

Dave Longley: Yeah, I was going to say anything we could do that reuses
query by example but augments it with these other things might be the way
to go. So you might have a layered approach where clients that understand
query by example will select things that work and there might be additional
fields that could be applied that would prove things in zero knowledge or…
00:15:00

Dave Longley: apply certain restrictions like you're saying and I think
that actually sounds like a pretty clean way to approach

Patrick St-Louis: Okay. …

Patrick St-Louis: I think that's enough on the topic. I'm happy that the
idea of using the value to express a sort of equation was brought up
because that's something I also thought or the idea of using another type.
These are all things that cross my mind. So it seems like maybe we need to
think what would be the best way to do this moving forward.

Patrick St-Louis: So I will raise an issue for this and then we can kind of
close the discussion for today and just take on this as an issue moving
forward. It seems like a few people mention that this could be useful but
yes neither Dwall couldn't do it either. So I was very curious on how to
express this in a very good. So I'm happy with this. let's go into PR
review. so someone had mentioned there was a specific PR that might require
some discussion and I believe it was the interaction schemes. so I'm happy
with starting with this. yes Manu. Yeah.

Manu Sporny: No, I can help try to explain what that PR is about. That's so
correctly or…

Patrick St-Louis: And hold on you guys are not seeing the PRs right now on
the chat.

Manu Sporny: not. …

Patrick St-Louis: Okay I will and yes please go ahead and explain it or do
you want to share your screen? Feel free to share your screen if you want
to do it.

Manu Sporny: I think I can give a pre let me see if I can. Yep. let me just
preview what it looks like. This one here, I think. Okay. So this adds a
section on the interaction scheme format. and this is one part of the PR.
The other part is the INA registr required in a registration at the bottom.
But let me explain kind of the use case here.

Manu Sporny: without a scheme format, we can't invoke applications to start
up on a button click in the browser. So let's say you're looking at a
website and you want to click a button on the website, but you want an
application to pop up and deal with that instead of it being dealt with in
the browser. the scheme format is the thing that triggers the web browser
to start up any application that supports that scheme. so this came up
because we've got a customer that wants to do a button click on a website
and pop up an app instead of having it dealt with in the browser.

Manu Sporny: I'll also mention that I think schemes you can register
websites to handle schemes now as so I think that's a possibility as well.
but the scheme is simple. You literally just put interaction colon in front
of the interaction URL. So we've had interaction URLs, this thing defined
in the spec for a very long time now. but if you were to click this in a
web browser, it would take you to a web page that's like, hey, you might
want to use something else to invoke to interact with this URL, right?
that's it. So, this is a new scheme format.

Manu Sporny: you put interaction colon in front of the interaction URL and
that will trigger an application to try and open the interaction URL at
which point you get this thing back and you can decide which protocol
you're going to use to interact with the website are you going to use VC
API or ID4VP or invite request or something else right so it's to get the
application to the point where it can request this thing. the only other
addition to the spec is an Ayanna considerations it's not showing up here
for some reason. There's an Ayanna consideration section that has to do
with what the registration ends up looking like. Let me see if that's in
here.
00:20:00

Manu Sporny: Yeah, this is the ANA consideration section and it just says
this we have to send this to Ayanna to say hey we want to register a new
scheme name interaction. It's a permanent registration. the VCOM spec uses
it and then I put some W3C contact information because you usually don't do
the registration until you're done with the spec. so that's it in a
nutshell. I don't know if there are any questions or concerns on that
particular PR. Go ahead, Patrick. No,…

Patrick St-Louis: Is there an example of a full interaction using this
scheme? Shoot. Okay.

Manu Sporny: but it's any interaction that and you just prepen interaction
colon to the front of it and that's it. No, that stays.

Patrick St-Louis: And this would remove the requirement for the query
parameter that we've defined here that stays.

Manu Sporny: That stays. Yeah, because the scheme is different from the
URL, meaning that you can convey that let me point to So, you're talking
about this thing right here.

Patrick St-Louis: Yes. Yes.

Manu Sporny:

Manu Sporny: Yeah. This is an interaction URL.

Manu Sporny: But it is not in interaction scheme format. So to turn this
into an interaction scheme you would put interaction colon in front of
HTTPS and that would invoke a different remember because if you just click
on this, it's going to invoke a web browser. If you put interaction colon
in front of it, it will in invoke any application or…

Patrick St-Louis: Yes. Yes.

Manu Sporny: web page that knows how to deal with that. interaction colon
scheme…

Patrick St-Louis: Okay. Yes.

Manu Sporny: which we expect to be digital wallets and things like that.

Patrick St-Louis: Yes. I think it does.

Manu Sporny: Did that answer your question?

Patrick St-Louis: So I'm trying to see the purpose of the query parameter
and if someone was to use the interaction scheme yeah you Okay.

Manu Sporny:

Manu Sporny: Yeah. The purpose of the query parameter is if you don't use
the interaction scheme. So let's say we want to put this in a QR code which
we do. You don't put interaction colon in the QR code. You don't need to.
In fact, we don't want to because it's a security concern to do that to
invoke something by someone scanning it. We don't want someone to scan a QR
code and invoke an application. it's an attack vector. whereas just having
a URL like this isn't the same type of attack vector. It's slightly
different.

Patrick St-Louis: I would argue that HTTPS is a scheme in itself and we
already do

Manu Sporny: It is but it invokes things that are safely sandboxed and…

Patrick St-Louis: Yeah. Yes.

Manu Sporny: and this is a well-known scheme with lots of protections built
in a web browser around it. we would have to build in the same kind of
protections for interaction colon and it would need the size of the web
browser industry to really make it secure and…

Patrick St-Louis: Yes. Okay,…

Manu Sporny: I think that's why we're kind of like we're not there yet if
ever All right.

Patrick St-Louis: thank you. That answers my question. coyote.

Kayode Ezike: Yeah, I think mine is kind of related. So I was kind of
curious to know do you expect that I guess for the coordinators to
represent both of those in a coordinator for example it have the QR code
that has the original schema and then it'll have a button that would have
the interaction schema and then how do we see that sitting beside for
example JPY or eventually DC API yeah what's the ideal sort setup for UX
setup that you expect to see with this

Manu Sporny: Yeah, it's a good question. A short answer is we are still
working through all the variations. So I can go down each one of the
protocols you listed, right? So this interact interaction colon is largely
for same device invocation. So when we know that the are fairly certain
that the person wants to invoke an application on their desktop mobile
phone almost certainly it's going to be like mobile phone right so if we
have gotten down the path of interacting with the user and we are really
certain they have an app and we want to invoke that app on the same device
that's when
00:25:00

Manu Sporny: you would use the interaction colon scheme. if they're not in
that situation, you probably wouldn't use it. you would use a QR code
something like that. So there are different use cases and environments
where you're going to want to make different choices. so how does this work
with DC API? we probably would not use this with DC API. you would invoke
in a different way because there's a different way of registration and
handlers and whatever for DC API. and then to add even more complication
for it currently DC API does not allow you to issue through it.

Manu Sporny: So unfortunately because there's so many different protocols
and DC API exists and it's kind of halfbaked and implemented for
presentation but not for issuance. there is a fairly complex decision
matrix that you have to go through to end up to where you can make the
decision on I'm going to show them a QR code. I'm going to show them a QR
code with the protocol handler in it or I'm not going to show them a QR
code with protocol handler. I'm just going to show them like an HTTP URL or
I'm just going to show them or I'm going to put a button here that's going
to have an interaction URL on it. Our experience in deploying these systems
into production is that because oid has done it in so many different ways.
because DCAPI is kind of half deployed right now that it's a really bad
time, right?

Manu Sporny: in the future we really hope DC API gets all the features that
we need to and we can just use DC API for the vast majority of this stuff
cross device same device things like that but even that presumes that
you're using a web browser and a number of where we're seeing this stuff
deployed in the convenience retail sector you don't have a web browser it's
a point of sale system and it's got a laser scanner on it

Manu Sporny: And so there is no cross device that system is never going to
speak DC API to your phone, so it's really unfortunately Coyote I think the
answer to this is when you use this is really complicated because of the
state of the industry. I don't know if that was helpful or not but I'm just
trying to convey like it's complic that's a complicated question to answer
right now. I wish it was simple. I wish we could just say, " we just use DC
API." But our experiments with DC API have not been going super great. it's
not nearly as ready as we'd like it to be.

Kayode Ezike: Just really quick, I don't want to belabor this too much, but
I guess the only outstanding question in my head is which of the I guess
click interactions would coordinator prioritize, right? the coordinator
could decide to choose for the button to invoke trappy or to invoke
interaction, Or it might decide to present both and that then becomes
confusing for the individual. So I guess it's not a question you have to
answer now, but it's I think something that we'll just need to think about
too because now that there are multiple options for getting to including
obviously oid4 as well, which is adds to the mix, but

Manu Sporny: And I don't think that there's a simple answer to that right
now. it almost depends on the use case. for example, if you know that
you're on a mobile phone and you know that the person has an application
with your credential on it and that's the only way they could possibly be
interacting with let's see what was the other thing. you're on a mobile
phone, that they have an application. and it's not cross device. there's
another thing that matters in there. at that point you're like yeah I would
want to use an interaction colon is they're on the same device. I'm fairly
certain they have an app installed. They'd have to even get to this part in
the process.

Manu Sporny: And they're doing issuance and not presentation because if
they're doing presentation, then you might want to invoke DC API. But if
you're doing issuance since DC API doesn't do issuance, you're like, okay,
they're on a mobile device, they're doing issuance, they've got to have my
app installed, I'm going to use an interaction that's the decision process
that gets you to using this feature or one of them anyway. But if you don't
know if they have your app installed, it's super risky to do this, So
you've got to figure out a way of getting that information out of the
individual and…
00:30:00

Manu Sporny: that just totally defeats the whole purpose of DC API.

Patrick St-Louis: Do you say your app,…

Patrick St-Louis: but do you mean your app or…

Patrick St-Louis: any app that can process an interaction URL?

Manu Sporny: I mean the unfortunate thing that some governments are doing…

Manu Sporny: where in the EU and…

Manu Sporny: in some states in the US where they have the pick your
government agency app right wallet right and…

Patrick St-Louis: Right. Yeah.

Manu Sporny: they only allow their wallet right in those cases they're kind
of like a closed loop ecosystem they don't support wallet choice and that's
a choice they've made and in that case it makes it really easy to make the
decision to use the interaction URL right because that's the only way the
person could be engaging with the government agency I wish we did not have
to do this be clear about that…

Patrick St-Louis: Very good.

Manu Sporny: but we have to because of interesting choices that some of the
agencies deploying this stuff have In the future, I hope we can just use DC
API as much as possible.

Patrick St-Louis: Is there any other questions regarding this PR? And most
importantly, is there any objections to merging the PR? So, I think we've
discussed it.

Patrick St-Louis: From what I gathered, more will come on this topic. but
this is a sort of first introduction to get the process started with this
interaction scheme. put the placeholder in the spec so can you clarify
maybe manu so you mentioned about registering the scheme is this decision
we're making today that we want to go or someone will go forward with
registration or this still needs to be discussed

Manu Sporny: We could do that. there's such a thing as a provisional
registration in you don't even have to point to a spec to do that at ITF or
ANA. we could do that.

Patrick St-Louis: Ready?

Manu Sporny: I don't think it's a big deal. by the way, OID4 VP and OID4 VC
have never been registered. it's just like they're just using it, So, we
don't have to. but I think it's a good idea to get a provisional
registration if the group is okay with doing that. we could kick off the
process now or we could wait until it gets in the verifiable credential
working group at which point it becomes harder for someone to object to the
registration. I don't know why anyone would object to the registration, but
some people don't like VCOM and they might just find a reason to object to
it.

Manu Sporny: So we could try it in two or three months. I don't think
there's any super great need to do it now.

Patrick St-Louis: Okay. …

Patrick St-Louis: sounds like this could be tracked with an issue as well.
Just put an issue about the interaction scheme and registration and we can
if we want revisit the topic next week or the week in the meantime, any
objection to merging this PR too late.

Manu Sporny: Do a rebase Never mind.

Patrick St-Louis: What did you want to do?

Manu Sporny: It's It had a clean history. Rebase emerge.

Patrick St-Louis: Okay. I'll keep that in mind for the next one.

Manu Sporny: That's okay.

Patrick St-Louis: Okay, let's look at this one here was open an hour ago.
So it says add new appendex for minimum and other workflow examples
handling issue 439. this was an issue open about one year ago. send the
example.
00:35:00

Patrick St-Louis: Yes, Yeah, Eric, please why don't you go explain us
through this PR

Eric Schuh: Yeah, sure.

Eric Schuh: Yeah, so the issue 439 there already had a prior PR raised that
added a bunch of language about workflow steps and the step functionality.
but there were some outstanding requests for a minimum viable example of
both a step in a workflow and a credential. so we talked about this a
couple months ago. Dave Longley added some examples to the issue. some more
complicated examples of workflows and then some paired down versions that
are the minimum viable yeah keep scrolling down.

Eric Schuh: So, I added this note here right there. I believe that's the
one that links down to the new appendix and the appendix currently contains
both the minimum viable step template and credential template that Dave
included in the issue. and then as we were discussing that issue last time,
it was also mentioned that it would be nice to actually be able to have the
more complicated examples included as well. And it was mentioned that it
might be nice to have those in an appendix. So below here, there are the
two complex examples that Dave had included in that issue. if I'm
remembering correctly from that conversation, Dave, you had said that it
might be nice to annotate these a little bit better.

Eric Schuh: So, I was hoping that this would give a place for so the
examples are at least in this appendix and I believe that we might want to
create another issue to track some annotations for this. and Dave, I just
wanted to mention that if you have the time to put the important
annotations from your mind someplace, I would be happy to do the work to
get the formatting and everything right to update this appendix. because I
know there were a few things for each of these examples that you would
wanted to highlight.

Eric Schuh: But I don't know what those were. So I think that's it though.
It's just adding this appendix with these examples and that one node up
above.

Patrick St-Louis: You're safe.

Dave Longley: Yeah, thank you, And that sounds good. I don't think we need
to hold up the PR for that. I can go try and mine that stuff or from my own
brain or wherever I might have commented on it at a later point for the
annotations. But I think it's a good start to have the data

Patrick St-Louis: Very good.

Eric Schuh: Yeah, and…

Eric Schuh: I think my last note is just thanks to Ted for coming through
behind me and doing the language cleanup. yeah.

Patrick St-Louis: My first reaction, it would be nice to have a feature to
collapse the example, especially this one. there's a JSON schema in there
and it's, pretty large.

Patrick St-Louis: It's not too bad because it's in the appendix. but having
a little collapse example feature and respect that's more of a respect
comment however would be useful. this is interesting. I had experimented a
little bit with workflows and for me the part currently that needs the most
clarification is how to define templates. so I think this kind of addresses
that either exactly or partially. I'll need to review this and go back to
the work I started going through. yes, Coyote

Kayode Ezike: The question that I was going to say so I was blanking off
from something else but this is an example of temp workflow examples
because there actually was a PR that I put up a few months ago that had
examples as well for specifying workflows. I wonder if maybe the two can be
combined or it may just be in this PR. Maybe you can merge this one and
deal with it later. There was an two examples of workflow definitions that
had credential templates in there as well and other things. But this might
have additional things on top of that maybe. But just wanted to call that
out.

Patrick St-Louis: Yeah, I think Eric did mention your PR was probably the
other PR he mentioned addressing this issue. could you explain a bit Eric
what could you explain again…

Patrick St-Louis: what this adds on top of the other one? I think it was
really the minimal viable one because workflows can get a bit overwhelming
when you just get started.
00:40:00

Eric Schuh: Yeah. Yeah.

Eric Schuh: The explicit ask from this issue 439 that was left open was for
explicitly an example of a minimal viable step.

Patrick St-Louis: Okay.

Eric Schuh: So, I'm not sure exactly the language there, gets a little bit
ambiguous, I think. So, the way that I believe Dave interpreted it and the
way that I framed it was that it's effectively a template for a minimal
viable workflow that has a single step in it, and then the other ask was
for a minimum viable credential as so that was the direct ask from that
issue. the issue had been discussed if you go to that 439 and there was the
initial ask of the issue was also i to add clarifying language around the
steps in the workflows in general but that part had been handled in another
PR.

Eric Schuh: But I don't believe that was any examples being so I guess if
there's another issue open that's asking for examples or has some examples
in it. would you maybe just mind adding me as an assigne and…

Eric Schuh: I can take a look and maybe there's a future PR that takes some
of the other examples as well and adds them to that appendix. if the ones
that are there don't cover everything. armies. Okay,…

Kayode Ezike: Sounds good.

Kayode Ezike: Yeah, actually think I do have the issue open. I can paste in
the chat. Believe that this is the one. And then there was I think an
example in there a few that have some workflow related stuff but also
cranial templates and stuff like that. Yeah.

Eric Schuh: cool. Yeah.

Eric Schuh: I'll take a look and see if I can't figure out if there's
something different that it's asking for or…

Eric Schuh: if it's the same thing and it's covered by the current examples
in that appendix that I just added. and I'll try to, propose at least some
solution for that other issue as well.

Patrick St-Louis: Sounds good.

Patrick St-Louis: Are you okay if I leave both issue open meaning the 439
and…

Patrick St-Louis: 460 and you can have a look and probably close one of
them or converge them. Is that sound good Eric?

Eric Schuh: Yeah,…

Eric Schuh: that sounds good.

Patrick St-Louis: Any objection to merging this R? I like it. It an
appendex adds more example.

Patrick St-Louis: Examples are always great. So, we'll go ahead and rebase
and merge. Awesome.

Patrick St-Louis: Why is it still Yeah,…

Eric Schuh: That's what we just were looking at.

Eric Schuh: I think it just hadn't updated

Patrick St-Louis: I'm trying to understand why it's still there we go.
Okay, it just took some time. small company. There's some bugs. okay. So,
these two other issues. this one I have not had the chance to go and update
it.

Patrick St-Louis: However, this one I had a chance to update it. However,
this was also adding an annex. So, I'm thinking might want to just go back
and make sure that the annexes are fine with the PR that we just merged.
however we can still have a look and I will just after the call is finished
go and make sure that all the annexes are properly sequenced and nothing
has broken.

Patrick St-Louis: Yes Manu.

Manu Sporny: Yeah, that's editorial.

Manu Sporny: I mean, you can merge on the call you and the editors can sort
it out after the fact if they're out of order or something's weird.

Patrick St-Louis: Okay perfect.

Patrick St-Louis: So let's just review it and then we can give a shot to
merging it if there's no objection. so this was to add a non-normative
section about managing status list. So there is the status service that we
outline in the spec and the sort of responsibility of updating status fell
under the issuer which makes sense. However there was no information about
how managing the status list. I believe there was one endpoint we defined
to update the status of a credential and we decided there was an issue that
mentioned it might be interesting to add some text about managing the
status list. the initial PR added this text in the status service section.
00:45:00

Patrick St-Louis: however I believe this was the last call of last year we
decided it would be preferable to put it in an appendex as a non-normative
section. So this is the change that I've made since then. So let's go and
have a look at this preview. Why cannot I see my preview here? Hold on. I'm
just trying to share the correct tab which for some reason is not So I'm
just going to share the whole window so I believe there's a reference to
this appendix.

Patrick St-Louis: Let me just scroll down really quick in the status
section. or we can go straight to the appendix. So there's an appendex
called status list management. that looks like this. I don't think it
renders the example unfortunately. There's a few example that's been added
or the different status list object. I don't think they render in the
suggestion. I don't think they render in the preview. Let's go see the OAS.
So, it adds a new endpoint. again, these are non-normative. so, this
endpoint could be anything.

Patrick St-Louis: And the idea is so we have the credentials status
endpoint which is just a post endpoint to update the status of a
credential. So in the spec. this adds a list at the end where you publish
your information to create a new status list. and these are the three main
operations. So the get status list this is a pretty straightforward
operation. This is the endpoint I believe that verifiers would call to get
the latest state of the said status list.

Patrick St-Louis: one maybe shortcoming that it doesn't get into a system
that might have multiple version of a status list. maybe that's something
that could be further improved eventually. Like I mentioned, some status
list patterns or specification enabled to get, a different state of a
status list at a given time. but that's a statusless method specific
implementation. I think we had decided that for documentation sake we will
model it against something like a bit string status list and how that
functions.

Patrick St-Louis: So Dave put a comment that instead of status slashlist,
you just use status dash list. yeah.

Patrick St-Louis: I mean, yeah. Yeah.

Dave Longley: This is all non-normative. I don't know how much it matters.
but I just want to comment that in our particular implementation, we did
not hang the status list the status endpoint which hangs off of credentials
with the intention of keeping that clearly separable from issuing
instances. So an issuing instance might have an interface on it for
changing status, but you might want to be able to wholly separate the
instance that manages your status lists from that. And so we just have it
as slash status lists and then list ID.

Dave Longley:

Patrick St-Louis: Yeah. Yeah.
00:50:00

Patrick St-Louis: Yeah, because status lists even though they are
technically a redial. Again, in some cases, they are technically a
verifiable credential, but creating this distinction that they can live on
a different endpoint that represents status list exclusively might be not a
so bad idea. Manu

Manu Sporny: I just ran through and did a quick review. plus one overall
it's, really well written and all that kind of stuff. I'm on a couple of
the major thing is we have normative statements in an appendix and we
normally don't do that because people normally are not expecting appendices
to have normative statements and we have some pretty strong ones must, so
at that point it's not non-normative, it's normative like you're basically
saying you have to do this.

Manu Sporny: the other thing that makes it seem like this is non-normative
is we define all the OAS for it, Which is kind of like, you've pretty much
said exactly how we should do it. I'm wondering a couple of thoughts. one,
if we've gone this far, we could probably just go the last little bit and
make it normative. I am concerned about that because we were concerned
about other people having different ways of doing status list things. we
could say if you're using bitstring status list then you must implement it
like that. That would be a way of just kind of not accidentally preventing
other people from doing different status a different way.

Manu Sporny: So the two major things is I don't know if we can really have
this kind of normative language in an appendex.

Patrick St-Louis: Mhm.

Manu Sporny: It's weird because you're saying it's not normative, but
you're totally making normative statements all throughout this thing, and
then the second one is even if we weren't doing that we have defined things
that are basically like this is how you implement it right so a couple of
ways that we could do this we could make this normative and move it up into
the core of the spec and then just say this is only if you're implementing
bitstring status lists and you can use the design pattern for other types
status lists to keep it really sharp and focused until we're a little more
sure about other status mechanisms that might come along.

Manu Sporny: And I think that would address both the normative statement
and the normative definition in the OAS files issue. but really interested
in what other people are thinking have to say.

Patrick St-Louis: So for the language yeah I can definitely remove this.

Patrick St-Louis: I believe this specific statement here is already covered
in I think the VC data model or the bitstring status list. I'm pretty sure
there is mention of it. So the VC API is not really concerned with it. I
think if it's not a VC API thing.

Patrick St-Louis: This is more of a thing to be worried about when you're
issuing credential and you have a status list and you want verifiers to
make sure that verifiers that rify the credential can also verify the
status or whether this should be non-normative my personal feeling is it
should stay non-normative at least the status stuff and I would even maybe
suggest removing the credential status endpoint and make it non-normative
this endpoint to update the status of a credential. maybe even all things
status related could be made non-normative. that would be my sort of
suggestion.

Patrick St-Louis: Yeah, that may maybe so when we say OES definition these
are mostly used to reference in the spec page to give examples.

Manu Sporny: Yeah, we could do that. I mean, I hate to lose something
that's so you're suggesting just remove the OAS definitions. yeah.

Patrick St-Louis: I'd still want to give some examples here. So as Yeah.

Manu Sporny: Which would be fine because examples are non-normative. I
mean, the other thing we can do is as long as we stick to shoulds, all of
this stuff is a should and not a must, then I think we're fine. that won't
trigger you have to implement this feature and you have to implement it in
this way.
00:55:00

Manu Sporny: It's just like a if you're implementing status management, you
should do it in this way, but that's not a hard requirement. People can
ignore it. okay.

Patrick St-Louis: Okay. Yeah,…

Patrick St-Louis: there's definitely like this. I can change it. I thought
I had changed it actually, but it's still there. So, obviously didn't use
much of it.

Manu Sporny: And then moving it up into the core of the spec having should
statements even in appendix is a bit weird. So let's just move it up into
the main spec and call it status list management or whatever the title is
right now. and then as long as it's just a whole bunch of shoods, I think
that's fine. it would be like Yeah,…

Patrick St-Louis: A new section status management issuing.

Manu Sporny: I Yeah, pro. Yeah, I think so. I mean, does it could go under
issuing, but it feels like make it. Okay.

Dave Longley: I think we have two. There's actually a Q. Air buns.

Patrick St-Louis: It's so something like this is part for me at least like
that why it's weird to put it in issuing. So this is more part of a setup
that you do for an issuer. So the same way that you're going to create a
divid you're going to create your status list like these are all things
that a issuer does as a setup and then updating a status.

Patrick St-Louis: This is a dynamic thing and it's a operation that an
issuer will dynamically do as part of the issuers's life cycle. so that's
fine. yeah. So, that's all I wanted to say. for me, I see this creating a
status like it's not the same thing as creating a did, but it's kind of in
this same one-off action that happens. And I say one of obviously you can
create multiple status list, but I see very much this as far as I'm setting
up my issuer to do the thing that they need to do instead of a sort of
ongoing operation.

Patrick St-Louis: Ted,…

Ted Thibodeau Jr: Yeah, I just wanted to ask this not be merged…

Ted Thibodeau Jr: until at least tomorrow. I haven't had a chance to go
over the pros.

Patrick St-Louis: yeah, this will stay open to till definitely next week.
we had discussed something. So I'll make those change and…

Ted Thibodeau Jr: That's fine.

Patrick St-Louis: maybe we can clarify where is on this but I'll have a
proposal by next time and we can see if this s suitable for everyone. Yes,
Dave. And then we'll have to call and…

Patrick St-Louis: enter to the meeting.

Dave Longley: Yeah, trying to remember…

Dave Longley: what I was even going to say. I think the status list
management is separable from simply updating the status of a particular
credential. So we might just want a separate section on status list
management even if it ends up having a lot of shoods. it is a specific type
of way of doing status and…

Dave Longley: man exposing APIs to create status lists and serve them I
think is a separate consideration from binding particular indexes to
particular values and so

Patrick St-Louis: Yes. Yes.

Patrick St-Louis: I think this reflects a bit what I was trying to say that
it's more of a setup thing like assigning index updating stat that's part
of the issuing process as creating your list is not really part of an
issuance process it's more be getting ready right the same way as you would
publish the public key that you're going to use to issue these credentials
these are actions that happen before the

Patrick St-Louis: the issuance. sounds good. I'll update this PR for next
time. there's two issues I wanted to open. I forgot, but I'll go over the
things that we close and it will come back to me. I think one of them was
about the interactions scheme registration. It was something else before
that. I'll go over this and we'll come back to me.
Meeting ended after 00:59:55 👋

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