[MINUTES] VC API 2025-05-27

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

*Topics Covered:*

   - *Introductions:* Rodrigo, a researcher at a university working with
   verifiable credentials in data spaces, introduced himself.
   - *Community Updates:* Manu Sporny provided updates on the Credentials
   Community Group call, including discussions about the future of the
   Verifiable Credential Working Group at the W3C, the current charter's scope
   (covering render method, confidence method, and potentially credential
   refresh), the need for re-chartering to include VC API work, and a focus on
   threat modeling and privacy.
   - *Pull Request (PR) Review and Merging:* The group reviewed four open
   PRs. PR #402 (ensuring challenge and domain aren't used in verifiable
   credentials) was merged after discussion. PRs #483 and #484 required
   further review and were not merged. PR #484 (adding OAuth2 structure to
   authorization field definition) needed additional review from other
   community members.
   - *Issue Triaging and Assignment:* The group categorized open issues by
   effort level (low, medium, high) and assigned them to attendees for PR
   creation. Many low-effort issues were assigned. Several issues were closed
   as already addressed or no longer relevant.

*Key Points:*

   - There's ongoing discussion about the appropriate use of challenge and
   domain parameters within verifiable credentials versus verifiable
   presentations. The consensus leans toward restricting their use to
   verifiable presentations.
   - The specification needs clarification regarding endpoint instances,
   their configuration, and the handling of proofs, particularly proof chains.
   - The group decided to add a protocols endpoint to the API specification.
   - Several issues related to OAuth2 authorization, workflow steps,
   template specifications, and data formatting were identified and assigned
   for resolution.
   - The meeting concluded with a plan to continue processing PRs and
   addressing remaining issues in the following week's meeting.

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

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

Benjamin Young, Eric Schuh, John's Notetaker, Kayode Ezike, Manu Sporny,
Parth Bhatt, Patrick St-Louis, Rodrigo
*Transcript*

Manu Sporny: All welcome everyone. we are going to get started and
hopefully a couple more folks will trip trickle in. welcome everyone. This
is the verifiable credential API call. this is May 27th, 2025. on the
agenda for the call today is that we're going to cover the pending pull
requests and we'll continue to categorize ready for pull request issues by
level of effort. we will also cover introductions and reintroductions.

Manu Sporny: so Rodrigo, if you want to introduce yourself in a bit at that
point in the meeting, please feel free to give a couple of kind of your
background and why you're interested in the work and that sort of thing,
where you're coming from. and then we'll cover kind of any community
announcements and then we will go into the main part of our agenda. are
there any other updates or changes that we want to make to the agenda? Is
there anything else we want to cover today on the agenda? if not, let's go
ahead and get into the main part of Rodrigo, it's completely up to you if
you want to introduce yourself. please do.

Rodrigo: All I'm a researcher at University and we are currently working
within the verifiable credentials ecosystem for the data spaces and…

Manu Sporny: Excellent. wonderful.

Rodrigo: right now we are investigating it and researching some protocols
to introduce some verification methods within it. Hey, I'm here to learn
from you guys and to see what can I implement in our protocols with your
information.

Manu Sporny: That sounds like wonderful work. very much in line with some
of the things that we're working on in welcome to the group. We're very
happy to have you.

Rodrigo: Thank you.

Manu Sporny: All right.

Rodrigo: Thank you.

Manu Sporny: Next up, are any community updates or any things of that
nature?

Manu Sporny: I'll mention that during the credentials community group call
today the future we just talked about what's next for the verifiable
credential working group at the worldwide web consortium. we covered the
current charter which basically allows us to work on let me kind of bring
up the issue 250. So these are the current specifications being incubated
at the credentials community group. So this is after the seven other
specifications reached global standard status.
00:05:00

