[MINUTES] CCG VCALM 2026-03-03

This meeting focused on updates and discussions within the WTC Credential
Community Group. Nate Otto presented the newly published interoperability
guide from the Strata Education Foundation, which offers profiles and
recommendations for using VCOM exchanges for credential mobility. The group
then delved into a time-boxed discussion on the complexity of VCOM workflow
primitives, weighing the benefits of supporting complex use cases against
the potential for making simple implementations too burdensome. The
conversation also touched on the challenge of preventing vendor lock-in
through standardized workflows and the difficulties in presenting complex
specifications in a user-friendly manner.

*Topics Covered:*

   - *Interoperability Guide Presentation:* Nate Otto shared the release of
   the interoperability guide from the Strata Education Foundation, detailing
   its purpose in providing guidance for building credential ecosystems and
   its specific focus on VCOM exchanges for open badge mobility. The guide
   offers profiles and workflow steps for developers and ecosystem
   coordinators to ensure interoperability.
   - *VCOM Workflow Primitives Complexity:* The group discussed whether the
   VCOM workflow primitives are too complex, potentially hindering adoption
   for simpler use cases while trying to support more advanced ones. A balance
   is sought between accommodating complex scenarios and maintaining ease of
   implementation for common workflows.
   - *Preventing Vendor Lock-in:* The discussion explored whether VCOM
   workflow definitions effectively prevent vendor lock-in, with perspectives
   suggesting that while standardization can mitigate costs, it may not
   entirely eliminate the issue. The idea of "mitigating" vendor lock-in
   rather than "preventing" it was considered more realistic.
   - *PR Review and Issue Discussion:* The meeting included a review of
   open pull requests and issues. A PR by Nate Otto to add an example for
   interaction URLs in the VCOM spec was merged. An issue raised by Nate Otto
   regarding the create exchange endpoint and its variables was discussed,
   highlighting a need to differentiate between variables for creating an
   exchange and those for getting the exchange state, potentially through
   separate OpenAPI definitions.

*Action Items:*

   - Patrick St-Louis will consider opening an issue to further discuss the
   balance between specification complexity and usability, particularly
   regarding workflows and preventing vendor lock-in.
   - The discussion on VCOM workflow primitives and their complexity will
   be revisited in the next meeting.
   - Dave Longley and Nate Otto will further investigate how to improve the
   presentation of complex sections within the VCOM specification, possibly by
   drawing inspiration from the newly released interoperability profiles and
   considering alternative documentation or presentation styles for developer
   resources.
   - An issue regarding the create exchange endpoint variables will be
   addressed, likely leading to a PR to refine the OpenAPI definitions to
   better distinguish between creation and retrieval states of exchange
   variables.

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

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

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Eric Schuh,
James Easter, Joe Andrieu, John's Notetaker, Kayode Ezike, Nate Otto, Parth
Bhatt, Patrick St-Louis, Ted Thibodeau Jr, Tom Jones
*Transcript*

Patrick St-Louis: Hey everyone, welcome to the call. we'll get started in
two or three minutes.

Patrick St-Louis: I'll get started in a minute.

Patrick St-Louis: Okay, let's get started. people might trickle in and
they'll be able to catch up in the next few minutes. Welcome everyone to
the WTC Credential Community Group VCall meeting. today is March 3rd, 2026.
this is a WGC meeting. So W3C policies are into effect today for the calls.

Patrick St-Louis: So, we're going to go through our regular introductions,
community updates, P review issue assignment, and I also captured a time
box topic of the VCOM workflow primitives and what everyone's experience
has been implementing them. There was a short discussion on Slack about
this. So, maybe we can time box to 15 minutes to discuss this and see if we
need to raise an issue. without further ado, let's get started. Any s
reintroductions? we'll leave you a couple of minutes to raise your hand.
Okay, let's move on.

Patrick St-Louis: if there's any community updates or any specific topics
people would like to discuss, please let us know now before we get started.
I've just remembered you had presented something last week, Nate, and we
kind of discussed maybe a presentation. did you plan something for today or
should we postpone this? I just remembered we discussed that last week.

Nate Otto: I didn't plan anything specifically for today, but I am happy to
talk for a few minutes about the interoperability guide that I released
with the Strata Education Foundation.

Patrick St-Louis: Yes, definitely.

Nate Otto: It doesn't require a lot of preparation.

Patrick St-Louis: Okay, that sounds good. so the last time you mentioned it
was about to be released. So, has it been officially published now or is it
in a similar state?

Patrick St-Louis: Or maybe you go ahead and talk to us.

Nate Otto: Yes, it sure.

Nate Otto: So let me go ahead and share a link in the chat which is
mobilityc collaborative.org. this is a website which is now published it
includes a few three in this case interoperability profiles for using open
badges verifiable credentials.
00:05:00

