[MINUTES] CCG VCALM 2025-11-18

Meeting Summary: CCG VCALM - 2025/11/18 Topics Covered:

   - *Community Updates:* Discussion of the TAC event and potential
   community updates.
   - *PR Reviews:*
      - PR 564: Add optional exchange (addressed linting issues, discussed
      schema patterns, and made decisions regarding object removal).
      - PR 79: Updated get exchange response object (discussed empty object
      representation and spec text updates).
   - *Issue Review:* Reviewed and closed issues 513 and 522.
   - *Issue Discussion:*
      - Issue 508: Discussion on adding an optional "client profile"
      property for supporting multiple OpenID profiles, including
client ID key,
      and how it relates to multiplexing and supporting different protocols
      within the same exchange.
      - Issue 536: Discussion of adding a VC request example, focusing on
      the implications of user-initiated signing, architectural considerations,
      and potential market impacts.

Key Points:

   - *PR 564:* Resolved linting issues and decided to remove unused objects
   (verifiable presentation request and verifiable presentation body object),
   with the possibility of re-adding them later if needed.
   - *PR 79:* Discussed the possibility of the exchange response being an
   empty object and decided to address the need with a new PR with spec text.
   - *Issue 508:* The meeting participants discussed the value of having a
   "client profile" property to allow for multiplexing and supporting multiple
   OpenID profiles within a single exchange, particularly for transitions and
   supporting different protocols.
   - *Issue 536:* The meeting participants discussed implementing a signing
   request feature where an application requests the user's wallet to sign
   things for it and the potential market implications of this feature.
      - Dave Longley raised concerns about the architecture's impact on
      digital wallets, the potential for users being tricked into
signing things
      they shouldn't, and the challenges of interoperability.
      - Dmitri Zagidulin emphasized the feature's fundamental nature for
      wallets.
      - The meeting participants agreed to prioritize discussion of the
      issue at the next meeting.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-11-18.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-11-18.mp4
*CCG VCALM - 2025/11/18 14:55 EST - Transcript* *Attendees*

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

Patrick St-Louis: Hey, good afternoon or morning or whatever time of the
day it is.

Patrick St-Louis: We'll wait a few minutes for people to come in and get
started in around two minutes.

Patrick St-Louis: Welcome Dave.

Dave Longley: Everybody.

Patrick St-Louis: Let's get started. If other people join, we can get them
up to speed. Give me one second. I will share my screen.

Patrick St-Louis: So welcome to the VCOM specification weekly meeting for
this week. today is the 18th November 2025. there was no meeting last week.
The meeting was cancelled due to community event. We are also expected to
have a lower participation today.

Patrick St-Louis: There was also ongoing event this week and then next week
meeting should be cancelled again and then we should be starting to get our
usual amount of attendees the week after so on the agenda today very
similar to the past few meetings we're going to go through community
updates and new agenda update suggestions. We're going to go over the
current PR. I believe there's two PR that are open. We should hopefully be
able to close them both and then go through their current issue. Try to
review them and assigning some that are missing and prioritized. before we
get started, is there any relevant community updates individual might want
to share? I know there was a TAC event last week.
00:05:00

Patrick St-Louis: so if anyone has attended or has some related updates to
share, now's the time. So we'll leave a couple minutes for anyone to raise
their hand and share their updates. Very good. As for the agenda, does
anyone have suggestion or items they want to bring up into this meeting?
Things they want to discuss, concerns, please let us know.

Patrick St-Louis: Okay, let's get started with R reviews. I would like to
start with 564 if there's no objection. we had started to review this last
time. there was an issue when rebasing and…

Patrick St-Louis: I've tried to address this issue. However, I'm not sure
if it's what we want. I can go over what I mean in a second. Dave.

Dave Longley: I just wanted to point out I think…

Dave Longley: what you're current at least for me what you're currently
presenting is still the agenda not the PR

Patrick St-Louis: Okay, hold on.

Patrick St-Louis: It's probably just stuck in the other tab. Let me make
sure to change tabs. Is this better?

Dave Longley: Yep.

Patrick St-Louis: So this was add optional exchange the original PR. So
they added a call back endpoint with some documentation.

Patrick St-Louis: We went through a few rounds of comments, addressed them,
and then when we merge the main into the branch, there were some issues
that started to happen. I think there was a mistake in the way it was
merged. We readded some section that we wanted to remove and when removing
these section there was some linting issues mostly related to unused
objects. However, these unused objects as we can see here.

Patrick St-Louis: So we have the notify presentation available request, the
verifiable presentation request body, and the verifiable presentation body.
It seems to me like these should be used somewhere else. however, I'm not
too sure why they're not. Dave. Yes. Okay.

