[MINUTES] CCG VCALM 2026-03-10

This meeting focused on addressing pull requests and issues related to the
BCOM specification. Key discussions included the rechartering of the
Verifiable Credentials Working Group, improvements to schema rendering and
organization, and the addition of a "reference ID" for exchange messages to
enhance debugging and prevent duplicate processing. The team also explored
strategies for improving the readability of the specification, particularly
concerning lengthy OpenAPI schema definitions and examples.

*Topics Covered:*

   - *VCWG Recharter:* The Verifiable Credentials Working Group recharter
   has passed, and the BCOM specification is slated to be published as a final
   community group specification in preparation for its inclusion in the VCWG.
   - *PR 603 - Request Body Schema Fix:* This pull request addresses an
   issue with the create exchange endpoint's request body schema by correctly
   separating variables for creation versus retrieval, specifically removing
   the "results" variable from the create exchange and issue request sections.
   The pull request was approved with a minor change and merged.
   - *Issue 605 - oneOf with required Rendering:* A larger issue was
   identified where the use of oneOf combined with required in the OpenAPI
   specification prevents certain fields, like variables, from being
   rendered, impacting spec readability. An issue was created to address this
   rendering problem.
   - *PR 601 - Accepted Issuer and Crypto Suites:* This pull request, after
   Manu's updates incorporating Dave's feedback, now correctly defines accepted
   issuer and accepted crypto suites to allow for both string and object
   types, addressing the syntactic sugar for simpler cases and more complex
   filter criteria. The pull request was merged after several minor
   adjustments and clarifications.
   - *PR 602 - Exchange Message Reference ID:* This pull request proposes
   adding an optional "reference ID" property to exchange messages to help
   clients and servers track message correspondence and prevent duplicate
   processing, particularly in multi-step workflows. The team agreed to add
   this feature and discussed its implementation details, including renaming
   the relevant schema.
   - *Issue 644 - Multi-step Workflow Example:* The team discussed the need
   for a more explicit example in the specification showcasing multi-step
   workflows where subsequent steps depend on the results of previous ones,
   potentially involving conditional routing or optional VPRs. This issue will
   be picked up by Nate.
   - *Specification Readability and Examples:* A significant portion of the
   meeting was dedicated to discussing ways to improve the readability of the
   specification, including proposals for code folding of repetitive OpenAPI
   schema definitions and potentially moving extensive examples to a separate
   document to manage the spec's length and complexity.

*Action Items:*

   - Manu to implement the agreed-upon changes for PR 601 regarding
the accepted
   issuer, accepted crypto suites, and accepted envelope schema
   definitions, and then merge the PR.
   - Kayode to finalize the change in PR 603 to remove the "results" field
   from the issue request variables.
   - Kayode to create an issue (if not already done) for the oneOf with
   required rendering problem and assign it to Manu.
   - Manu and Dave to rename the exchange participation response
schema to exchange
   participation message and apply it to both request and response messages.
   - Assign Issue 644 (Multi-step Workflow Example) to Nate for further
   development and PR creation.
   - Create an issue to track the improvements for specification
   readability, focusing on code folding for repetitive sections and
   potentially separating complex examples into an appendix.
   - Close issue 599 as it has been fixed.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-03-10.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2026-03-10.mp4
*CCG VCALM - 2026/03/10 14:58 EDT - Transcript* *Attendees*

Benjamin Young, Dave Longley, Elaine Wooton, James Easter, John's
Notetaker, Kayode Ezike, Manu Sporny, Nate Otto, Parth Bhatt
*Transcript*

Benjamin Young: All righty. I think we probably have enough people to get
started. Thanks for coming everybody. This is the BCOM call. I'm MCing
today but I have not been in

Benjamin Young: a complete beall meeting anyway for a little bit. So, my
expectation is that you all have some things you want to discuss. I'm
bringing up the repo and spec and things like that and we can look through
pull requests and issues, but if there is a key topic y'all were hoping to
get back to today, please let me know that because I don't. also Patrick is
obviously out. So if it was something pertaining to meeting Patrick, we're
likewise not going to be able to cover that. But with all that in mind, any
directional thoughts?

Manu Sporny: Yes, that all sounds good to me. Benjamin, we should take
advantage of the fact that Nate's here because I think he had a couple of
issues I was looking at at least one issue that I was looking at where I
needed a little better direction to figure out what to write. So maybe we
can do our regular PR processing and then handpick some issues that Nate
can give some feedback Same thing with Coyote. if there's anything that we
can address on his mind, I think it would be good to take advantage of both
of them being here today.

Manu Sporny:

Benjamin Young: Yeah, agreed.