Nate Otto: One of the profiles, the VCOM in the title, specifically
provides recommendations for how to use VCOM exchanges to move open badge
credentials from issuers to, holder systems, wallets, and then from those
holder systems to verifiers. The idea of this guide, which is situated
within a larger website, learning mobility collaborative.org, is to provide
guidance to people who are trying to build successful ecosystems where
there is end credential transferability for the purpose of learning
mobility.

Nate Otto: the website defines five what they call verticals for learning
mobility use cases which involve mostly in the education and workforce
sector that involve aligning skills or competencies between educational
institutions and employers and then recognizing the qualifications of
individuals and consuming them for the purposes of getting those folks
jobs. one of the key technologies for doing these use cases is digital
credentials and verifiable credentials is one of the models that's
prominent there. Open badges the schema that's probably the most prominent.

Nate Otto: there's also the comprehensive learner record standard from one
tech and then forthcoming is something from open called a trusted career
profile or TCP which is a document format that is like a JSON version of a
resume. It includes information you might find on a traditional paper
resume but including the possibility for verifications of skills and
experience using credentials. in any case, learning mobility, there's a
bunch of different reasons why you might want to organize an ecosystem, but
the organizations that want to do that, which are often state governments
or workforce development boards in collaboration with public or private
educational institutions and industry groups such as chambers of commerce
or manufacturing industry collaboratives, etc.

Nate Otto: you want to make sure that you have actual interoperability
between the technologies that you're building in those systems. These are
by definition multi-party networks. they've got multiple educational
institutions involved, multiple employers, often governmental agencies. so
these represent a bunch of different buyers of developers of technology.
The question is in this ecosystem is how do you make sure that all of the
technology being purchased across a network of multiple buyers is
compatible with one another. and so that's a question that the coordinators
of a learning mobility collaborative need to be able to answer and it's
also a question that individual software vendors and developers need to be
able to respond to.

Nate Otto: they need to be able to understand what makes their systems
compatible with other systems that might be in use. And so for this problem
for both these user types the ecosystem coordinators and software buyers
and the developers of the software, we have the concept of an inter And
interoperability profiles in general are documents that describe
specifications that may be implemented and then the specific options or
limitations within those specifications that should be applied within a
particular context or community.

Nate Otto: And so the idea here is for the various profiles on this website
is to inform buyers of how to ask vendors for software that will work
together using one of these three approaches to move digital credentials or
it's to inform software developers how to meet the requirements of the
profile and how to be compatible with the other systems that are described
in the profile. So we break this down by describing several different
workflows for credential mobility. One being a interaction between an
issuer system and Another one being that holder wallet system interacting
with a verifier such as an employer. And then some other interactions with
this OB3.0
00:10:00

Nate Otto: direct purple profile describes how you could download a
credential as a static JSON file blob of copy pasteable JSON and move it
around that way without a protocol. So there's not necessarily a holder or
wallet system involved in that one. So we have these workflows and we
describe what are the steps of the workflow in general and then the
specific steps that you need to do for a particular interoperability
profile. So at the top of this interop profile we talk about we mention
what are the requirements specifically for the use of those standards.
sometimes it's just like you must use open badges 3.0

Nate Otto: and be compliant with its schema. Sometimes it is u more
specific about a particular option that should be you must support
credential expiration dates. and then after going through this top section
about the specifications used a little farther down is a section on those
specific workflows. And the idea here for this document is how can we make
this information as digestible as possible so that the developers who are
building from it can follow this in a step manner.

Nate Otto: So if you click the issue to wallet or verify for one of these
procedures at the overall site here we talk about what are the steps of
this process and then within each interoperability profile document we
break down those steps and have different informance statements you must do
this you must do this. So if you could click into the VCOM profile and see
credential issuance workflow right there. Yeah. So here's an example of
that where we say okay the task that you're trying to do is to issue a
credential into a wallet which will use holder binding in the credential
and so you start out by creating an exchange to do this and exposing an
interaction URL to the wallet and then the wallet will fetch that
interaction URL.

Nate Otto: So the step two for the issuer system is to respond to that
fetch. And then the third will be okay, we're going to use the VC API
protocol there. So the next step will be that the wallet will make an empty
post request to the participation endpoint. So you got to respond to that
with a data authentication request and then you'll eventually package up
the presentation with the credential and deliver it to the wallet. Scroll
down just a touch more and you'll see the mirror image of this workflow in
the credential acceptance workflow. This is the same process but from the
reverse role from the perspective of the holder system. So the first step
is to access that interaction that is provided. And so the idea here is to
provide these really targeted checklist so that you're the developer of one
of these systems doing one of these workflows. You can just work down it
top to bottom and implement. so that's the idea.