Dave Longley: Couple of comments. first one is I don't know what the notify
presentation available request is. So that might not be used anywhere. it
does say it's from the VP request spec. but it's also got request query by
frame and it looks very old. I don't think that's a format anyone has ever
used. So that one's probably fine. I guess someone else would have to do a
search on those other ones. They sound like they could be actually used. so
I don't know the answer to the other two. And then finally, I left a
comment I think up at the top, it's a little bit too prescriptive. there's
a schema that forces a pattern for people to use specifically a UYU ID all
the way up the very top of the PR.

Dave Longley: I guess you have to refresh to see my comment. or I failed to
hit the there it is. I don't think we need to force it to be a UYU ID.

Patrick St-Louis: Yeah, that is okay with me.

Dave Longley: So I just suggested we remove that part of the schema.

Patrick St-Louis: probably would be good to have a pattern. We definitely
don't want spaces or anything like this. but I'm assume probably this can
be reviewed at a later stage. As long as it is a URL encoded string, I
think it's fine. yeah. Okay.
00:10:00

Patrick St-Louis: any objection to removing this pattern here? Let's commit
this. as for these two objects, as far as I know, the schemas are still
going to be there. we're just removing these objects. Are we okay with
removing these now and…

Patrick St-Louis: adding them back at a later stage if we see they are
missing or do we want to investigate a little bit more?

Dave Longley: Does the preview tell us at all…

Dave Longley: if anything broke? I feel like wasn't it last time that we
determined that something strange was going on based on the preview. And if
not, I think we could add it back in if we see that there's a problem.

Patrick St-Louis: All right, hold on. Let me share the preview page. Vcom.
It does.

Dave Longley: I suppose the other option is to just leave it in there. Does
it generate like a linting error and say it's not used?

Patrick St-Louis: It does fail one of the R tests. We could decide to
ignore that test. yeah,…

Dave Longley: That looks like maybe there's a bug in the preview.

Patrick St-Louis: I think this section needs to have some more stuff in it.

Dave Longley: I imagine that that's actually populated if we look at the
live spec. So maybe since it's generating an error, let's just submit it
and then if it needs to be added back in, I think that could probably be
done very quickly as an editorial fix. Yeah, the preview doesn't seem to be
generating the right thing.

Patrick St-Louis: There's definitely content missing like here.

Patrick St-Louis: Let me quickly look at the preview for the other PR if I
can.

Patrick St-Louis: Seems like this other PR I cannot generate a preview. So,
we want to wait a little bit and investigate a little bit more.

Dave Longley: That is a possibility.

Patrick St-Louis: Or are you saying it's just the preview feature itself
that doesn't render these? But they should be rendered in the spec.

Dave Longley: That would be my first guess.

Patrick St-Louis: Okay. Yeah.

Dave Longley: Either that or every single one of those fields is broken by
this one change, but that seems unlikely unless it's like a syntax thing
that stops it from processing.

Patrick St-Louis: It could be an indentation error.

Patrick St-Louis: I'm not too sure what's going on here.

Dave Longley: So, I guess we can't view any of the previous PR.

Dave Longley: Yeah, E Eric has a PR in that does not have a preview on
there. So, we can't use that one. I'm going to see if there's a closed PR
that still has a preview link. That's recent.

Patrick St-Louis: Okay, let me have a quick Okay. So,…

Dave Longley: Yeah, there's another one that number 565 the preview does
not have a bunch of tables in it.

Patrick St-Louis: it seems like some content is not preview friendly but is
actually rendered in this spec. Okay.

Dave Longley: That's my guess because if we go look at the spec now, that
PR565 has been merged and the content is in the spec. So, it seems like a
preview problem.

Dave Longley:

Patrick St-Louis: So in this case would we be comfortable with merging this
and…

Dave Longley: Yeah, let's do it and…

Patrick St-Louis: look at okay we can always revert.

Dave Longley: see what breaks and then it can just be an editorial fix to
adjust

Patrick St-Louis: Any objection to merging 56 564 knowing that we are
removing the verifiable presentation request and verifiable presentation
body object. We'll go ahead
00:15:00

Patrick St-Louis: So, we maintain the list of edits. That looks good. Let's
go ahead. While this goes, we can just read the other PR and when the
GitHub action is finished, we'll probably just need to rebase so this is a
PR open by Eric to attempt to handle another issue. Updated get exchange
response object.

Patrick St-Louis: secondary option to get exchange response object can be.

Patrick St-Louis: So this was open two hours ago at 79. fairly small PR.
yes, Erica, go ahead.

Eric Schuh: Yeah, if you sorry.