Benjamin Young: So, why don't we just do sort of some round table updates
and see where those go?

Manu Sporny: I'll just mention this because I'm mentioning it in all the
2026 verifiable credential working group recharter vote have passed. that
was really good. Lots of companies voting in favor, 40 plus organizations,
no formal objections. That went And then at the very last minute the
European Union folks came in and said, "Hey, we want you to also include
digital product passport and the European business wallet stuff." so that
was put into a proposal to be included and then when that happens at the
last minute, you have to go and ask everybody that voted again, are you
okay with that update or do you object to that? that happened last week.

Manu Sporny: I haven't heard the outcome of that but I don't think I would
be surprised if anyone pushed back but we'll find out on Wednesday during
the verifiable credential working group call. this work item is included in
the new charter. so we should start thinking about all of the levers and
buttons we have to pull and push to publish this as a final community group
specification to prepare it to be pulled into the verifiable credential
working group.
00:05:00

Manu Sporny: Typically we do that right as the VCWG is voting on pulling it
in because it does have to go to a working group vote. they have to vote to
accept this specification as input. Once they do that, then, it doesn't
take but an hour or two to, do the thing to publish it. But it does require
the chairs to get involved on both sides and everyone's busy so that can
take up to a week to do. So just a heads up that at some point we're going
to pull the rip cord and this thing's going to go out as in its current
form. It doesn't have to be perfect.

Benjamin Young: Awesome. Thank you,…

Manu Sporny: We just publish a static version of it. and then we'll just
need to do that. That's it.

Benjamin Young: Any questions or comments about that before we get updates?
Okay, Nate, why don't you go first and then Kyote, you can go after

Nate Otto: All right. So, I was looking through the issues list and the one
that I see that is open north toward the top that was by me is 599. And
that I think is the one that Coyote has something to speak for. Pull
request 603 is one that I think fully addresses it.

Kayode Ezike: Yes. the answer to that if we were to open the pull requests
tab we can see that and that is going to be the one at the top and…

Benjamin Young: Sorry, I missed the number.

Benjamin Young: What was the number?

Kayode Ezike: sorry that's the 603 is it the one at the top?

Benjamin Young: Okay, great.

Kayode Ezike:

Kayode Ezike: Yeah. Yep. So what this no problem.

Benjamin Young: Thank you.

Kayode Ezike: What this is doing is essentially just fixing an issue with
rendering that happened as a result of the request body schema for the
create exchange endpoint incorrectly including a results variable inside of
there. It's not supposed to because at that point when you creating
exchange you don't have any results to speak to. So what this is is it
separates out variables for create exchange endpoint and the one for get
exchange endpoint and any other sort of retrieval based variables that we
get. And so the only difference really between the two is that the create
one is a amorphous object. So there's no fields that are specified within
it.

Kayode Ezike: it is worth noting that currently the only variable that's
actually defined in the specs one and so the only way to I guess not
include it would be to just have an MG object that allows folks to include
anything in there. and I also noticed that the exchange variables was also
used within not only create exchange and get exchange but another area
forget exactly which section that is looking that really quickly.

Kayode Ezike: So I think it was issue request but let me just quickly see
if I can give me a second so it's going to be underneath issue request
variables and this actually made me realize something as I was going
through this PR which I was just in the middle of creating an issue which
is that in the issue request

Kayode Ezike: I noticed something that's a bigger issue not just with that
field but with others as well which I can get into in a second but
basically some fields are not showing up whenever we use one of coupled
with required and so I noticed that the place where I changed that get
exchange variables in the issue request scope is actually not even rendered
in the spec because of the way that we're using one of coupled with
required.

Kayode Ezike: So I can get into that a little bit later. But in any event,
the main thing maybe were that I can ask about that is it correct to
include the results field inside the variables for that issue request
section as well because currently it does include it there too. So that's
the first question that's a little bit more easily answerable maybe.
00:10:00

Benjamin Young: So line the line I have highlighted here 1154.

Kayode Ezike: Any other questions? So happy to answer them.

Benjamin Young: That's the one you're still have questions about.

Kayode Ezike: And the main thing here is so the way it's implemented will
include the results variable in it. And so my question is that proper to
include it also in the issue requests? That's my first question. is it
proper to include that variable inside the issue requests?

Benjamin Young: Good.

Kayode Ezike: Variables.

Dave Longley: we probably don't want to put it there. it's not incorrect to
have it there, but in the same way it's not incorrect to have results when
you're creating an exchange. It's just awkward and probably no one would do
it. And the same applies here.