Nate Otto: would love feedback and open issues in the associated GitHub
etc. And just one more thing to note about this is that a second phase of
this work has been funded and I'm going to work on this leading up to the
badge summit in Boulder, Colorado this summer. on behalf of the US Chamber
of Commerce Foundation, I'm building some interactive developer tools that
help developers work through these checklists and potential future
modifications to the checklists as well. So that if you're building a
holder system, the testing tool will act like an issuer system and you can
actually interact with it.

Nate Otto: it will create the exchange and you can request the interaction
URL and then the participation URL and it will light up those check boxes
as you go and provide contextually appropriate error messaging as well. So
that's the idea and I'm excited to be working on this next step.

Patrick St-Louis: Thank you. That's really great. so I have a bit of a
tangent question. is there currently any system where through the use of
these open badge or CRL a student was able to get a credential and be able
to apply to a school or apply to a job successfully? Is there production
instant of this where that end to end flow has materialized and a realworld
reflection where a student was able to have this wallet get their open
badge apply for a school apply for a job with the credential and…

Patrick St-Louis: resulted in and enrollment. Does that exist currently?

Nate Otto: Yes, there are some ecosystems in…

Nate Otto: which this is occurring, but I do think that there are some
interoperability challenges in those ecosystems. So for example, I
participated in the assessment of several programs who had won grants
through the skills forward project last year. And these were seven
different projects that were responsible for implementing credential
interoperability for employment and skills-based hiring and advancement use
cases. and they largely did do a production roll out of verifiable
credentials specifically all of them chose the open badges schema for that
and there was some amount of applying for jobs and success.
00:15:00

Nate Otto: There are companies that have this system in production and that
includes Smart Resumeé is a place where you can go take your credentials
and have them verified, put on your profile and they have a talent
marketplace where you can connect with employers, but there's definitely
more work that needs to be done so this learning mobility collaborative is
an effort to provide further documentation and support to states and other
collaboratives that want to put these methodologies into practice and there
is forthcoming and ongoing work in statewide in Arizona and work launching
statewide in West Virginia as well that I'm aware of and…

Nate Otto: a good number of other projects that are at some stage of
development.

Patrick St-Louis: Okay, that's interesting. Just quick followup. Is there
any public resource that talks about these implemented system with some
kind of metrics and impact? whether that's a blog post or anything like
that that of. I'm happy to reach out outside of the call too for this.

Patrick St-Louis:

Nate Otto: The one that I am aware of off the top of my head coming from
the skills forward initiative, they've got some blog, there's some case
study resources that are out there that were recently published about some
stuff from their network beyond. And so skillsforward.org is a place to go.
I think they have a specific website that I'm struggling to find at the
moment.

Nate Otto: Which is specifically a showcase of different projects that
we're doing this.

Patrick St-Louis: Okay. …

Patrick St-Louis: thank you very much, Dave.

Dave Longley: Yeah, I just want to say I think this is excellent work, I
really love how this is targeted at developers, how it gives them
straightforward lists of items to go down, requirements and checklist items
for what they need to do for what they need to build to get to
interoperability. this is the kind of document, this is exactly the kind of
simple implementation guide that's often missing as a gap between what a
developer needs and the spec. So this gives them the entry point for all
the things they need to do and then if they have any additional questions
as they go they can dive into specs to get more details out of it or to
expand their support if they want to support more than one profile or some
of the other options in the profiles. So first this is great. I think it's
going to be really helpful to developers as a developer reading this. It
would be helpful to me.

Dave Longley: the other thing I wanted to say was I do want us to be
careful about creating profiles that are only different. I saw there's a
VCOM eddsa profile and there's an oid4 ECDSA profile. And I want us to be
careful that we don't lead developers to think that they have to switch
protocols if they wanted to support both types of cryptography, for
example. So, I don't know if there's a way to say that if two other
profiles should be offered in each one of those protocols, but if you're
having to switch protocols, there might be a lot of burden to take on if
all you needed to do was add support for a different proof type. so, I
wouldn't want developers to get confused about that. And that's really my
only hopefully constructive feedback on

Patrick St-Louis: You want to respond, Nathan?

Nate Otto: Yeah, thanks for taking a look at this Dave and that thank you
for that specific feedback. That is really useful. I'm noodling over it and
trying to figure out what to do with it. I think probably the right thing
to do is just to recognize that a particular data integrity crypto suite,
switching those is not a very high cost lift compared to switching to a
different protocol. And so probably the right response to that will be to
require both ECDSA and EDSA support in maybe all three of these protocols
essentially. as a baseline. A note about sort of why that wasn't present at
first, which is that these particular profiles came out of what was being
implemented in various different communities.
00:20:00