Eric Schuh: So, I think this is pretty straightforward. Hopefully I got the
YAL still getting used to the syntax, but effectively I added one of here
instead of just the exchange response so that the response to this get
exchange response can either be the exchange response object as newly
defined or…

Patrick St-Louis: Okay. Yeah.

Eric Schuh: this empty object which would terminate so the exchange
response you can see right below that it's the last green line. because the
preview everything else was what already was…

Eric Schuh: what was originally contained in the git exchange response. So
everything else there is below that exchange response is exactly as it was
before. but it just cuts off fairly I believe so.

Patrick St-Louis: And this needs to be an empty object,…

Patrick St-Louis: currently it could be just an object. does it absolutely
need to be empty?

Eric Schuh: Yeah. So that probably needs a Yeah,…

Patrick St-Louis: if we want. yes, Dave, go ahead. Yes.

Dave Longley: I was going to say this JSON schema makes it look like
there's an object with the property empty exchange response, not just that
it's an empty object. And in fact, the exchange response below it, I don't
think it has any required properties. If it doesn't have any required
properties, then technically it would pass the JSON schema…

Dave Longley: if it were an empty object.

Patrick St-Louis: So should this be more addressed by the spec text saying
that the exchange response can be an empty object and…

Patrick St-Louis: if it's an empty object it means okay what do you think
Eric so we'll leave revert back the one of

Dave Longley: Yeah, I think so.

Eric Schuh: I'm fine with that. yeah,…

Patrick St-Louis: Yeah.

Eric Schuh: it would probably be simpler, I would expect, just to reject
this PR and then I can submit a new one with updated spec text in its place.

Patrick St-Louis: And you can update maybe this description to say it can
also be an empty object to signal blah blah blah and some text in the spec
itself.

Patrick St-Louis: Are you sure you want me to close this and you don't want
to just keep working on this one? It's up to you. …

Eric Schuh: Either way,…

Eric Schuh: honestly, as far as I'm concerned, I just thought it might be a
little cleaner to just close this one. since I imagine most of the changes
will take place in the spec text, other than as you mentioned, maybe small
descriptive update.

Patrick St-Louis: what about this? I'll add a comment to this PR with our
change,…

Patrick St-Louis: and you can decide, if you want to close it, open a new
one, or work on this one. That work. Okay.

Eric Schuh: Sounds good. Yep.

Patrick St-Louis: This group decided that instead of changing schema and
include one of the what was called I think that's good.

Dave Longley: I also left a comment on there.
00:20:00

Patrick St-Louis: I was just going to say this. Let's just slightly off
because that's cute name. So it can be an empty object. Yeah. we happy with
this.

Patrick St-Louis: Think so. And leave it up to you, Eric, if you want to
close this or just update it at another commit. At least we have this
history here. Very good. Okay, let's go see. So, the GitHub action
completed, which is good. I'm going to open the rendered spec. We'll update
the screen I'm sharing so we can look

Dave Longley: I also did a search in the GitHub repository for those two
things that got removed from the schema and they only appeared where we
removed them. So they weren't referenced I don't think anywhere.

Patrick St-Louis: And it looks like it rendered properly. and like I
mentioned the schemas for these object is still in there. there's no
reference to them to use them to render them somewhere. So if we feel that
we need to render the presentation somewhere the schema is still there. So
I don't think it would be a big issue. So we have a presentation here.

Dave Longley: Yeah, and I was going to say I found other instances of the
schemas for verifiable presentation in the spec already. So, there might be
some duplicate schemas or something.

Patrick St-Louis: So maybe there's a bit of a schema object cleanup.

Patrick St-Louis: lying somewhere in here to avoid duplication of code. But
as far as the spec, everything looks good. And then where is this call back
exchange? I think this is what we added. Does this look correct? I think
so. There's an exchange ID property in the data. this is great. I'm just
going to go and see if this was closing another feature.

Patrick St-Louis: So this was addressing 247 which we can quickly review
here at callback URL to exchange. This is closing that one is Closed 295 a
bunch of times it's closed. this is not what we just merged. This is a very
old issue. Yeah. So, this is what was been raised. Okay. I think I'm happy
with closing this issue.

Patrick St-Louis: I don't think there's any outstanding items to do. So if
there's any objection close this issue perfect so 25 issues left not much
credential query should be an object not an array. So I haven't had time to
look at it. …

Patrick St-Louis: But I believe we discussed it last time and I'm happy to
try to have a look this week. yes, Eric. Yeah,…

Eric Schuh: Yeah,…

Eric Schuh: I did just want to mention that I think we have a couple of
issues that were left open after a couple PRs got closed. so I don't know
if we want to handle them or just go down the list and we'll get to them
eventually, but …