Kayode Ezike: All So then I'll just create exchange on here instead and
that'll go with that. so that addresses that and then I can bring up the
other question after we decide if there's anything else that needs to be
done with this outside of that change.

Kayode Ezike: So any feedback I take the silence says either we need more
time to review it or that we're happy with just me making that one change
and merging it afterwards. So if that's the case go ahead.

Manu Sporny: Yeah, I mean I don't know enough to have any good opinion on
this. if Nate is happy and it addresses this issue, that's good enough for
me. And if Dave's going, I don't see anything wrong with it, then that
sounds good. you had mentioned I think Dave was like, "Let's not do this
one thing." I guess that's going to require you to make a change and then
we can merge after that.

Manu Sporny:

Kayode Ezike: Yeah, pretty much.

Manu Sporny: Okay.

Kayode Ezike: Yeah, just that one line. Yeah, we'll change it.

Manu Sporny: All right.

Kayode Ezike: Yeah, we'll do that shortly. Probably before the end of the
call and…

Manu Sporny: Cool.

Kayode Ezike: then Sounds good. and then if it's okay to discuss another
thing related to this unless you want to just process all the PRs first but
okay so what I was getting at is that if we I guess maybe it'd be easier to
look at the OAS file so if we were to open that file what you'll see is
that go we search for the issue request that same section where

Kayode Ezike: what you had it highlighted before. Yeah, exactly. The one
thing that I noticed is that the way we structured this the way we're using
one of and where we have the required restraints underneath. So I guess
this is line 1155. that's resulting in issues where for example the
variables field is not getting rendered. I just noticed this and it occurs
in a few places and s this is I think one of three places that it occurs
and so that's a problem because then it means that people are not going to
know that this is an op these are options if it's not listed but I've tried
to find ways to fix it just for all the different instances that shows up
but I wasn't able to find a way that works across all of them so I think
it's really a respspec issue too it's not for all renderers but it's just
something that I've noticed as a problem yeah go ahead Hang on.

Manu Sporny: Yeah, there's probably some corner case that isn't covered in
the respect OAS plugin which is hack upon hack because it's kind of evolved
beside this specification it just requires somebody to kind of look at the
code and I apologize for all It was me that created all those hacks. But we
probably just need to look at this particular code path and then see that
just figure out why it's not triggering the proper rendering.

Kayode Ezike: So I was creating the middle of creating issue for it. So I
can just create that really quickly and then maybe assign you or myself to
it and we can address it later.

Kayode Ezike: That's all for me.

Benjamin Young: Okay, sounds good.

Benjamin Young: Thank you, Cody. Do you want to pick the next topic?

Benjamin Young: Just keep going down the list. Yeah. Okay.

Kayode Ezike: that are you asking me or…
00:15:00

Kayode Ezike: I see this popcorn style. Yeah, I guess we can go to the next
J sounds camera for Cory B.

Manu Sporny: And I can cover that one since so this was raised a month ago.
Dave Long only asked for a couple of changes. if we scroll down are the
requested changes. I have made those changes as of 15 minutes ago, 19
minutes ago. And I think it's good to go. but it would be good to get I
think it's fine if folks want to take a look at it. we should be able to
merge it now. I did have one question now that I think of if we look at the
change log are good.

Manu Sporny: Sorry, I'm doing a PR review as I'm doing this. files changed.
Yeah. And if we go down to recognized in maybe. that one. And if we go down
to accepted issuer, there's a component down at the bottom. keep scrolling
down. It's the definition of accepted issuer. Yeah, So that can be a string
like it did a URL did or it can be an object that has recognized in and
then it's going to point to a verifiable recognition credential which is
basically like a list of approved parties. I totally forgot the format of
that thing. Is that what you were thinking Dave? Now I have to go look.

Dave Longley: Yeah, but we should also cover the case that you want to put
the ID in the object case. So the string case is really just syntactic
sugar for the object case. And then in the object case the first use case
we have is put the ID property in there and put the ID of the issuer. And
then other use cases are put other properties there that would allow
someone processing the query to instead of having a direct ID but instead
of having the ID property find an issuer that meets the requirements such
as recognized in.

Dave Longley: So I don't think we would say that recognized data is
required and we should also have ID there. So it's more like a set of
filters.

Manu Sporny: Gotcha. …

Manu Sporny: so string and andor ID recognized in one of those All right,…

Dave Longley: Yeah. as our first set of use cases that can go into this PR.

Manu Sporny: let me go ahead and add that. So, I'm happy to add those
things. And then if I add those, are we good to merge?

Dave Longley: I was scanning for anything else. I mean, we're probably
good. does the accepted I'm trying to parse the JSON schema here to make
sure that the accepted issuers and…