Nate Otto: These are very close to approaches that are being used by
existing vendors in the field. where a particular vendor that was using the
oid protocols happened to choose the ECDSA curve signatures and several
vendors that were using VCOM or a slightly earlier version of VCOM were
gravitating toward the EDSA crypto suite. And so we tried first to sort of
be documentary about what was happening in the field and then we can move
next to being prescriptive about what we think should happen in the field.
I'll note that these aren't perfectly matching to what people have
implemented already.

Nate Otto: For instance, this idea of the interaction which is a newer
concept in VCOM than some of the earlier stuff around exchanges, isn't
actually being used in the wallets and issuer systems where I drew the VCOM
EDSA profile So, there is a little bit here which is a pointer toward, hey,
go finish that last little step and then you'll be u sort of in full
alignment with the profile. But I'll probably see some more
crosspollination here. And also a couple things upcoming. I'll probably add
some more like additive profiles for a couple things and use cases emerging
for that include the inclusion of competency data within open badge
achievements along the lines of credential engines recommendations to use
published competencies. and then I had one more which is slipping my mind
at the moment.

Patrick St-Louis: Yeah, I just wanted to say me personally I do like that
is very specific about what it asks and has people to implement these. I
think this is a good thing for interoperability because the goal of doing
profiles is exactly this to select what is available and make sure that
everyone doesn't need to implement everything. I haven't checked but I know
CDSA sometime comes with selective disclosure support and these types of
algorithm and this can add a layer of requiring both crypto suite on every
profile does significantly add implementtor burden.

Patrick St-Louis: yeah, I do like more especially after our experience with
WebVH, being extremely specific about who implement makes it extremely easy
to implement the specification, We were able to build a significant roster
of implementation fairly quickly. which I don't think would have been
possible if it wasn't as specific into what needs to be done here. Yes,
Dave.

Dave Longley: Yeah, I agree with that philosophy generally, but I think
there are also external pressures or external requirements that might
influence what profile you'd pick. So if you wanted to use hardware
security modules for example, you might struggle to find some that do
EDDDSA, but you might easily find some that do ECDSA and that might push
you in a particular direction unnecessarily. and so it would be good to
acknowledge that there are going to be potentially outside requirements.
And so that might need to be considered in h what selections are made or
how much optionality is added to the profiles.

Patrick St-Louis: Thank you a lot, for this little presentation. It was
great. any other comments for the learning, mobility, collaborative
interoperability profiles? Otherwise, let's move on. maybe that's a nice
segue until this little topic that I thought we could just touch on really
quick.

Patrick St-Louis: So there was a lot of questions asked and kind of
discussion and the standards channel about are VCOM workflow primitives too
complicated to implement and do they what I saw as a conclusion to this
that the question to be asked is do we want to sacrifice some of the ease
and simplicity of doing simple workflows

Patrick St-Louis: in order to support making more complicated workflows.
there was a few people that chimed in that, had a quick look at this and
maybe actually that's why I said it might be a nice segue since this kind
of goes over some of these. from what I heard from what you explained,
Nate, this interpret profile does not get into very advanced workflows. It
wants to keep it as simplive simple workflows with a couple of steps which
are scoped at issuing and presenting. but the VCOM workflows are definitely
taking on this idea that implementers could have very customized
requirements for workflows and tries to support all of these.
00:25:00

Patrick St-Louis: so if anyone wants to share some thought about are we
forcing people to implement something that is too complicated for their
needs only to support a minority that might have more advanced use case.
yes, Dave.

Dave Longley: I think the short are we forcing anyone to implement is
definitely not. the question is will we get independent implementers of the
various features that we offer in the spec and if we have at least two then
that's sufficient. the way I would put this is I think we want to make sure
that our spec allows implementers to pick and choose from the things that
work for them. Let them implement the things that they work that work for
them and let them build the more complex pieces only if they want to. And I
would also say if we don't cover the more complex use cases those are the
things that are harder to prevent vendor lock in for.

Dave Longley: So if that is specified and there are independent
implementers for those things that is more supportive for the use cases
where people get locked into the more complex cases that they have to build
out and it's that much harder for them to switch away if it's not part of
the standard. So we do want to be careful and think about that. but at the
same time we don't want to say you can choose from this spec the pieces
that you want to implement. you don't have to be fully conformant for
everything up and down the whole VCOM spec. You can be a conformant
verifier. You could be a conformant exchange client. You can do interaction
URLs. You can pick and choose from the pieces that you want to work with.
And our test suites should reflect that.

Patrick St-Louis: I think that's interesting and maybe I could extend a
question. do we really want our workflow definition to address this vendor
lock in? I know this was one of the main part of the VCOM and there were
different roles about issuing verifier service and so on and this workflow
now is the sort of wrapper that wraps around all of these interactions. I
am skeptical if that really will prevent vendor lock in. because at the end
of the day when someone implements a platform they will want their platform
to make things work.