Patrick St-Louis: Do you have a specific issue, a specific number in mind?

Patrick St-Louis: there 522.

Eric Schuh: yeah, issue 513 and issue 522, 513 and 522, I believe, can both
be closed.
00:25:00

Patrick St-Louis: We'll just review very quick. so this one sorry I need to
change every time I want to go to a new tab. Okay so ensure colors of
endpoint portly reference workflow instance instead of issuer coordinators.
This is a recent issue. Believe we can close this issue.

Patrick St-Louis: the API component table. This was an issue that was
assigned to you and you took on I think so. Yeah. hold on. Just want to
make sure I reading the correct thing. Yeah, I think I'm happy to close
this issue.

Eric Schuh: And the other one was 522.

Patrick St-Louis: Any objection. Go ahead. 522.

Patrick St-Louis: Let's have a look. So this was expected callers and API
component overview and also a recent issue PR. So this one we closed it. We
didn't merge it. but you did open another PR afterwards update and it looks
like it addressed any objection to closing this issue as well? There we go.
So, now we're down to 23 issues. We're good. Maybe we'll be done by
Christmas.

Patrick St-Louis: okay let's see twin lane diagram I think we discussed
this the last time so let's skip this one so this is your at length so all
the ones that are already assigned I think we can skip for today since we
did have some PR at least to that were coming in. Okay, so this is some
open ID related stuff.

Patrick St-Louis: so it seems like this is just about adding an optional
property of profile. so I guess my question would be do we want to list
every optional property that exists for other specification? If what is
special about this one that we would want to add in there?

Patrick St-Louis: Because obviously I'm feeling if we want to get down into
listing every optional properties it could be a big list. However, if we
decide that for specific specification that have a significant amount of
traction we want to include them that is fine. So I'm just curious Dave if
you could mention this do we feel like this is required for this spec?

Patrick St-Louis: widest one in particular. Yeah. Sorry.

Dave Longley: Can you This one isn't being shared again.

Dave Longley: That's Yeah.

Patrick St-Louis: Sorry. Every time I keep thinking it's going to show…

Dave Longley: All right.

Patrick St-Louis: because I'm using the same browser, just different tabs.

Dave Longley: Yeah, you might be able to make a new window that just has
the taps that you want to share. yeah.
00:30:00

Patrick St-Louis: You can see it now.

Dave Longley: What's that?

Patrick St-Louis: You can see it now. That's

Dave Longley: Yeah, I can see it now. So, it's not so much about listing an
option property if anyone wants to do interrop on this, we should put it in
the spec. So, optional properties, as you were alluding could be more or
less anything. But if there's any property that at least two implementers
are interested in getting interop on then we should put it in the spec. And
I would expect implementers to want to do this in particular because of the
way I mean maybe the landscape will change.

Dave Longley: this has to do with oid for BP ISO8013-7 which is for MDO.
and the fact that the ISO 18013-7 NXB requires different parameters and a
different sort of protocol interface than does these other upcoming annexs.
So there are several different ways to use oid forVP and several different
ways to present MDOC and they're not all compatible and if you create a
single exchange that supports multiple profiles then a wallet that
understands an interaction URL can pick the one it wants to work with.

Dave Longley: So, a wallet that receives an interaction URL could read, for
example, an MDOC URL from the protocols list or an oid forvp 1.0 URL from
the protocols list and then make a decision and the same exchange can
provide both of those URLs so that for the coordinator side all of the
state and everything is managed cleanly with one thing. but the interface
to the wallet has to be different because that's what the ISO spec and the
OID forVP specs call for. They have a difference. And so this feature
enables someone to implement an exchange that would expose effectively both
of these endpoints for use with the same exchange.

Dave Longley: There is an open question around whether or not ISO 18013-7
NXB is going to continue to be used in the ecosystem. Some of the larger
big tech companies don't look like they're going to be using it. and maybe
people will just stop using it or…

Dave Longley: maybe there will be subsets of people that do use it. And so
it seems prudent that we say if you want to support both of these at once,
here's how you do it. and that's what this issue documents.

Patrick St-Louis: So I think I misunderstood initially.

Patrick St-Louis: Client profile is not a specific property to anything.
It's something we want to define to list which I want to say it's some kind
of versioning which version of the spec you want to support…

Patrick St-Louis: which yeah

Dave Longley: sort of…

Dave Longley: because it's about multipplexing. You're supporting two
things at once. So there is a property that you can speak the oid forvp
protocol in multiple different ways and if you express at least two…

Dave Longley: if we have a concept of client profiles where client refers
to an oid for vp client and…