Benjamin Young: Go ahead.

Dave Longley: accepted crypto suites allows either a string or an object.
And I'm not sure it does that now.

Nate Otto: In accepted envelopes line 213 where does one of these examples
I see v verifiable credentials signed with an LDP like a data integrity
proof.

Nate Otto: I mean these are just examples not necessarily everything you
can use but do we have a media type for application VC with a data
integrity proof?

Manu Sporny: We do.

Manu Sporny: And is it? We should have that in there, I'm just going to add
it as a application slashvc.

Dave Longley: I was busy processing something else.

Dave Longley: What are we adding? Yeah, this is not the envelope format.
So, we don't need it. application VC is not an envelope, it is a VC. So
that the accepted crypto suites covers that because you attach the crypto
suite to the VC without having to envelope the data format with another
format.

Manu Sporny: This is But it's not an enveloped thing. Yeah.

Nate Otto: Okay, thanks.

Dave Longley: The other thing we're missing here is it's good that it's on
the screen here.

Dave Longley: it says accepted issuer and we have one of for string or
object and we have the same thing correctly under I think if we go down to
accepted we don't have it for accepted envelope and we don't have it for
accepted crypto suite both of those should also be one of either a string
or an object so all of those fields accept syntactic sugar where if you
just put the string It refers to the most simple property version of it.
00:20:00

Manu Sporny: All right, I can make that change too. Also, I hate JSON
schema so much. let's see for accepted issuer allowed or object with ID or
object containing recognized for what is this accepted crypto suite and
accepted envelope allow either a simple string or an object.

Manu Sporny: an object that yes okay all right so all the changes are
update accepted issued allow a URL did string or…

Dave Longley: Yeah, that's

Manu Sporny: an object with an ID that is a URL did string or an object
containing recognized in which then is a URL did string and for accepted
crypto suite and accepted envelope, allow either a simple string or an
object that matches the current schema definition.

Dave Longley: And then if we look at credential query, in this schema it
requires an example and I don't remember I think that it would be new to
require that example. I don't know that we require it. so if you scroll to
the bottom of that, in this JSON schema, that's where the required
properties are at present. So keep going. Yeah, line 87. I don't think we
have those requirements in the spec that you have to put those two fields
there. so we might not want to put that in the schema now because we'd have
to think through there might be existing use cases where no example is
given a wallet is just announcing that it accepts certain cryptoes and
envelopes for any kind of VC that they're about to receive.

Dave Longley: So there's no example needed. Though we could say I don't
know if there existing implementations that do that without an example but
the other way to do that is to have an example just be an empty object.
because then you don't put any requirements on the example. if we scroll up
to example I don't know if there are requirements within the example
property that we might have to change. yeah, if we go to credential
example, can we see what the requirements are there and the requirements
here? Let' let's scroll down to what's required for that's probably at the
bottom as well. Yeah, those requirements are also too strict because you
can use this to request a credential that does not for example have a
context.

Dave Longley: you could ask for an MDL expression. and it would not have
type or credential subject either. So I think we just remove the line 165
and line 87 until we figure out if we need to have any required properties
and what those are.

Manu Sporny: All right, I'm making those as change suggestions in the PR.
So remove reason. I guess we are abandoning reason.

Dave Longley: Yeah, that's right.

Manu Sporny: All right. So both of those things now we're just like do not
require any of these fields. It's totally dependent on what you want to
have So, those two have been made as change suggestions and then there All
right. Any other desired changes? Okay.

Manu Sporny: If not, I will make those changes after the call and then make
one last check to make sure that the schema is valid and then I'll merge
unless there are any objections. All right. Thank you for the eagle eyes.
00:25:00

Benjamin Young: That leaves us with one PR. It's from Patrick though who's
not here. anyone have a guess at the state of this one?

Dave Longley: My guess would be he hasn't gotten to it.

Benjamin Young: Yeah, not in a minute. okay, we'll skip that one. It's
apparently quite behind Go ahead. Nice.

Kayode Ezike: Yeah, I was just going to say that I updated made the request
that Dave asked for and also created an issue related to the issue request.

Benjamin Young: …

Kayode Ezike: One of required issue looks like it. Thanks.

Benjamin Young: are we good to merge this one then? All righty.

Benjamin Young: Are we typically rebasing and merging? It's fine.

Manu Sporny: Yes. Three basin merge.

Manu Sporny: Unless the history is not clean, but I think Coyote keeps
clean history. Yep.

Benjamin Young: Okay, that's done. Thank you, K. And you said you created
an issue as well. Maybe

Kayode Ezike: Yes 605.

Kayode Ezike: Pretty much just reiterating what I mentioned earlier and…