Patrick St-Louis: and if the VCOM is too complicated for implementers, this
might be used as this might have a opposite effect, And use as an argument
as to why not to implement VCOM. any Yeah.

Nate Otto: Yeah, I mean I'm also a little bit skeptical about overpromising
that we will be able to prevent vendor lock in because we bother to specify
a bunch of pretty complex generic behavior related specifically to
workflows. where there can be really customized workflows that do lots of
things. I don't have fully formed thoughts here and not even really a
well-formed hypothesis about what might prevent vendor lock in. I do know
that vendor switching costs in this market are very high at this point and
largely that has something to do with the deep integration with the various
different particularities of a certain system and the fact that other
vendors are not directly comparable to it.

Nate Otto: So we may make some good progress toward reducing switching
costs by allowing kind of more standardization space to exist covering some
of these concepts. but I think we'll probably see a lot of implementations
where they have chosen not to implement the full complexity of what we're
offering in terms of different custom comp or multi-step workflows that can
do a lot of
00:30:00

Dave Longley: Yeah, I agree with a lot of that. I think we want to make it
possible for us we want to make it clear that there are some abstraction
lines that we've tried to define some separation of concerns that help
people in these situations be able to avoid vendor lock in more than they
would if we did if we were certainly more than they would if we were
totally silent on all of this. there's lots of vendor lock in the
ecosystem. As Nate said, some of these other protocol approaches are
totally silent on everything around vendor lock in. Meaning that if you're
going to hire a vendor to help you provide the workflows that you want to
provide, they're going to do everything.

Dave Longley: And it's better if we can carve out pieces of that and create
reusable primitives that might help you switch vendors, lower your cost. it
might not make your cost zero. I don't think that's a goal. It's great if
it happens, but the goal is to make it significantly more possible as
opposed to essentially not possible or…

Dave Longley: requiring an entire rewrite.

Patrick St-Louis: Yeah. …

Patrick St-Louis: I'll go ahead and say bringing the cost to zero. I think
that's not true. That's impossible. There will always be costs with
changing vendors. But I like a lot maybe changing the phrasing from
preventing vendor lock in from mitigating or something of the sort. I think
this frame framing is a lot more realistic and to set a baseline of as we
said the term primitive here is good so that because at the end of the day
vendor lock in is a word but also this is where vendors can put their
secret sauce if we want to say it this make their difference and make their
software better than one of the competitors is by adding this little extra
feature that is super useful.

Patrick St-Louis: But I think the spec should aim to have a balance of both
to enable vendors from standing out and offering their special neon cat
fairy dust feature but still have the overall sort of functionality be
covered by the specification right you don't need this vendor lock in to be
right at the beginning of an exchange, but maybe it can be a little
something that happens along the line that provides a lot of value.

Patrick St-Louis: Yeah, leave it at that. Yeah, Joe.

Joe Andrieu: Yeah. I'm not sure…

Joe Andrieu: where the spec is spec text that mentions this vendor lock in,
but I wanted to praise this notion of balance. and then also talk about
what I think is the best way out of vendor lock I've long used the term in
my work I try to find the can't use cases that you really need to support.

Dave Longley: We lost your audio, Joe. It

Joe Andrieu: And in exploring what you might do, it expands the space of
the complexity.

Joe Andrieu: So there's another process of finding now that we understand
the complexity.

Dave Longley: Joe, I don't know if you can hear us, but we lost your audio.

Joe Andrieu: I could not hear you actually.

Dave Longley: Yeah.

Joe Andrieu: Okay.

Dave Longley: And it was right around the time that you were getting to
your punch line, so you might have to repeat all of that. Unfortunately, we
heard at least I wanted to praise the balance and then

Joe Andrieu: There's this tension between simplicity and complexity. I use
this phrase as an anchor, the simplicity on the other side of complexity,
which is to say you have to understand your complexity in order to
understand what you might want to support or not. and then you typically
want to distill that back down to something that's more simple.

Joe Andrieu: and I think we want to encourage that redistillation if there
is complexity get rid of then I want to get rid of that complexity. however
specifically with regard to vendor lockin I think that's best addressed by
adding complexity specifically because what vendors will do understandably
is they will create extensions to meet the use cases that are their special
sauce and that creates the vendor lock in. So if we can foresee hey this
little bit of complexity is something that a lot of vendors might add and
we see a way to standardize it then we can have a way that if you choose a
vendor that did implement it they implemented it hopefully in a way that's
interoperable with some other vendors. so I embrace that complexity as a
goal for getting rid of vendor lock in. even though yes we have this strong
drive we want it to be simple but that's the tension that's inherent
balance here.
00:35:00