Manu Sporny: These are the next ones that we're hoping to take through the
process of only this one. So the render method and confidence method are
clearly within scope of the current charter and it's arguable that
credential refresh would be in scope as well. So we've got three
specifications that are in scope and we can continue to work on. some of
the other things that happened during the call today was that there is a
big interest in threat models and making sure that our threat modeling for
the verifiable credential technologies and digital wallets, in general
there was a specific focus on privacy as well.

Manu Sporny: and so we know that at least these three and then of course
ARA fixing the specification any bugs and things like that are in scope as
so that means that this thing render confidence method credential refresh
probably within scope and then all the other items we will need a
rechartering and that rechartering discussion will probably start August of
this year. We're trying to give the group a little bit of a break, a little
time to breathe, a little time to get some of these specifications in order.

Manu Sporny: it was specifically stated that we would have to recharter to
work on VC API in the working group. So that's just something that would
need to happen. I think that's it. Any questions or concerns over any of
that? That the entire transcript will be published at the end of the day
today. So we'll all be able to take a look at what was discussed there.
that is it then for any other community updates that folks wanted to share?
all right.

Manu Sporny: So let's then jump into our main agenda for today which is
going to be processing PRs and then continuing to categorize ready for PR
issues. So, we've got four open PRs. and these have been out there for a
week. and I think what we're going to try to do is see if we can get some
of them merged on the call today. this one ensures that the get credentials
with an ID value includes objects that contain a verifiable credential.
let's see. you know what?

Manu Sporny: I think I was supposed to go in and add an example here that I
have not done yet. so that this is covered, but I think they've longly
asked for a verifiable credential barcode use case, and I need to do that.
So, we can't merge this one today. but the rest of the content looks good.
I also note that it's got a merge conflict now, and that needs to be
resolved. So that's kind of where that one Can't merge that one. ensure
that the challenge in domain isn't used in verifiable credentials only lean
verifiable presentations. I think this did get resolved because the
suggestions went in. We've got two positive reviews. go ahead Patrick.

Patrick St-Louis: What's the reason why I just can't use …

Patrick St-Louis: why you couldn't use that on a VC? Okay.

Manu Sporny: You could I don't think there's anything like making it
illegal.

Manu Sporny: But the OAS files are pretty OAS is very black and white. It's
like you either do it or you don't. there are optional things but when we
make things optional then it raises a whole bunch of questions on should I
include it or should I not in general we don't have any protocols today
where you would use challenge or nons on them on the verifiable credential
itself right it's usually only used on verifiable presentations so while
it's not illegal to use it like the spec says you can use it whenever you
00:10:00

Manu Sporny: want to I think what we're trying to nudge people towards is
the place you really use them is unverifiable presentations because when we
allowed them on credentials that's what raised this issue in the first
place the person was like wait a second I thought this was for
presentations so we could change it and make it optional concern in doing
that is then all of a sudden people will basically because it'll show up in
the documentation and it'll show up as a property. It won't say optional be
beside it. I don't think maybe it does.

Manu Sporny: But then it's like okay when do I use this? You're saying it's
optional. Do you have an example of when I use challenge in a verifiable
credential? there are some use cases right …

Patrick St-Louis: right? Yeah.

Manu Sporny: if you wanted to create a credential and you were creating
thousands of those credentials even that anyway I'm going to try to stay
away from trying to come up with a use case for that but I think did that
answer your question Patrick Yeah.

Patrick St-Louis: Yeah. it's just I had a use case that it's not even a
credential. It's just like a data integrity proof. it's still a
authentication proof but it's just like a document that has a shortlived
proof but it's not a presentation.

Manu Sporny: Mhm.

Patrick St-Louis: So I was just wondering if there was a specific reason
why not to.

Patrick St-Louis: And it seems like there's no real hard bound reason. by
most of the time it's designed to be used on a presentation authentication
type of proof.