Patrick St-Louis: Yeah. What's this?

Dave Longley: in that terminology that's actually the verifier side. So if
you want to ex express two different verifiers in the same exchange then
this is how you would do it and then the wallet then as a coordinator you
don't have to care what protocol the the wallet can either pick the ISO
1803-7 NXB approach or it can pick some other approach if based on whatever
client profiles you have available.

Patrick St-Louis: my gut reaction is that this is a good thing to have
because I think one of the reason why people would look at the VCOM is to
be agile in what

Patrick St-Louis: they support and down the line implement new protocols
without having to change their whole system. So having a built-in mechanism
that this is a bit the same way for the coordinator to advertise which
client profiles they support so that the wallet can pick. is that a correct
this way to define this?
00:35:00

Dave Longley: Yeah, one of the big strengths,…

Patrick St-Louis: Okay. Yeah.

Dave Longley: yeah, one of the big strengths of the VCOM spec is you can
create a single exchange that can support many different protocols for the
wallet to interact with and then the coordinator doesn't have to care. the
wallet you'll be able to support more wallets in more ecosystems without
having to think about it.

Patrick St-Louis: this and…

Dave Longley: If you implement

Patrick St-Louis: it's very useful because a big thing I'm looking at right
now is the step of transitioning. So if you have an issuance flow an
ecosystem based on something and you want to transition towards something
else obviously you don't want this transition to you want to make it as
seamless as possible for people that will manage issuing software and
wallets.

Patrick St-Louis: So any feature of this nature can really help for this.
So I think I understand more.

Patrick St-Louis: Sorry, I totally misunderstood the issue at first.

Dave Longley: Yeah, if you look at the second code block,…

Dave Longley: it's a little more there's yeah,…

Patrick St-Louis: Yeah, this one here.

Dave Longley: there's currently an o open ID section in the workflow schema
that we have and today all it does is take the top block as a single client
profile. So that top lock represents a single expression of an oid forvp
client. And what the change would be in to the spec which would be
backwards compatible would be you can either provide just one profile at
the top level like we do today or you can pro provide the client profiles
property and then nest those profiles.

Dave Longley: So you can have multiple that and…

Patrick St-Louis: Okay. I

Dave Longley: that way multiple choices can be made and you expose those
through different endpoints on the same exchange and…

Dave Longley: they all use the same ex backing exchange state. Yeah. And I
think it's defined as a map…

Patrick St-Louis: And this is the profile.

Patrick St-Louis: Okay, the profiles would be a list of these objects
basically, right? But this is an array or…

Dave Longley: where the keys refer to the client ID.

Patrick St-Louis: a map.

Dave Longley: Yeah it's just probably not clear. yeah,…

Patrick St-Louis: So, probably this is something that would need to be

Dave Longley: the suggest above that text probably needs to be adjusted.
technically in this issue, nothing says what oid for BB client profiles is.
I should have been more clear with that.

Dave Longley: But the text does describe above this block. Wait, if you
keep scrolling up, it says the suggestion here is to add an optional client
profiles object to the open ID object in a step. And so that's the
paragraph right above the code block.

Patrick St-Louis: And so we do want this to be an object,…

Patrick St-Louis: not an array.

Dave Longley: Yeah, I believe we want that to be an object…

Patrick St-Louis: And the object would be a key with this profile as a
property. Okay.

Dave Longley: because it makes it much easier for implementations to
reference specific names for those clients. And so and so each key would be
defined based on if you're creating a workflow, you would set some number
of keys for each profile you want to support. And then each value for the
key would be the profile options for that key. And then you can do things
like expose two different URL and many different URLs that reference the
different clients and then the wallet can make a choice.

Dave Longley: So for the MDOC versus oid forvp example, you would expose a
URL that says that has a scheme of MDOC colon slash and then for open ID
for VP it's like oid for VP or open ID I don't remember the exact scheme
name from the spec and then colon slash and…

Dave Longley: the rest of that URL the suffix for that would reference the
correct client ID.

Patrick St-Louis: Can we go over…

Patrick St-Louis: what the key is quickly? just and…

Dave Longley: The key It's a semantic name that you choose to identify your
client profile. It's whatever you want that to be.

Patrick St-Louis: when you say you choose who's this in our creator.

Dave Longley: The workflow creator chooses the name Yeah.

Patrick St-Louis: So the key is a semantic name chosen by the workflow
created creator. and then that's it.
00:40:00

Dave Longley: And the value is the o OID for VP client profile as defined
above with whatever properties you want.

Patrick St-Louis: So an example would be you have an example of…

Patrick St-Louis: what the key be like as a workflow creator.

Dave Longley: I don't know that you'd want to name them directly after a
scheme.