Patrick St-Louis: I think it seems like there's a resounding concept of we
all aware that we need to strike a good balance that makes it that when
someone reads the spec and they want to implement it they don't get
discouraged because it wants them to do things that they don't need without
really preventing it at the same time. okay so I'll think about it maybe
open an issue. I'm personally happy with the discussions we've had. I think
there were some interesting topic Does anyone would like to add anything on
this topic? Very good. thanks for the discussion.

Patrick St-Louis: So, let's take some time to go have a look at our PRs. I
saw I think there was one or two opened. and then maybe do a couple of
issues. So, this one I still have not had a chance to let's have a look at
this one, the JSON schema. I know we had discussed some things the last
time about some updates being needed.

Patrick St-Louis: I'm not seeing much updates here and manu is not on the
call. does someone know if there's been work on there?

Dave Longley: I don't think Monu's been able to get to it.

Dave Longley: That's all.

Patrick St-Louis: Yeah, that's totally reasonable. and I'm happy to just
leave this.

Patrick St-Louis: Maybe we can leave a comment discuss and we will review
next meeting as so let's have a look at this. the spear was open by Nate 1
hour ago. so especially for this meeting. do you want to take Nate? Okay.

Nate Otto: Yes, sorry, running back from my kitchen where I was warming up
some lunch. yeah. So I was looking at the specification as I was trying to
do a little bit of work to understand how to describe interaction URLs and
how to make sure I'm implementing them correctly in a product that I'm
working on. And I was unsure whether the interaction part of it when using
the custom scheme was supposed to be URL encoded. Dave let me know that it
was not supposed to be URL encoded, just the plain URL prepended with the
interaction colon prefix. and so I just added an example to the
specification so that this is highly clear.

Patrick St-Louis: This is great because I also was thinking we should have
anam just a very simple example of what it looks like. I'm going to prove
this. I think it's very straightforward and very useful. is there any
comments any objection for us merging this today? Very good. Let's rebase
this and merge. And this should close this issue. Perfect. Nice little
automation. So that's good.

Patrick St-Louis: So these two we'll just leave them as this. let's couple
issues open yesterday. Let me close some of my tabs here and we can just
maybe have a look at these two new issues. One open by Nate and one open by
Dave. would you like to explain this a little bit Nate?

Nate Otto: Yeah. And if you could go over to the VCOM spec itself, I can to
endpoint. I can drop a URL in the chat if you section 3.6.3 create
exchange. So you see in variables here this is essentially describing what
do you do to create a new exchange for the workflow and the display here
doesn't make sense because what you see is post a object that includes
variables those variables should look like this give us the results of the
exchange the exchange doesn't have any results yet in most use cases
because the exchange hasn't been interacted with and dealt with so we
should create a second definition of this object that can be referenced
00:40:00

Nate Otto: here where it's exchange variables for create or something like
that where it describes …

Nate Otto: what can you do with variables here and a common use case but
certainly posting the results is not the common use

Patrick St-Louis: Okay. …

Patrick St-Louis: so yeah, I want to make sure I understand properly. So
you want to remove this and replace it. Yeah.

Nate Otto: Dave, I'll let you take

Dave Longley: So yeah, this stuff is generated from OAS files I believe and
there is probably some OAS file that defines some type for either the whole
create exchange API or for the variables section. And we need to make two
different types I think which is more or less what Nate is saying because
we want to be able to say what do the variables look like perhaps mid
exchange after some of the results have been written to them from various
steps. but that is not what you should be posting to create an exchange in
most use cases as Nate says. So I think we just need an additional OAS file
or type however we're doing that in the OAS stuff.

Dave Longley: to differentiate essentially variables that don't have any
results yet and variables that do. And when you're creating an exchange,
it'll be variables that don't have any results yet that you're going to
send to create your exchange.

Patrick St-Louis: Right. Okay.

Patrick St-Louis: I'm just trying to go up here. I'm a bit slow. I don't
100% understand it but hopefully when a PR is up I'll be able to understand
a bit more what's

Dave Longley: Yeah. Another way to think about it,…

Dave Longley: Patrick, is I imagine when you were scrolling around there,
when you get the state of the exchange, you're going to get back
potentially all of the variables that are in there. And that's where you
would want to see results. when you're getting the state of the exchange as
it is progressing. So we want to have that information there for that step.

Patrick St-Louis: Yeah. All right.

Dave Longley: But when you're creating an exchange, we should reference
some other OAS file that allides omits the results and the variables
because you shouldn't be sending those when you create an exchange.

Patrick St-Louis: Don't you want to set some variables when you create an
exchange?

Dave Longley: Yes, you do, but you probably don't want to set any results
from any steps. I suppose you could, but that's probably pretty unusual.
So, as a Yeah.

Patrick St-Louis: Yeah. Yeah. Correct. Yeah. Yeah.

Dave Longley: Okay. Yes,…