Benjamin Young: Okay.

Kayode Ezike: yeah sign to you but happy to support anyway with that any
Okay,…

Manu Sporny: Yeah, please do. I'm probably not going to get around to it
unless I find myself in respect OAS fixing another bug.

Kayode Ezike: sounds good.

Benjamin Young: All that finished up poll requests. We're about halfway
through the call. was there anything else top of mind y'all wanted to
tackle? If not, we'll just chip through probably the unlabeled issues
mostly. Okay, keep working our way down.

Benjamin Young: Dave, you just filed this one an hour ago. Do you want to
I'm going to

Dave Longley: Yeah, this is a suggestion that we add an optional property
to exchange messages. I recommended it be called reference ID based on a
similar feature that's already in the invite request protocol that's in the
spec. the idea here is so exchange properties today can include the
properties we have defined are verifiable presentation and redirect URL.
And I noticed that if you're implementing workflows that have a significant
number of steps this becomes more obvious but it applies to any number of
steps.

Dave Longley: It's nice to know that when a client responds to a message
that they're responding to the most recent message. And one way to do that
is to include a reference ID so when the server sends an exchange message
that's like send here's a VPR please send me some VCs. It's nice if
something like a reference ID is in that request so that when the client
responds and they include that reference ID you can see that they meant to
be talking about the current state of the exchange.

Dave Longley: It's conceivable that a mis implemented client or a slow
message could come from the same client that's has accidentally responded
to a message twice, for example. And in the rare case that two steps might
be implemented that might possibly accept two similar responses, you would
want to be able to distinguish those. And having this feature helps with
debugging and helps servers prevent duplicate messages from being
accidentally processed as if they weren't duplicates. Hopefully that
explanation makes sense.
00:30:00

Manu Sporny: Does this create an issue? no. I think it sounds fine. I is
this much more useful if you have branching in your workflow?

Manu Sporny: Like I'm wondering

Dave Longley: I much more useful is a little bit too strong…

Dave Longley: this is useful even if you have one step. it's because it
helps you more explicitly determine that a mistake was made by the client
as opposed to implicitly guessing what happened. but that becomes more
important the more steps you have which often includes more branching but
branching steps are more likely to surface a problem like this. so I guess
the answer to that question is yes.

Manu Sporny: And then let's see. I guess what's the guidance on what the
reference ID should be? I mean, should we just tell people create a UU ID
for every just Okay.

Dave Longley: I would say create a UYU ID. I would say the server may
include it in their messages. If the client sees it, they should include it
in their response.

Dave Longley: But none of that's required to make things work. It just
really helps in the cases where things aren't working properly.

Benjamin Young: do we want to call up?

Benjamin Young: It should probably be a UU ID here.

Dave Longley: Yeah, that's fine as a suggestion when the text goes in.

Benjamin Young: Whoever's going to write this

Dave Longley: And that should also be a common pattern that people have
experience in writing other HTTP APIs is to include these sorts of things
for debugging and making sure stuff lines

Benjamin Young: Anyone have other thoughts?

Manu Sporny: We should make notes on the PR market ready for PR and meaning
tell the PR writer exactly…

Benjamin Young: Great. Yeah.

Manu Sporny: what they should be writing and…

Manu Sporny: let me try and find this issue. Where's this issue 64?

Benjamin Young: Here, drop it in chat.

Manu Sporny: Got it. PR should be raised. that may be raised that says that
a server may include a reference ID in is it just a VPR or…

Dave Longley: let's start with May. It could be as strong as should but
certainly May is good enough for now.

Manu Sporny: in a Okay.

Dave Longley: No, it's not in the VPR itself. It's in an exchange message.
I don't know that we have a name for those, but it's where those other
properties appear.

Manu Sporny: other properties here. And if the client sees it, it should
include the reference ID and the response to the server. Debugging the ID.
Do we want to say must be a uruid or it's just should be a UID value. It's
like that.

Dave Longley: Yeah, what you said sounds good.

Manu Sporny: No, it's not. Okay. I did. What is going on?

Benjamin Young: I'm reloading.

Manu Sporny: There we go. Okay. I thought it was I know.

Dave Longley: You're not sharing your screen, so

Benjamin Young: Yeah, right.

Manu Sporny: I I was just surprised it because sometimes At least it used
to auto pop up, right?

Benjamin Young: Yeah, it usually does. Not today anyway. Thank you, M. Go
ahead, Nate.

Nate Otto: probably a PR writer can figure it out themselves, but should we
include a specific list of end points which request bodies and response
bodies would have this property? does it go as far as the get workflow
configuration? Is it just the post requests?
00:35:00