Patrick St-Louis: I think you just gave one, but okay.

Dave Longley: You could call it M do but that's probably not a good idea
because you can also pass an MDOC through oid for BP.

Patrick St-Louis: Just Okay,…

Dave Longley: It doesn't matter really what those names are.

Patrick St-Louis: so they're just a name.

Patrick St-Louis: Can they have spaces? Does it need to be like a okay that
is name

Dave Longley: It's going to be something that's going to appear in a URL.

Dave Longley: So it's a name that'll appear in a URL. So it's a slug value.

Patrick St-Louis: What the hell?

Dave Longley: And I mean as a workflow creator, you're probably going to
want to give it a name that seems to resonate with what the client profile
parameters actually are. So anyone editing or looking at the workflow would
have some recognition.

Patrick St-Louis: Focus open ID profile it refers to. Okay. does this make
sense to everyone to hear what I added here?

Patrick St-Louis: I do not believe this was covered in the issue and I
think it clarifies a little bit what this means. so the PR should add this
property that's optional.

Dave Longley: It's just called the client profiles in the suggested schema
above,…

Dave Longley: not oid for VP client profiles.

Patrick St-Louis: But does it need to be a open ID for client profiles or…

Dave Longley: Yeah. …

Patrick St-Louis: we can foresee other profiles on the line?

Dave Longley: it's already nested under open ID,…

Patrick St-Louis: Yes. Okay.

Dave Longley: so it probably doesn't need the additional

Patrick St-Louis: along with text explaining how to map these any
objections to so yeah I'll just put this here if someone wants to clarify
this please just add another comment anyone wants to take this or we can
come and discuss it again in a further meeting.

Patrick St-Louis: How would you put this in a priority or a important
feature?

Dave Longley: That's hard to do in the absence of thinking about all the
other priorities but the protocol space is rapidly evolving.

Patrick St-Louis: Yeah. Yeah.

Dave Longley: So it's and important today. It might become less important
over time or…

Dave Longley: more important. it's hard to say …

Patrick St-Louis: Okay.

Patrick St-Louis: But there's no current pressing needs to implement this.

Patrick St-Louis: Is this something that's out in software today or plans
to be out or it's really more at the idea phase now or nice to have with
this client profiles array.

Dave Longley: there are implementations that already have this feature.
there might be two implementations that have this feature. There's at least
one. Yes. Yep.

Patrick St-Louis: To note that are currently deployed. Let's use this
feature. Just adding this so we know that if we want to change the behavior
when the PR comes in, we'll need to make sure to take into consideration
existing deployments. Okay.
00:45:00

Patrick St-Louis: We'll look at maybe one or two more and then maybe we can
cut the meeting short after this. Add a issue VC request example. I'm
curious to see what this is is Dimmitri. I think I saw you join the call
Dimmitri.

Dmitri Zagidulin: Yes. Yeah. this

Patrick St-Louis: So we had discussed this. This is also fairly recent. let
me just get up to speed. So creating web apps that auto compos credential
and VPR spec. Okay. So this is a VPR related question or feature.

Dmitri Zagidulin: This is adding a new feature to the VPR spec that allows
applications to ask the wallet to sign things for it.

Patrick St-Louis: Yeah. Yeah. Yeah.

Dmitri Zagidulin: So in this particular case the application is a resume
creator for example and after it creates the resume it needs to sign it
right the resume is in a verifiable credential format needs to sign it.
it's not managing for the user. The wallet is managing keys for the user.
So this is a signing request very similar to incidentally how MetaMask does
it or rather the feature is similar.

Dmitri Zagidulin: Obviously MetaMask does not use Yes.

Patrick St-Louis: So would it be fair to say that in this case the rumé
creator is the holder and…

Patrick St-Louis: they're asking the wallet of the user to issue a
credential.

Dmitri Zagidulin: which underlines the fact that Holder is a terrible name.
But yes.

Patrick St-Louis: So when I think about I'm just going to make a parallel
for the unknown issue credential model. the sort of issuance dance if I can
call it this can start with what's called a proposal.

Dmitri Zagidulin: Mhm. Yeah.

Patrick St-Louis: And the proposal is when a holder propose a credential to
be issued to them.

Patrick St-Louis: So there and it's an optional step. so it goes proposal
offer request then storing. So the okay and…

Dmitri Zagidulin: So this is similar but not quite but this is similar.

Patrick St-Louis: how is it different leaving the semantic of issuer holder
verifier on the side just from a point of

Dmitri Zagidulin: For one,…

Patrick St-Louis: You that's…