Patrick St-Louis: I would assume that maybe results at first would be empty
or something like that, It could be there…

Dave Longley:

Dave Longley: that's right. Yep.

Patrick St-Louis: but empty. And this is what it would look like. okay.

Patrick St-Louis: I think I understand. Yeah. Yeah. Yeah. I understand. So,
we want this more to be get exchange. I don't know if we get a specific
exchange. This one here. That's the protocols. Are we missing an endpoint?
No. get exchange state.

Dave Longley: That's create exchange.

Nate Otto: just get exchange 366. Six.

Dave Longley: Where is get exchange?

Patrick St-Louis: Yeah. Okay. This is what I was looking at. yes,…

Dave Longley: This is where results make sense.

Patrick St-Louis: it makes sense. at least this is…

Patrick St-Louis: where it makes sense. again, if the exchange just started
and it's still on the first step, I would still expect this to be empty,
okay. Yeah, I think I understand a bit more what is happening here. Yep.
And this is just an object of what result might look like, these are things
that can appear in a result. obviously, if this specific step has nothing
to do with verifiable presentation, I'm not expecting to have a verifiable
presentation in there.

Dave Longley: Yes, that's right.

Patrick St-Louis: probably the same can be said for other things. although
verifiable presentation is the only thing that is here which raises more
question for me…
00:45:00

Patrick St-Louis: but okay it seems to be at a different indentation. no,
it is at that. Okay. Invite request.

Dave Longley: I think there was an open ID section below that as well.

Dave Longley: So there are some other result things that might be based on
the specific protocol that was chosen that get st saved in the results.

Patrick St-Louis: I think this probably talks a little bit about the
complexity here.

Patrick St-Louis: I know for me reading this the variables was something I
was not really understanding mostly the variable in the templating were
some things that were not so clear to me. okay I think that's probably as
far as I'll understand this today. and…

Dave Longley: Nate's had his hand up for a while,…

Patrick St-Louis: probably sorry Nate.

Dave Longley: so he might

Patrick St-Louis: Can you please

Nate Otto: Yeah, problem. I just wanted to mention that this is a discrete
improvement that could be made to the display of these schemas, but it's
certainly not the only one that we could make for clarity in the spec. for
example, in where we were just looking at, it really just isn't necessary
to explode out the idea of what is the verifiable presentation schema
within the context of what is the variable schema. we should definitely
have a different spot to describe what is a variable viable presentation
and what does its schema look like, but maybe an improvement to the resp
package will need to be done to enable us to get the right level of
specificity for each of these displays. Otherwise, we risk just really not
necessarily confusing a developer, but just like you were having trouble
just scrolling up and down the thing and determining what the indentation
levels were already.

Nate Otto: I think we can certainly improve this to provide just as Dave
says an overview of some particular thing rather than the full details in
this

Patrick St-Louis: Yeah. Yeah.

Patrick St-Louis: because it seems like the thing with the workflows for me
is because we want to cover so many use case we're including a lot of bloat
that some people might not care about and if I don't care about open ID I
don't care about it so yeah I think this is a challenge with documentation
because the tool that does this it just reads the OAS file and renders it,
right? It doesn't do anything else than that.

Patrick St-Louis: so maybe I don't have a solution for now, but we
definitely need to think maybe it would need to be like another website
that is like you were mentioning Nate, you're going to be doing some
developer tools and things like that, but maybe we need some other
developer resource for workflows that is a bit more implementation
developer friendly. to explain a bit these things. because this page static
for me this is a bit of a overload of information, Someone who wants to
implement workflows for me this is a lot, right?

Patrick St-Louis: it's a lot to understand and since we're kind of
including some open ID stuff like it these document take into account that
the reader does have previous knowledge and knows some things because the
vCon spec is not going to explain how open ID works right but it's going to
refer things from open ID so this can be a little bit overwhelming I would
say. Yes, Dave.

Dave Longley: Yeah, I agree that additional implementation guides and stuff
can help. as Nate just pointed out with his great work, it is also the case
that have exploding out all the details here makes it look more complicated
than it is. I mean, that thing's just a verifiable presentation. That's
what goes there. And so there might be a way in the OAS files I don't
remember those all specified in YAML maybe they have some metadata flag…

Dave Longley: where you could say in make this a detail or expandable maybe
that's hard to do in the right context but that would be a way to help do
it in the spec to help out a little

Patrick St-Louis: It's clear to me that there's a completely different
what's the term cognitive comp complexity to the workflow section as with
something like issuing like this is very easy,…

Patrick St-Louis: right? It's very light. okay. This one maybe a bit. What
is this? Okay, that's the object there.
00:50:00

Dave Longley: I think some of that is intrinsically true that workflows
have a little bit more complexity than some of those other bits,…