Manu Sporny: Yeah. Yeah. for that use case, Patrick, one of the things
we've looked at is use the created date and use milliseconds or
microsconds. that's just as effective as having a challenge or a nons in
there,…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: but again, that's debatable and it's kind of like until we
have a really solid use case where people are like, I want you to document
this use case, I think we're just going to not say anything about it. for
All so I think this one is ready to go. are there would anyone object for
this one being Just ensuring that the challenge and domain isn't used on
VCs or at least we don't document it as being used in VCs and we only put
it on VPs for now.

Manu Sporny: if that's the case, we will rebase and merge this one. there
we go. All And that should take care of issue 402. Okay. All right, that
one is done.

Manu Sporny: All right, on to the next PR which is 483. Add a note that
exchanges are not performed by coordinators. looks like we've got some
notes from Dave on this, so we won't be able to merge it today. And it
looks like we're going to have to go back and rethink some of the language
or try to see if we can make a change based on this stuff.

Manu Sporny: So, this one's not ready to go yet. And it looks like there's
a good legitimate use case All Next one is a work in progress that Coyote
you raised last week. would you like to take us through the use case or…

Kayode Ezike: And I just left a comment on it too.
00:15:00

Manu Sporny: the PR

Kayode Ezike: So basically this is in response to an issue I raised some
months ago around I think the underspecification of this property on this
spec. And I think the decision we came to was that it wasn't in the
clearest but it was basically that we should try to give guidance on how to
use the field. and to provide examples where necessary so I think what I've
done is basically to add the fields that would be used for an OT exactly
this right here if you're using OT you would have to have that field which
shows the issuer config URL and I also had text that I added just a few
minutes ago

Kayode Ezike: around explaining basically that currently there's no
normative requirements for that field but that we should use certain fields
when we're using O2 I don't know if that's best way you want to go about it
but generally I tried to follow the guidance that was in that issue and I
think the main thing I'm wondering is what's the best location to put that
because it probably should be near the definition in the actual spec HTML
but there are other places for example where they're talking about
different types of authorization where it could potentially go and…

Kayode Ezike: so I just not clear exactly where to put that kind of
language and also if that's the best language you want to use generally so

Manu Sporny: Yep. …

Manu Sporny: I mean, yeah. one, thank you for writing the PR. that's great.
I don't have strong feelings about this particular kind of PR. I see what
you're saying and I see the benefit of kind of putting it in both places.
There is some danger that we duplicate information. I wonder if we should
generalize this to a component and OAS component where it's like an OOTH2
configuration. since it looks like it's duplicated in both. is it
duplicated?

Kayode Ezike: So those are two different. So this is for the get and create
endpoints.

Manu Sporny: Okay.

Kayode Ezike: So potentially I could define the model and refer to in both
places instead.

Manu Sporny: This wouldn't be the only place it would happen though, right
Coyote?

Manu Sporny: Or are these the only end points where you would list this
object.

Kayode Ezike: Those were the only places…

Kayode Ezike: at least I was looking for the places where authorization
property is specified. can dig further but those are the name places that I
came across correctly.

Manu Sporny: Maybe so let's see. We should definitely get a review from
Dave Longley, Dimmitri.

Manu Sporny: what other oathy people do we have in the group? It looks fine
to me, Coyote. I'm just wondering who else we should ping on this. I don't
know if Lane would have an opinion. Patrick, you might have an opinion.
we'll ping those folks and see if they've got any opinion on this. and
other otherwise, I think, we just merge it. do you feel like it Let's see.

Manu Sporny: I do think we probably need some exposition in the spec
coyote. we should talk about one second. So if there is an authorization
section in the spec, right? We do talk

Kayode Ezike: So I was debating whether to include it there in O section or
to include it somewhere closer to where the end points are defined because
it's going to start to talk about specific properties as part of the
request body for example and response body so I didn't think it would maybe
appropriate to include it in this section specifically so that's the only
that's…

Kayode Ezike:

Kayode Ezike: why the question that I asked in the PR basically is that's