Dmitri Zagidulin: it's not the end result of this request is the wallet
handing an issue assigned credential, right? So instead of wallet receiving
a credential from the issuance process, it's handing it over to the app.

Patrick St-Louis: why I meant in this specific transaction the app would be
the holder cuz they're the ones that's going to hold that.

Dmitri Zagidulin: So it's conceptually similar to the anon stance. Yes.

Patrick St-Louis: So with that being said, I think this would make a lot of
sense and I just want to make sure the words so issue request.

Patrick St-Louis: Could we adopt the term a issue proposal or…

Patrick St-Louis: would issue requests be required here?

Dmitri Zagidulin: It's not required.

Dmitri Zagidulin: If there's consensus proposals,…

Patrick St-Louis: I mean I'm just trying to align things.

Dmitri Zagidulin: fine, right?

Patrick St-Louis: Because in the other lingual the requesting a credential
is when the holder asks for the credential from the issuer.

Dmitri Zagidulin: So I'm a huge fan of aligning terminology,…

Patrick St-Louis: Yes.

Dmitri Zagidulin: but it is a different use case and a different workflow.
structurally, it's very similar. but it does need its own name.

Patrick St-Louis: And wouldn't it be more like an issuance request or…

Dmitri Zagidulin: Yes. Yes.

Patrick St-Louis: again a bit of a semantic here?

Dmitri Zagidulin: Issuance request would also be a valid name for it.
00:50:00

Patrick St-Louis: Okay. Kyod

Kayode Ezike: Hey, yeah, I was also going to make a comment on the first of
all, I love the use case. So, thank you, Demetri. I was just going to say
as well about the naming that we actually have a field named that in the
workflows and obviously it's a different part of the spec, but I guess
having two different use cases use the same field is something to be aware
of.

Kayode Ezike: So, that's all I was going to say.

Dmitri Zagidulin: …

Dmitri Zagidulin: the initially I was proposing this to be a sign request,
right? Because that's all it is.

Patrick St-Louis: Mhm. Question.

Dmitri Zagidulin: But yeah. Yeah. Not necessarily.

Patrick St-Louis: So you have a credential subject ID here. In this
example, would this be the ID that also issues this credential?

Dmitri Zagidulin: This is just an example.

Patrick St-Louis: Okay.

Dmitri Zagidulin: Yeah. Exactly.

Patrick St-Louis: It depends. It doesn't matter. Okay.

Dmitri Zagidulin: And in fact one of the use cases for this is for
recommendations. So I'm a colleague writing a recommendation credential
about somebody else's credential. So the ID would be different.

Dmitri Zagidulin: Basically the credential subject ID is different.

Patrick St-Louis: Okay. Okay.

Patrick St-Louis: So definitely change for issuance then it could be maybe
posal probably request makes sense. I think I would make a argument for
proposal that in this scenario the réumé builder tells the user here's…

Dmitri Zagidulin: I'm not attached to issue proposals. Fine.

Patrick St-Louis: what I proposed to you as a resume that I've built. Do
you want to issue this? and then the user accept or okay.

Patrick St-Louis: Dave just might put a comment.

Dave Longley: Yeah, I'm on the queue. I can speak to some of that.

Patrick St-Louis: So sorry. Yes, Dave,…

Dave Longley: That's right.

Patrick St-Louis: please go ahead. I did see your hand earlier.

Dave Longley: Yeah, it's hard to do while presenting.

Patrick St-Louis: I got distracted. Yeah, go ahead.

Dave Longley: So this is definitely a useful feature. I put some concerns
down here into the issue. in order, the first one is the more complex that
we make digital wallets, the fewer of them there will be a harder time
having competition because it's harder for people to build those and that
can be a significant drain on user freedom and liberty and
decentralization. So, we do need to be careful with that. and I highlight
that in particular because it seems like there's some measure of conflating
user holder and issuer roles in this particular space. the digital wallet
is becoming an issuing application.

Dave Longley: Nothing says you can't have that be the case.

Patrick St-Louis: Is that

Dmitri Zagidulin: correct which…

Dmitri Zagidulin: which many of the wallets do do that. Many of the wallets
have for example a selfissued feature. Yes.

Dave Longley: Just without thinking about the problem and the complexity
and so on. if our architecture made it such that we could put all these
pieces together and you used for example websites to do the issuing and
some simple API in the wallet to put your signature on the end of it.
ignoring all other problems with what I just said. that I think that would
be better architectural design because it wouldn't require digital wallet
providers to really do anything and the issuing websites are going to know
the details around the data models and all the other things that they're
building and so they can build richer better interfaces for that sort of
thing.