Patrick St-Louis: Okay. Yeah.

Dave Longley: but I think it also appears to have much more complexity than
it actually does because of the presentation style. So we could probably
present this in a much simpler way to totally agree.

Dave Longley:

Patrick St-Louis: If it appears more complex than it is,…

Patrick St-Louis: that's a problem, Because that exactly can be used as a
negative thing like,…

Dave Longley: Totally agree.

Patrick St-Louis: it's looks complicated, I'm not going to bother. and if
it's actually more simpler.

Dave Longley: We should fix it. It is a problem and…

Patrick St-Louis: Yeah I think the main focus should be around creating
simple workflows simple exchange right and…

Dave Longley: we should address

Patrick St-Louis: have a clear way to do this and maybe have a advanced
section somewhere or advanced guide implementers guide but then yeah it's
difficult to define how this will look like in

Patrick St-Louis: a specification. yeah. clear solution here from Yeah,…

Dave Longley: We might even draw from the profiles Nate just made looking
at some of those steps that you do like if you take the perspective of an
Exchange client and what they have to do to step through a workflow you can
make that very simple and what you're returning as the server can look very
simple and then we can have a section that says how do you drive that
behind the scenes that's how you can use templates with variables and so
there are ways we could present this that would be easily digestible

Patrick St-Louis: that's good. But also that's another comment. I mean so
I'm looking at the didcom workflows and this is just as complicated, I
think it's just at the end of the day when you want to support these work
use case specific workflows like it is just not a simple thing, right?

Patrick St-Louis: just like issuing a credential signing it fine at this
point I would dare to say it's trivial right just applying a signature
there's all these crypto suite algorithms proof but this workflow here
needs to take into account all the different parties and make sure they can
progress at the same time and be configuration driven support all these
different exchange protocol like this is a whole other layer of complexity
that is difficult hold to address in a specification. and we don't want to
spend a lot of time defining this at the end of the day have something
that's not usable, not user friendly. but yeah, I think it sounds like
we're all on the same page for this. it's a challenge definitely. Demetri,
I thought you raised your hand for a little bit. did you want to

Dmitri Zagidulin: No, I changed my mind. one of the things that I've been
sort of wrestling with regards to this spec is I don't know if the
complexity is worth the benefit. there's only a couple things that people
are going to typically use these exchanges for. One's to issue credentials.
the other ones to request them in issuing case the issuance workflow is
going to be hardcoded I don't think creating a language for it via the
steps is that useful and then separately for requesting stuff it's missing
a couple of fields that might be useful because it's focused just on
credential variables

Dmitri Zagidulin: but I don't have a strong dog in the fight just sharing
opinion.

Patrick St-Louis: Yes, Dave.

Dave Longley: I think you might be describing some cases that are very
simple for the simple case where issuance is just you pick up a credential
and you're done. that might be quite common. It's true. but there are other
cases where you need to do more than that. And for all the cases that are
really easy for people to implement or throw together really quickly,
that's not a vendor lockin problem. That's not where you hit those sorts of
issues. If everything is really easy for you to automatically regenerate
and recreate really quickly, I would agree. and you're not talking about at
that layer the need to interoperate with another party because you're just
effectively interoperating with a service provider or doing it yourself.

Dave Longley: I would agree that that's not where you need help and that's
not necessarily where you even need to standardize anything, but where you
do need to standardize things are the ability to make these more complex
and interesting workflows. that's where if we have that in our spec, that's
where more of the value comes in. That's where if you select a service
provider that conforms to these standards that does this sort of thing,
that you can switch to another one with a lower overhead of switching costs.
00:55:00

Dave Longley: And that is the exact place where vendors dig in and take
advantage of the vendor lock

Patrick St-Louis: interesting. Okay.

Patrick St-Louis: So, definitely there's a lot of discussion about
workflow. This seems to be where we are putting a lot of our efforts in and
is probably currently the unknown in the specification right because it may
be difficult to test depending on the direction here I'd like to go over
this however I'm seeing the time it's four minutes left before the end of
the hour before usually we try to finish five minutes in advance so I think
we'll

Patrick St-Louis: We'll leave this for the next time. I don't think there's
much value in just going over this in one minute. I think we'll probably
want to discuss a little bit more. Is that okay, Dave? Okay.

Dave Longley: Yeah, totally fine with

Patrick St-Louis: So, we can put pin this for next week to make sure we go
at this issue. yeah, great discussion about workflows today. closed one
small PR. we didn't have any outage this weekend so that's good. that being
said I think I'm ready to end the call today. is there anyone else has a
final comment they would like to Very good. in that case thank you all for
attending and thank you Nate for the presentation again and we will see
each other next week.

Patrick St-Louis: A very great end of your week everyone.
Meeting ended after 01:09:32 👋

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