Manu Sporny: Yeah. Yeah.

Manu Sporny: Yeah. I think that's a good thought process that you had u
through that. So yeah, retract my request. I think it's fine to just put it
where people the mo more concrete thing in the place where people are more
likely to do something about it. which is what your PR does. Okay, I think
that looks we'll just wait on feedback from a couple more folks before we
merge it. I'll just say this looks good to me.
00:20:00

Manu Sporny: Anything else on PR484 adding the OOTH2 structure to the
authorization field definition? All right. if not, let's go ahead and jump
into some issue processing. And what we're looking for here is whether or
not something that's ready for PR is a loweffort, medium effort, or high
effort task. and we're going to go from kind of the oldest to the newest
one. So, let's look at make named naming scheme for path parameters
consistent. Although I feel like we look over this

Manu Sporny: So PR should be all identifiers that are part of the path to
rename the resource they appear on and path ID appended to them. So this
feels like it's a fairly loweffort task. and I think Patrick,…

Patrick St-Louis: Yeah, it seems like I'm already assigning.

Manu Sporny: okay,…

Patrick St-Louis: I just to to Seems pretty straightforward. just need to
take the time and do it.

Manu Sporny: okay, all sounds good. all right. You're assigned and that is
marked as effort low. let's see what just happened here. it updated. Is
that a new GitHub thing? that's create workflow config object to reuse
across API calls. group discusses. Agreed.

Manu Sporny: There shouldn't be an intermediate step property. So, this
looks like and Patrick, this is assigned to you.

Patrick St-Louis: Yeah, I'd have to get my head space back in there. Yeah.

Manu Sporny: Okay. I think what this is asking for is to delete the step
property. okay. Yeah. go ahead Cody.

Kayode Ezike: Yeah, I commented before but meaning there's another thing I
wanted to comment about this issue too that keeps coming to mind that is
technically not correct which is that the step name is technically not
correct because I think it's like step name itself would be the actual name
of the property which is not the case it's actually just like a open space
for anybody to use a string there and I think the way we have specified is
technically not the way to do it.

Kayode Ezike: I don't know exactly the way to fix that in OAS, but that's
been standing out to me as well. I'm not sure how big a deal it is, but
yeah, exactly.

Patrick St-Louis: Are you saying that step name shouldn't actually be step
name,…

Patrick St-Louis: but it should be the name of the step? Okay. I think can
you just define a property as string and it's just going to show as string
and you give it the definition that would explain it.

Manu Sporny: We'll have to look into it,…

Kayode Ezike: Yeah.

Manu Sporny: Because I don't know if this is our code that's messing this
up or if OAS just doesn't know…

Manu Sporny: how to, …

Patrick St-Louis: …

Patrick St-Louis: remove the inner step and…

Manu Sporny: have delete this.

Patrick St-Louis: then yeah. Yeah.

Manu Sporny: And then this is the name of the step. and then an associated
object. I'm going to say effort low to start and then let us know if it
turns into a bigger ordeal. Patrick. Thank you. All next up, it's auto
updating Hooray. Go, GitHub. I don't remember it doing that before. I had
to keep document that endpoint instances have specific behavior by default,
but can have options. John took this on. and he wrote a PR for this.
00:25:00

Patrick St-Louis: Is it closed? Seems like depends…

Manu Sporny: Yeah, it seems like it should be closed,…

Manu Sporny: right? All right.

Patrick St-Louis: what that PR is, but

Manu Sporny: So, the specification needs to elaborate on endpoint instances
and that they're configured to perform a series of steps. Can add options
Workflows can be configured to have multiple issue instances. This feels
like it's really old and it feels like John probably raised a PR to do
this. Service configurations and two of them in fact.

Manu Sporny: So this does talk about service instances and I that added a
whole bunch of this stuff. So, this one's probably done. Yeah, I think this
is done. Does anyone disagree that this one's done? All right. So, let's
say 426 and 443 is 426.