Nate Otto: Is it just the stuff in the scope of an exchange rather than a
workflow? I see we also have it in the invite request protocol. So it's
slightly beyond just exchange participation.

Dave Longley: I think this issue is just about the exchange participation
those other calls might have implicit maybe that's the wrong word to use
here those other calls have …

Dave Longley: if you're creating workflows or doing updates they already
have some mechanism like that I think this is the place that's missing such
a mechanism. There's no sequence id reference identifier for you to know
what the other parties responding to. And the other APIs allow you to
easily detect duplicates. I'm pretty sure that's true for all the other
APIs at this

Benjamin Young: Okay.

Manu Sporny: So just to clarify, it's so what I updated to exchange
participation response. Thank you, Coyote, is the schema that we need to
make that Yeah.

Dave Longley: Yeah, that'll be the response one. I don't know if that
schema covers both directions. It says response in the name of the schema,
but maybe it's used in both directions, but it's just important for it to
cover both directions.

Manu Sporny: Okay.

Dave Longley: Yeah, I don't know if there's an exchange participation
request or if it's just the same schema.

Manu Sporny: Let's change participation request. I'll just Put question
mark around it.

Dave Longley: You'd have Benjamin, you'd have to look at the OAS file to
find that text.

Benjamin Young: Yeah, I was getting there towards that realization anyway.

Benjamin Young: Yeah, I'm only seeing response and it's all used in one
spot.

Kayode Ezike: and yeah what I noticed is that s basically where it would
have been defined we're actually not using a schema for it so it just lists
out u repetition request representation and it actually doesn't even list
out the third one I guess redirect URL. So, we can either update that to
use to refer back to a schema that's either the same one as this or renamed
it to request, but it ultimately is probably going to have the same body
So, there's a bit of redesign that had to happen with the schema naming and
creations. Yeah.

Dave Longley: Yeah, reusing the same schema in both places would be good
and… maybe just calling it participation message.

Dave Longley:

Benjamin Young: sounds right to me.

Benjamin Young: Do we want all that written up?

Manu Sporny: Yes, because it will be forgotten.

Benjamin Young: Do that.

Manu Sporny: If we don't write it down. So, let's see. yeah.

Benjamin Young: You going to do it in yours?

Manu Sporny: …

Dave Longley: So rename exchange participation response to exchange.

Manu Sporny: where that hold on,…

Manu Sporny: wait. …

Dave Longley: Exchange participation response to exchange participation
message and…

Manu Sporny: I was typing in okay.

Benjamin Young: That's the line.

Manu Sporny: What rename participation and…

Dave Longley: use it around line 303 for the request as well as the
response.

Manu Sporny: also use it around line what 303 Three 63 and…

Dave Longley: Yeah, it's somewhere around there.

Benjamin Young: It's 3:19 on Maine.

Benjamin Young: K.

Dave Longley: Yeah, the request bit is around 303 I think was on the screen.

Manu Sporny: 319 in both cases.

Dave Longley: Yeah, those are lines. Yep. To look for

Manu Sporny: Okay.

Kayode Ezike: I think I forgot to load my hand, but since Nate put up a
good question, do we expect that clients would also be able to send back a
redirect If not, then they should be separated to different schemas.

Dave Longley: Yeah, something to keep in mind is we might want to split
that out, but we might want to leave it. It would be a good exercise to
think through what that would mean. for a server to be told to go to
complete an exchange somewhere else. It's important to remember that a
redirect URL can carry an interaction URL in it. And so it's not that
you're being told to go view a website in HTML. You could be handed an
interaction URL to be told to go continue and exchange somewhere else. And
that could be a way for a client to signal that a server is meant to switch
and become the client and go interact somewhere. So that root use case
should not be ruled
00:40:00

Benjamin Young: Sounds good. In other news, it does look like GitHub
refreshed the changes without me touching anything. do we have enough here
for somebody to pick up VR? I would think so. Okay, Nate, you excited about
this one? Can I assign it to you?

Nate Otto: Yeah, I can take it.

Benjamin Young: Thank you. somebody else is going to have to. There's only
three people on the list.

Dave Longley: is yeah, GitHub handles autonomy.

Manu Sporny: I got it.

Dave Longley: I don't know if it

Benjamin Young: Nice.

Benjamin Young: Yeah, I don't know if I could have seen that. Time for at
least one more. long way. This is you again. Multi-step workflow example.

Dave Longley: yeah, let me remember yeah, this is just I don't think what
we don't have as an example in the spec today is showing multiple steps
where subsequent steps rely on results from previous steps and someone
reading the spec and trying to implement it could figure out, hey, I can