Dave Longley: the second thing which kind concern I had which is kind of
related to what I just said is that there are dangers here in tricking
users into signing things signing assertions in particular that they
shouldn't. this is notably different from signing presentations of other
assertions you have. If you sign an assertion and put that out into the
world that's some claim that can travel and go anywhere and your stamp of
approval is on it. and if you don't fully understand what that is, that can
be a problem. And number three, getting interrupt with wallets that can
help users actually understand what they're signing might be really hard to
do. and so you might end up having wallets that have lots of these really
powerful, cool features that work with these 10 sites, and no other wallets
can do it, and then those wallets gain, market advantage, and you have a
serious problem.

Dave Longley: and so we want to be careful not to sort of repeat problems
like that in the ecosystem that were that arose because of architectural
decisions. We don't want to repeat problems that we had with IDPS and
providers that became super providers and no one else can compete in the
space. So I have a whole bunch of those concerns. I do know that Demetri
has mentioned that in this particular use case or at least a subset of the
use cases users have cryptographic keys on their device that they want to
be able to use and they're not living in the cloud. And so that's something
else we have to consider in the signing interface is that the signing has
to literally happen on the device that is involved in the use case.
00:55:00

Patrick St-Louis: Is that Richard?

Dave Longley: But I wanted to raise all those concerns so that if we can
come up with a way to architecturally do this that would address those
concerns, we're going to I think have better outcomes because I think this
feature is so useful and so powerful that it could spread and it could
create market trouble and that leads ultimately to problems for users at
March.

Dmitri Zagidulin: Thanks all very valid concerns except I would argue with
your phrasing that this feature would create market problems. It's a
fundamental feature that wallets should have. So if they don't have that
feature they should have a problem. Those other wallets this is a
fundamental operation that's needed that we don't account for. That's it.

Dave Longley: So yeah, so to clarify, I mean the architecture choice that
we make to enable this feature could create market problems. I was saying
if we ignore the other if I propose that you go to websites and websites
know how to do all the issuance and there is a primitive that every wallet
has to just sign something and…

Dmitri Zagidulin: That is what's being requested by exact thing. How?

Dave Longley: we rely on all it's it's a little different because the
information that's being sent over is not for example It's a bunch of data.
So it's not just sign this hash.

Dave Longley: and I think that leads to a question of whose responsibility
is it to figure out what it is you're signing. And then that becomes a
question around that's the digital wallet needs to understand what you're
signing as opposed to trust a user deciding to trust a website to sign it.
There's all of these issues are sort of all wrapped up together and they
all depend on the architecture. So I want to be really clear. I'm not in
any way arguing against this being a really powerful useful feature and
users having a wallet that enable them to sign and create assertions. that
should be there. But how we go about doing it can have a really significant
impact on the ecosystem.

Dmitri Zagidulin: So that makes sense. What would you suggest the next
steps be? with that in mind

Dave Longley: I would say if we can look at what would an architecture look
like if so we have an existing architecture where you go to issuer
coordinator websites and you build up credentials and then the issuer ends
up signing them instead of the user. How close could we get to that
architecture so that we minimize what the digital wallet needs to do while
also addressing these trust concerns? can we get to something that's really
close to that so that this becomes a usable trustable feature that's even a
significantly lower level request to the wallet and…

Patrick St-Louis: Sorry,…

Dave Longley: that would be my suggestion.

Patrick St-Louis: I noticed we're just one minute to the hour. my mic was
muted earlier. so I'm very interested in this feature. there's obviously a
lot of discussions to be had. so I put some labels and we'll try to
remember to start with this issue the next time. because this speaks to I
can think of a few use case and even some things I'm working on. I think
some of the concern that you raised Dave are valid and some of the other
ones I'd like to discuss them a little bit more. U so yeah I would probably
defer discussion to this until the next meeting.

Patrick St-Louis: One last question for you the same as the last one. Is
this used currently somewhere in some software as is defined here or…

Dmitri Zagidulin: …

Dmitri Zagidulin: so we're implementing it into learn a credential wallet
for use with the resume creator and…

Patrick St-Louis: it's a Okay.

Dmitri Zagidulin: and some other stuff. I don't know how major of a Awesome.

Patrick St-Louis: Very interesting. so we'll make sure to start with this
issue on the next meeting. I'd like to at least allocate a good 20 minute
discussion more on this or more if needed. with that being said, I'm going
to adjoin the meeting today. Thanks a lot for attending and next week the
meeting will be cancelled I believe.
01:00:00

Patrick St-Louis: and we'll start resuming normal schedule the week after
and we'll probably then also discuss a little bit about the holiday period
where we might see a couple more cancellations. so have a good rest of your
day. Thank you very much for attending and see you next time.
Meeting ended after 01:00:53 👋

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