Manu Sporny: raise to address this issue. All right, that one's done. add a
protocols endpoint that serves action protocols objects. did we do let's
see interaction exchange. I think this PR did have the protocols endpoint
in it.

Manu Sporny: Yeah, I think we have this in the spec today. Yeah, I don't
think it's listed as an endpoint.

Patrick St-Louis: Is it listed as an actual endpoint or it's just like
somewhere in the documentation?

Manu Sporny: And we do need to list it as an endpoint, right? Okay.

Patrick St-Louis: Yeah, I would say so cuz there's all right initiating
that would be like on the initiating interactions or…

Manu Sporny: So then that means right.

Patrick St-Louis: it's before that they list website and…

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

Patrick St-Louis: VCPI interaction protocol

Patrick St-Louis: interaction URL format. No.

Manu Sporny: Yeah, it's not defined. So we don't define the endpoint. So
that's probably the action. Add full exchange ID protocols endpoint. Yeah.
So we have not done this. This is ready for PR. Okay.
00:30:00

Manu Sporny: So a PR needs to be raised that defines the protocols endp
point and what can be returned why it is useful and what can be returned
from that endpoint. point. So, I'm going to suggest that this is a
loweffort thing because I think all of it's more or less defined. but
Patrick, you are assigned to it. I'm happy to take it because I did the
interactions thing and I can probably kind of continue that,…

Manu Sporny: but you're free to keep it if you want.

Patrick St-Louis: Yeah,…

Patrick St-Louis: I wouldn't mind if you take this one. thank you.

Manu Sporny: All So, I will work through that one. All right. next up is
add support for proof chains to VC API proof proof endpoint. I think we
decided not did. no. What did we decide?

Manu Sporny: PR should be raised.

Patrick St-Louis: What was it?

Patrick St-Louis: Last week we had a discussion that all proof should be
added at the same time.

Manu Sporny: Yeah, it feels like we should close this and…

Patrick St-Louis: Seems related clear.

Manu Sporny: let's see. So we do now say that issuance instances are
configured to do certain things with the proofs and…

Manu Sporny: they should do the things with the proofs all at the same
time. and it is up to them to figure out…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: if they're adding on a proof set or they reject that or if
they chain things together. so I guess the question is,…

Patrick St-Louis: They should return the issued credential they intend to
do it which can mean to remove all the proof and put their own or add one

Manu Sporny: do we need a PR for this or do we think what we just decided
in that other thing is good enough? Do we have text?

Manu Sporny: Did we merge that? I forget.

Patrick St-Louis: So on the section 3.8.1 at the very end right before
2.8.2 too.

Patrick St-Louis: I think it talks a little bit about it. Is it clear
enough?

Patrick St-Louis: It doesn't quite say what we decided, I think.

Manu Sporny: Yeah. Yeah. All right. let's say group discussed this on the
five 57 call and came to a slightly different conclusion based on the
current text at the very end of this section, namely

Manu Sporny:
00:35:00

Manu Sporny: R should be raised to clarify the text above should be raised
to make it clear that the instance configuration determines how the
existing proofs are added to proof chain or an error. It's returned. go
ahead Patrick.

Patrick St-Louis: just losing my hand. I can take this one. it's just
changing that little bit of text to reflect this.

Manu Sporny: Okay, Thank I think effort hopefully is low here. and then
that's Yep. Awesome. Thank you. that one's ready. And then I guess
rendering of arrays of objects. breaks down and there's array of objects.
This is true. We have rendering bugs.

Manu Sporny: does anyone want to take this? I don't think it's effort high.
but it'll take a little bit of time. I can probably take it if nobody else
wants to. that the code is a mess. it needs to be refractored pretty badly.
and since it is partially my mess, I will try to fix that. And that is all
right. Clarify workflow step functionality is the next item.