Dave Longley: do some neat things where in the first step if the client
presents X my workflow service will store that result and then the second
step can be a template that can use that result to decide what to do in the
second step and so it's like we have the basics of prim b we have some
basic primitives and basic basic code that you can run through templates
and variable

Dave Longley: And it would be good to more explicitly show someone, hey,
you can do this neat thing with your steps based on these primitives.
someone could figure it out, but it would be good to have that as an
example. And I think I listed one possible example which I'd be reading
here now to remember it. this example is an exchange client can send its
own VPR. So when it starts an exchange, it could say, I want a certain
credential from you before I'm willing to do something like give me your
registered business VC for example. And if the exchange is set up to allow
that sort of thing to happen, the first step would just be optionally give
me a VPR and…

Dave Longley: if you don't give me one, I'll just go to the next step. If
you do give me one then I will potentially make a different choice in that
step and what the next step is. Hopefully that made sense.

Benjamin Young: when you said and…

Benjamin Young: what the next step is. there's some routing based on what's
in the first step. So it might skip steps.

Dave Longley: Yeah, the second step will look different. And I think I
mentioned here there maybe being a third step. I don't know, maybe I didn't
mention that.

Benjamin Young: Yeah, you did in include the issued PCs from step two in the

Dave Longley: Yeah, none or a third step, is determined by this choice. I
mean, it's just probably the best thing to do is to have a three step
workflow that shows in the first step something's received and… optionally
received. In the second step, some kind of response is made that determines
what the third step will be or something along those lines.

Dave Longley:

Benjamin Young: If this second step is an optional response,…

Benjamin Young: does that mean you're possibly going to just advance to
step three and get a final response?

Dave Longley: Yeah, I meant the first step would be the optional response.

Dave Longley: It's which is yes,…

Benjamin Young: Okay. Gotcha.
00:45:00

Dave Longley: the first step is if you send me a VPR, I'm going to save
that VPR and the second step might do something different or we should do
something different. And then based on how you respond to the second step,
we can make that do something different there. You might be able to
simplify this down to two steps, but it might be nice to show three for
branching so people can understand, hey, you can do a lot of different
things with this without while allowing a coordinator to outsource all of
that to a workflow.

Benjamin Young: Gotcha. Anyone have thoughts on this?

Manu Sporny: We would need a concrete I'm trying to figure out what's the
concrete thing that we'd end up using in the examples. Struggling.

Benjamin Young: Go ahead.

Nate Otto: I'm generally okay with this. I do note that the workflows piece
of the spec is potentially quite complicated. It is good to be able to
provide some documentation. I wonder if there is any ability to ship a
second document alongside the core specification where we can split out
more advanced examples. because I'm familiar with the open badges spec is
very long and the length of it provide poses a barrier to adoption in some
cases and…

Benjamin Young: Good night.

Nate Otto: we have developers not noticing and knowing about certain
sections of the spec because of the overall length. up. Just curious there.

Manu Sporny: Yes, plus one to that. I was just thinking about that. I was
also reading about there was another issue we had where it's show a
complete open ID for example and it's pages and pages of config things and
protocol responses back and forth and I mean and we already have complex
examples in the spec I think we're going to take up 30 pages in the spec
just with protocol messages back and forth plus one to

Manu Sporny: that I think we can have a spec that's a examples appendix or
something like that. I don't think we should do an implementation guide or
anything like that. We're just like hey if you want to see some really
involved examples go here and check them out and try to keep the spec a
little cleaner. the other thing I was considering is do some code folding
for let me go back. The vast majority of the spec is OAS just reprinted
over and over and over again, right?

Manu Sporny: and while it's nice to have all of that it's very accurate,
it's just wall of text and you don't care about most of it until you really
want to know what the object is. So I'm wondering if we should do some
display folding if we look at section 352 create presentation that thing
property description this entire thing maybe it starts off folded and you
click a little button and it expands.

Manu Sporny: that might help a lot with kind of readability in the spec or
I have a button that's expand everything I'm implementing. I need to see
everything, so two proposals there plus one to what Nate's saying. I'm
getting concerned about the amount of, example stuff. and maybe we just
want to put that in a separate document but within this repository. So you
just click on it and you just go to something that's just protocol messages
and data objects and then for this spec do some code folding on the
repetitive tables and things like that. we stop

Dave Longley: Yeah, I just wanted to say Nate brought up the same point
last week. and we talked about how a lot of those OAS specs have things and
here's where you put a verifiable credential and there's no reason for us
to have to expand the whole definition of what a VC is. even a spec
implement is not going to care about that. They're probably never going to
unfold that. So, being able to make those sorts of distinctions is
important, too.
00:50:00

Manu Sporny: I'm not following …

Dave Longley: I mean I mean so you're submitting a verifiable presentation
there.

Manu Sporny: what concrete thing would that change

Dave Longley: In this particular case that's on the screen it would be what
goes here is a JSON LD verifiable presentation. that whole thing could be
rolled up. There are some other places where we might need a contextual
hint or something in the OAS for what to don't know but the general idea
folding is great. I don't know if we need to go even further and fold
specific things for specific descriptions based on…

Dave Longley: what makes contextual sense and we might have to know that
for the different calls.

Benjamin Young: Yeah. …

Benjamin Young: I'm also noticing that this text mentions a VP without a
proof and then the object description includes a proof.

Dave Longley: That's nested under verifiable credential.

Benjamin Young: That rendering is terrible. Yep, you're right.

Dave Longley: Yeah, because the wall of text makes it too hard to even see
that. Yep.

Benjamin Young: It's too long. it'd be nice to collapse them maybe one by
one. Go ahead and trunk.

Manu Sporny: Plus one that, if you go to section 362, that's another
example, Benjamin, of something that's just like, are you kidding me? roll
scroll down, right? It's just like you got all that,…

Benjamin Young: Yeah. Who shrunk to?

Manu Sporny: right? Yeah.

Benjamin Young: We have an example in

Manu Sporny: Yeah. Mhm.

Dave Longley: Yeah, that's an example of…

Dave Longley: where I think you specify maybe a verifiable presentation
request within a step. and it's like there's no reason to need all a couple
lines down from that says verifiable presentation request and that's just a
VPR goes here. that should not be unrolled like that. And that's the sort
of thing where you would know contextually you don't want that to probably
we have a step schema and the step schema might need a note or something. I
don't know that sounds like more work for someone to write but in the YAML
you could say hey don't unroll this in the step schema. Someone could click
it to unroll it…

Benjamin Young: Right now,

Dave Longley: if they want to, but it's not useful usually.

Manu Sporny: So, I think we've established let's figure out a way to make
this easier to read. and it's either going to be autofold everything or
fold based on hints. And that's just, code that someone has to write into
respec oas. if there is also a better way to render this stuff, and you've
got ideas, please suggest. This is just what I did in the beginning because
we're at the very tip of the spear and doing this at W3C. No other group
that I know of is doing this. because they haven't had to yet.

Manu Sporny: And if there is a better way to render this or you've seen a
better way to render this, please us know. the other thing to point out and
I don't know if a lot of people know that this spec can do this, but there
are endpoints that you can go to. Let me try and find all right one second.
where is the repository link? there are endpoints that you can go to that
will render. here we go. So if you go to this endpoint, it will take the
OAS and use RedO to render it. And there we also do Rapid Do and Swagger
outputs as well. takes the exact same thing and renders it using this other
mechanism. So there are multiple views on the specification.

Manu Sporny: We had initially done this because Ary was like I want to see
absolutely everything. don't ask me to implement something when it's not
written down in the spec. I want every single variable on the screen. So we
tried to figure out a way to make that happen. I think at this point it's
gotten a bit unwieldy. So, concrete takeaways from this is maybe we start
off seeing if we can do some hinting at things that should be collapsed.
and if that's difficult, then we auto collapse everything.

Manu Sporny: auto collapse the entire table and maybe just talk about the
top level, attributes and say, "Hey, click here if you want to really see
the gory details." I don't think it would be good to make people jump
between different documents to see details. That probably isn't good. so
yeah, there's some things that we can try out here. But I think the goal
here is let's see if we can collapse these things by default in the spec
and only when you want to see the details do you click the button to see
the details.
00:55:00

Manu Sporny: Yeah, that's a

Benjamin Young: Sounds good.

Benjamin Young: Do we want an issue for that? I mean, is it some point
it'll be Yeah,…

Manu Sporny: Yeah, might as well track

Benjamin Young: I don't think it's a discussion issue more for a Okay.
GitHub's not happy with me today.

Benjamin Young: get some of your examples. This one was the worst, I think.
Yeah, I'm just going to stop there. and whoever's into UX tomorrow can fix
it and send us a PR because I'm sure it's easy and fast. Okay, we're down
to three minutes. I don't think we're going to open another can of worms.
Cody 599.

Kayode Ezike: I just want to say feel free to close issue 599 now.

Benjamin Young: This one has fixed in.

Kayode Ezike: Yes. 603

Benjamin Young: Okay. Something is not loading at all. There it goes. Yep.
And thank you for that. Awesome.
Meeting ended after 00:57:49 👋

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