Manu Sporny: we just sort of talked about this ready for PR. So I think
this is the PR that needs to be raised is it describes the intent of the
steps feature to support branching in repeated steps and then it describes
how templates can be used to implement branching.

Manu Sporny: PR should be raised the two describes how templates can be
used for branching. Let's see. John is not going to be able to join us, but
I think this might be effort low, meaning it won't be hard to raise the
initial PR. We might have to iterate on it, but I think maybe folks will
have opinions once we raise this.

Manu Sporny: anyone specifically want to take this one? All right. If not,
we'll just go to the next item. what is the schema for exchange variables?

Kayode Ezike: I can actually speak to this. So you have a comment I think
last week, but I think this is actually addressed if you click on that from
in the past months ago. I think we've already addressed it So it's just
that this PR had other stuff as well in addition to it. That's why I think
this one got missed, but I think it's safe to close this one.

Manu Sporny: Okay, we'll do that again. Okay, let's see variables fields.
Okay, Awesome. That is good. What is Thought I closed it. Did GitHub stop
auto updating it now..

Patrick St-Louis: was only a preview of the new feature.

Manu Sporny: That's right. I got AB tested out halfway through the call.

Patrick St-Louis: I need to pay
00:40:00

Manu Sporny: Need to subscribe to their new functionality to get it now. I
don't know. GitHub looks like it's struggling. Let's see if another issue
will make it better. unspecified enumeration. that's funny. Maybe it got
stuck. let me reload that. This one had a PR exists. That's all I wanted to
do there.

Manu Sporny: that and then ready for PR. And we're back to this one.
Unspecified enumeration of expected values for template. what did we decide
here? PR should be raised.

Manu Sporny: with the JSON example, noting that JSON is not the only option
choice for templating languages. That feels like a effort low thing. Are
you still okay to take this one, Coyote? All right,…

Kayode Ezike: This is the one you were discussing earlier.

Manu Sporny: thank you. under specified authorization property and
workflows. Okay. What's position?

Patrick St-Louis: There.

Manu Sporny: Got All So, this one should be effort low, All right. and then
change exage ID to ID and exchange creation response. ons.

Kayode Ezike: And it should also be low. I think I had a comment on this
that I put last week or so that not sure if it got addressed though.

Manu Sporny: Looks like there's a design decision that needs to be made
here, but that's fine. that's not what I want to do. there's more
discussion here.

Kayode Ezike: Yeah, I think so. I think the comment was just sort of a
different end point but the other question I had was just around basically
whether it should be the fully formed URL ID or the local ID gets returned
and exchange object and…

Kayode Ezike: I thought it was going to be okay to use the local ID in that
which I think is we use another endpoint specifications. But that was my
question there.

Manu Sporny: Okay. …

Manu Sporny: is there enough to raise a PR that we can take a look at here,
Coyote? Okay.

Kayode Ezike: Yes, this should be enough.

Manu Sporny: Although I'm at a loss as to what are we doing here?

Kayode Ezike: So I think a decision was made earlier about this but it's
just basically we shouldn't be using exchange ID as property name should be
ID instead and…

Manu Sporny: Do we want to return?

Kayode Ezike: there's other stuff that decided as far as the format of what
that value should
00:45:00

Manu Sporny: Do we want to do this where an exchange object is returned
where ID is one of the properties but there could be other metadata with

Kayode Ezike: Yeah, I noticed that too.

Kayode Ezike: I don't know. I think if we expect to have other properties
maybe that are not exchange related I could see that maybe making sense but
yeah I'm not sure. I know there's other end points we have that we don't do
that.

Kayode Ezike: We just sort of provide ID and other information directly and
so I wouldn't suggest it but I think I don't have a strong opinion about it
though.

Manu Sporny: Let's do this for now…

Manu Sporny: because it's a simpler change and then if people have an
opinion on other data that should go along with the exchange, we could do
that at that

Manu Sporny: point which just makes this kind of a search and replace PR.

Kayode Ezike: The other thing about this too,…

Kayode Ezike: so there was something about location which the location
header, returning it there instead, which was something we did add in
another a month or two ago. is that an addition to having it in the
response? It was a thought or is that set to do you think that's the one
that added the location name in one of the PRs get actually the current
endpoint for creating a new workflow does specify that at the moment.

Manu Sporny: Yeah, let me try to see

Kayode Ezike: So I guess nothing really will change there. It's just going
to be the object is returned. Yeah.

Manu Sporny: So, we're with All And that's effort low and it's assigned to
All next item. you have four more to potentially improper format for Create
authorization request step property. okay.

Kayode Ezike: Okay.

Manu Sporny: This would be, I think, effort low if people knew what to
write. and I guess it's kind of explained here.

Manu Sporny: Okay. Yeah.

Manu Sporny: Yeah. So, this property is a true false value I guess for
just, if you want it to autogenerate the authorization.

Kayode Ezike: So I remember one thing that came up in discussion was that
it was confusing me…

Kayode Ezike: because it has a similar fact that it has the create verb.
It's similar to another create property. Forget what it's for. I think I
named it somewhere here but apparently it's not that. So, I don't think and
that one I think is a boolean. I'm not sure if this one is a boolean as
well. from my understanding of it, it's supposed to be a string. If you
scroll up, I think that's what Dave said in the first response.

Kayode Ezike: Yeah, it's supposed to be a string. So entirely.

Manu Sporny: It identifies the name of the variable and…

Manu Sporny: variables that the authorization request will be stored in for
sub subsequent use in the exchange. a string that specifies…

Kayode Ezike: But it's funny that what you said about blooming because
that's the same thought that I had when I first saw it, which is part of
the discussion about whether or not we should change that. But since their
implementations that currently use it, I think there's a discouragement
against that.
00:50:00

Manu Sporny: which value

Manu Sporny: variables will contain the open ID authorization request.

Kayode Ezike: Let's begin.

Manu Sporny: And we might want to revisit since both you and I jumped to
the wrong conclusion there, Coyote. could be that this is a bad name for
the variable and even though there are implementations we might want to fix
that because it does seem not like a authorization request value location
or something like that. I'm not saying that's the right thing to use but
authorization request variable name. that's what it is.

Manu Sporny: So, this one probably could be low effort but might generate
some discussion. All right. And then under specification format for
workflow credential templates property two PRs Yeah, this is high effort
can be done but that will take some work.

Manu Sporny: And then support content type for application LD plusJSON.
let's see. That has been done. And that PR is going in. I think there is a
PR for this one.

Manu Sporny: 481 has been raised to address this issue and it is highly
likely to go in this week. I'm going to close this issue because I think
we're not going to support this and we've already got something going in
that makes it clear. I think we're fine unless somebody I clicked the
button too soon. any objections to closing this issue? Presuming that 481's
going to go in, which really looks like it's going to. Okay, not hearing
any objections.

Manu Sporny: we are down to our last issue to classify array add workflow
step to properly indicate whether domain should be included should be
raised at an example to show how domain variable can be used in a template
to support the use case expressed in this issue effort low because we're
just adding an example or the domain parameter for a challenge response
protocol. Okay, that is it. We have classified all the issues. We've closed
a few. we've got these other four that we need to discuss next week which
we will do. In the meantime, if you're looking for something to do, any of
the effort low you should be able to put those together in an hour.

Manu Sporny: So, please try to find some time to do that over the next
week. we will meet again next week and we'll try to classify these last
four as ready for PR and get those wrapped up and we'll continue processing
poll requests. All right, that's it for this week. thanks everyone for
attending today and participating. we'll get some work done over the next
week and then meet again next Tuesday to process more PRs and get these
last issues taken care of. Thanks everyone. Have a good day. Ciao.
Meeting ended after 00:55:39 👋

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