[MINUTES] CCG VCALM 2025-10-14

Meeting Summary: CCG VCALM - 2025/10/14

*Attendees:* Dave Longley, Dmitri Zagidulin, Eric Schuh, Joe Andrieu,
John's Notetaker, Kayode Ezike, Manu Sporny, Michael Burchill, Parth Bhatt,
Patrick St-Louis, Rodrigo

*Summary:*

The meeting covered community updates, pull request processing, and issue
discussions. Key topics and points are summarized below:

*Topics Covered:*

   - *Community Updates:*
      - IIW (Internet Identity Workshop) next week, leading to cancellation
      of the regular call.
      - A special data integrity call next week regarding ski sign, a new
      post-quantum signature mechanism.
      - Incubated specifications (render method and confidence method)
      adopted by the verifiable credential working group. A schedule swap is
      planned for the CCG incubation and VCWG spec refinement calls.
   - *Pull Request Processing:*
      - PR 549: Define reserved exchange variables. Kayode addressed
      comments, and the PR is ready for merge.
      - PR 556: Define structure for credential issuing steps and add ID to
      credential templates. Still needs to be processed.
      - PR 559: Update API component tables. Eric is working on resolving
      conflicts.
      - PR 562: Update architecture section to include statement about
      implementing multiple components. Ready to merge.
      - PR 563: Clarify interaction path requirements. Ready to merge after
      Dave's edits.
   - *Issue Discussions:*
      - Issue of VC request example: Discussed the need for a way for web
      applications to have wallets sign credentials. The discussion centered on
      self-attested data and different approaches to handle it, with
      considerations on how to include it within the architecture.

*Key Points:*

   - *PR 549:* Ready to merge after Kayode's work.
   - *PR 556:* Kayode to incorporate a comment; then, it'll be ready to
   merge.
   - *PR 559:* Eric is resolving conflicts before merging.
   - *PR 562 & 563:* Ready to merge after the required updates.
   - *Issue of VC request example:* The group explored different approaches
   to address the use case, including whether the resume builder should be
   responsible.
   - The meeting concluded with a reminder of the next meeting's
   cancellation due to the Internet Identity Workshop.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-vcalm-2025-10-14.md

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

Dave Longley, Dmitri Zagidulin, Eric Schuh, Joe Andrieu, John's Notetaker,
Kayode Ezike, Manu Sporny, Michael Burchill, Parth Bhatt, Patrick St-Louis,
Rodrigo
*Transcript*

Manu Sporny: Hey we've got a good set of folks here. So, let's go ahead and
get started. welcome everyone. This is the verifiable credential API for
life cycle management call. we have an agenda today which is largely kind
of the same general agenda we have. We're going to go over some community
updates, do some pull request processing, and discuss some issues. that is
basically it for today. and if we run out of issues, we will just end
early. any other updates or changes to the agenda? Is there anything else
people would like to discuss today? All right.

Manu Sporny: If not, let's go ahead and get started. does anyone have any
community updates that they would like to discuss or share? I think the
only two that may be relevant is IIW is next week. So, I know a number of
you might be going to that next week. so I expect we're going to cancel the
call for next week. and we also have a special data integrity call next
week around ski sign. It's a new postquantum signature mechanism with
really small signatures like 141 bytes versus 1 kilobyte to 4 kilobytes
which most of the other postquantum stuff have.

Manu Sporny: it is in the NIS competition has a very large group of people
associated with it. So that is next Thursday at 10:00 a.m. we also have
some of the incubated specifications at the CCG have been adopted by the
verifiable credential working group specifically render method and
confidence method. And that call will be this Thursday at 10:00 a.m. And
then we're going to try to shuffle some things around. We're going to try
to switch that call with the incubation call. So hopefully we can move the
incubation call to Thursdays at 10:00 a.m. and then move the spec
refinement the verifiable credential working group spec refinement call to
when we normally have our VCWG meetings.

Manu Sporny: we will just meet when the BCWG is meeting. So, we're just
trying to swap those two calls this week. I think that's it Anything else
from anyone else before we get All right, let's get into pull request
processing then. let's go in order. first up is pull request 549. Define
reserved exchange variables. Coyote, you've been working on this. please
give us an update…

Kayode Ezike: So I was able to address all the comments of the weekend that
were there.

Manu Sporny: if you can.
00:05:00

Kayode Ezike: It's just one more question I had. It's not a critical one. I
don't think we need to answer this to merger it. It's just as I was
changing I remember we decided to basically change response all the
references to use problem details. so as I was doing that, I came across
one usage in an endpoint path just definition that I think is outdated.
it's basically an endpoint that starts with endpoints. It seems to be a
discovery endpoint for exchanges, which I don't believe is really something
that makes all that much sense because exchanges are, shortlived resources.

Kayode Ezike: So, I was just wondering if I could just delete those two
endpoints that I found. one for exchanges slash exchange ID. Go ahead,
Dave. Okay.

Dave Longley: You can, but you'll immediately have a conflict with Eric has
another PR that does the same thing. I don't know if we've merged that yet
and if you could rebase, but those are meant to be removed.

Kayode Ezike: I thought he only removed it in the table, but I know he
removed it in the OAS as well, but I'll check.

Dave Longley: That's a question for Eric. So maybe we could just do it here.

Kayode Ezike: Is Eric here today?

Kayode Ezike: He is. Okay.

Eric Schuh: Yeah, I'm here.

Eric Schuh: Yeah, that was after last week's discussion. I, removed those
from the OAS file in the, what is it? PR 559, I believe. so the current
version of that PR should not have those in the OAS any longer, I don't
believe.

Kayode Ezike: Thank you. So, in that case then this is ready to go Manu and
yeah it's ready to go.

Manu Sporny: Okay, that's great.

Manu Sporny: Any objections to just merging it now?

Manu Sporny: Do you need to do any other cleanup?

Kayode Ezike: The only other thing I'll call out is that there was one
thing I noticed between this is I guess jumping to the other PR…

Kayode Ezike: and I made a comment in that but basically where I think Dave
was saying that we wouldn't need to change the OAS to basically support the
whole credentials and options fields that we expect for the templates to
render to. I think that that comment is in conflict with one of the updates
that I made here from his suggestion which was to update an example to
include the credential field in the top level.

Kayode Ezike: and so I just wanted to allow Dave to elaborate if we do
include it in an example workflow config, that means that we're saying
we're committing to that field being in the schema for a workflow config,
in which case we actually would need to update that and then we can close
this out and then I can make that update in the other PR. Otherwise, I
should remove that credential field here and then continue with the other
one. and go hit these.

Dave Longley: Can we find on the updated example? I would not think it
would change the schema because it's the output of the template that
produces this. the change is not to the input to the workflow. It's what
the workflow generates when the template is rendered.

Kayode Ezike: Interesting. But this example that I put this is what would
be inside of a workflow config though, isn't it? And this is what you
recommended for me to do. So then workflow

Dave Longley: So that looks right except that's part of the template.

Dave Longley: So that might not be a valid That template should be a
string. but it looks like it's an object.

Kayode Ezike: No, it's a string. There's a quote over there.

Manu Sporny: Not back.

Manu Sporny: It's not back tick escaped is the issue or…

Kayode Ezike: I see.

Dave Longley: Yeah. it would be in the template…

Manu Sporny: sorry back slashes escaped.

Kayode Ezike: So then I should do that, but then it would still have the
credentials inside of there, though. No,…

Dave Longley: which would not impact the JSON schema for the workflow.

Kayode Ezike: I Okay, because it's a string and so it shouldn't Okay.

Kayode Ezike:

Dave Longley: Yeah, it's just opaque from the perspective of the workflow.

Kayode Ezike: All Mono, should I back slashescape this template or…

Manu Sporny: Can you …

Manu Sporny: why don't we just merge this and you can just fix it on main.

Kayode Ezike: Okay. No,…

Manu Sporny: I want to get this in here, right? Because it's like we're
going on week five and…

Kayode Ezike: I agree. That Sounds good.

Manu Sporny: you've done a lot of great work and everything else is just
like editorial cleanup, right? Okay.
00:10:00

Kayode Ezike: right.

Manu Sporny: All Any objections to merge? All right. I've got a clean
commit history. Looks like it. All right.

Manu Sporny: then rebase and rge. All right, thank you very much, Coyote. I
know that was a tremendous amount of work, so much appreciated.

Manu Sporny: And then do we feel like we can close 446?

Kayode Ezike: No problem.

Kayode Ezike: I think so. Yes, we should be able to Yeah.

Manu Sporny: Okay. Yep.

Dave Longley: Do we have any other comments? If we just scroll up. I just
want to make sure we didn't have anything that we Yeah, sure.

Manu Sporny: Give me one second. how results are stored.

Dave Longley: That was in the PR, I believe.

Manu Sporny: And this was just

Kayode Ezike: Yeah. …

Kayode Ezike: it's just reopening the PR.

Manu Sporny: Okay.

Kayode Ezike: Sorry, the issue. And if you scroll a little bit further, I
think so. I think this should be fine cuz we had another PR that we used to
close this issue but then I reopened it to address the variable stuff and
that's what that comment is saying but outside of that I believe that we've
addressed everything. Yeah, that's before

Manu Sporny: All looks good to me. All right, that one is closed. Let's go
and check out our other poll requests. next one is define structure for
credential issuing steps and add ID to credential templates, which is
PR556. Coyote, this one's your one as well.

Manu Sporny: Please take us through it.

Kayode Ezike: Yeah, this is the one…

Kayode Ezike: where I said I just left the comment there just outlined
earlier where I was wondering if we would need to change the OAS, but since
it's a string, we wouldn't have to. And that's about all that I've done on
this one. the other one took more time, so I think there's still one more
comment that basically to actually figure out…

Kayode Ezike: where to put the credential options field and specify that.
And so I just have to incorporate that thing that Dave said in that second
to last comment over there.

Manu Sporny: …

Manu Sporny: this still needs to be processed,…

Manu Sporny: I guess, is what you're saying.

Kayode Ezike: Yeah, exactly.

Kayode Ezike: Get to that.

Manu Sporny: All So once you make that change, we'll go ahead and merge.
Okay.

Kayode Ezike: Yeah, should be good. Yes.

Manu Sporny: And the change I didn't get to see what the change is not too
super complicated meaning if you get it done by this weekend, we can
automerge or just merge it down. Okay. All right.

Manu Sporny: we don't have a lot of reviews on this. I mean, there's
discussion. so if folks could review PR556 before the weekend, that would
help merge it down. it'll get merged down anyway, but just, want to make
sure people see it. go ahead, Patrick.

Patrick St-Louis: About ials so it's a bit to credential issuing steps is
that related to workflows?

Kayode Ezike: So what's happening here is that the credential templates
basically there's this issue request field that was added to a workflow
step config and…

Patrick St-Louis: Yeah.

Kayode Ezike: what it does is it basically says these are the set of
credential formats that should be released from this step right and so ref
and it does that by referencing a credential template by index from the
credential templates field in the workflow config. So it's just a way to be
clearer about which steps are releasing what credentials. Yeah.

Patrick St-Louis: Okay, because it's still one issue I had a while ago and
it's still not clear to me is what happens to the ideas of workflow when
you have an exchange that is something else than the VC API. So what we had
before we introduced the interaction is that the VC API exchange URL was
used as the interaction URL as well. So that endpoint sort of returned the
different protocols. so let's say I have an inter interaction URL and I
only offer a OIDC issuance flow. Where does the workflows and exchange come
into play? Because you're not actually using the VC API exchange in there.
00:15:00

Kayode Ezike: I have response by

Patrick St-Louis: So is that just overwritten by the OIDC and you're off to
the OIDC and you're not actually using the VCOM spec.

Dave Longley: So in that case in fact using VC API exchanges you'll still
use the exchange URL and the OIDC servers those necessary endpoints will be
off of the end of the exchange. So when you create an exchange that
supports OIDC or OID4VP, if you support either one of those, whether you
support them exclusively or in addition to other protocols that the wallet
can choose from it, there's a single exchange for all of those things. And
the wallet then decides either to interact with the exchange using whatever
protocol they want to.

Dave Longley: And if for example oid for VP they'll fetch the metadata from
that the exchange serves…

Dave Longley: which will tell it where to get the authorization request
endpoint and how to get that and where to send it. And if you're
interacting with the VCOM spec where you're just using a direct exchange
you'll just post back and forth with the exchange endpoint.

Patrick St-Louis: So that's really not clear to me.

Patrick St-Louis: So let's say I have a interaction URL IUV and there's
only one protocol right and it's oid for VP there's no VC API there's no
invite request nothing where is this exchange URL how's the wallet going to
know the exchange URL for this workflow defined by the VCOM API

Dave Longley: So in the oid forvp URL that is listed there. the endpoint
for that if I'm remembering offhand is a URL that goes to the authorization
request. Is that correct? I don't remember. I'd have if that's correct, the
way that URL will look will be the exchange URL and then tacked on to the
end of it slau authorization requests.

Dave Longley: So the exchange URL will be embedded in that URL.

Dave Longley: It'll be treated as opaque from the wallet's perspective. It
does not care that this happens to be implemented on top of the VC API, but
you'll be speaking oid for VP. The exchange will serve up the authorization
request to you and it will do it by using the Okay, so we've got one. Yeah.
Yeah.

Patrick St-Louis: So I put that's from the spec.

Patrick St-Louis: So that's the example from the spec. I'm just copying the
actual protocol. So there's the probably ID4 VP.

Dave Longley: So this is getting into how we wanted to add some examples to
the VCOM spec so you can see exactly how this looks with functioning on top
of exchanges.

Dave Longley: But your client ID is going to be the exchange ID and…

Patrick St-Louis: So you're using the client ID.

Dave Longley: it's going to be the exchange authorization response just
like…

Patrick St-Louis: The client ID is the Exchange URL. Is that correct? So
you're…

Dave Longley: how it looks in the example you pasted in the chat here. But
from the wallet's perspective,…

Patrick St-Louis: but it's not just a open ID for VP exchange then it's
like a VCOM open ID for VP exchange because you then embed some kind of
requirement that's necessary to use this as a VC API exchange But from the
issuer perspective,…

Dave Longley: it doesn't know or care about any of

Dave Longley: that it doesn't have it.

Patrick St-Louis: it's like a opinionated use of open ID for VP where you
have a very strict requirement that the client ID must be the exchange URL.
Okay.

Dave Longley: Oid forvp has a number of different ways to express client
They have the client ID type of that's called redirect URI that can be
expressed as a scheme or as a prefix. They also have other types of schemes
like you can use a DID for your client ID and you can use an X509 sand DNS
field for your client ID and so on. And each one of these can work and…
00:20:00

Patrick St-Louis: Okay.

Dave Longley: I know this because I've implemented it on top of VC API
exchanges.

Dave Longley: So in the case this simplest case that you're using the
redirect URI type of the client ID just ends up being the exchange
authorization response which looks a whole lot like what you've pasted into
the chat here. And your exchange server just uses the existing exchange
information which it can get from processing the step or the step template
or a VPR. It can generate an authorization response that's compliant with
oid forvp from that when the wallet hits that URL and…

Patrick St-Louis: Okay.

Dave Longley: and it can also generate all the metadata that's required for
oid forvp to make all of that happen.

Patrick St-Louis: Because the real goal of this is for Dcom, right? So,
let's say I want to use Ditcom as the issuing protocol, which I think I
should be allowed to in the spec. how then would I communicate this
exchange didcom has a very specific spec for didcom URLs. Where would that
fit in? Would then there need to be a requirement that you use a goal for
the exchange and you communicate this as part of your message so that the
the wallet can track the workflow exchange.

Patrick St-Louis: because currently my train of thought is just you get
this interaction URL and then you just go off with the DICOM and you
complete it according to the DICOM and you never actually query the VCOM
workflow. So it's like a totally different thing. Okay.

Dave Longley: So I…

Dave Longley: if your s so this URL that's going to be used in any protocol
either you're going to be connecting to some external system or you're
going to integrate it with your existing exchanges so you can have a single
exchange that tracks your state regardless of the protocol chosen by the
wallet. You can always have your interaction go wherever you want over on
your coordinator system. So if you don't want it to go to a VCOM system
because you don't have this integration and then you can do that. the
disadvantage to that is if you want to support multiple protocols, you're
going to be checking exchange in different systems in different places.

Dave Longley: So the VCOM spec allows you to unify all of that so you can
have your state in one place. And so if you do that, if you have a way to
take your didcom implementation, whatever this I know it's peer-to-peer,
but I'm just going to call it the server side of it. If you put…

Patrick St-Louis: Yep. Yeah.

Dave Longley: if you put the server side of that, you integrate that with
your Exchange server so that you expose whatever URLs are needed in that
protocol, then you would include those in your interaction URL for DICCom.
And when the client goes and talks to those URLs, they'll be talking to
your Exchange server, which should be able to read what and update whatever
state is associated with the exchange. So you just have one thing that the
coordinator works with.

Patrick St-Louis:

Patrick St-Louis: It's still not clear to me. it sounds almost to me like
there would need to be when you have an exchange URL there's a mandatory
like field that is the workflow exchange URL itself and then you add your
list of protocol that you can interact with and that mandatory exchange URL
is where the client could pull for the state of the interactions.

Patrick St-Louis: Wouldn't that be preferable instead of trying?

Dave Longley: You say are you referring to the coordinator client that's
trying to get the state?

Patrick St-Louis: Yeah. Yeah.

Dave Longley: Yes, that exists.

Patrick St-Louis: My wallet. So

Dave Longley: Your wallet. That's different. So, there's the coordinator
who's trying to get the state of the exchange as the exchange interacts
with the wallet. and so there's a client there that can get that
information. And then there's a client which is the wallet itself that's
actually participating in the exchange over whatever protocol that I would
need to dig into d intocom more to maybe better answer your question
because I can tell I'm not answering it well enough.

Dave Longley: But given that there's something that you implement on the
server end of DICOM, there's some way to put that at the end of an exchange
and just have the exchange state be backing it such that the coordinator
client when it needs to read what's going on with the wallet or…

Dave Longley: whether what has happened

Patrick St-Louis: The com has its own states,…

Patrick St-Louis: So there is very much this, state of the didcom exchange,
Whether you want to request a presentation, issue a credential, there's
these different states of where the two parties are in their negotiation.
from what I'm understanding this vcom workflow and exchange would just be a
way to uniform these states across different protocols right …
00:25:00

Dave Longley: That's right.

Patrick St-Louis: because every protocol is going to go through a sort of
offer request issuance and then maybe something in between if there's
wallet binding and whatnot but at the end of the day yeah and…

Dave Longley: Yep, that's exactly right.

Patrick St-Louis: then we want a uniform sort of data model to express
these different states. So, didcom can have its own state management or IDC
can have its own but ideally whether I'm using didcom or IDC. I have a
consistent way of pulling the state of that exchange and…

Dave Longley: That's exactly right.

Patrick St-Louis: so it seems like the way to get that endpoint for the
exchange is something else than the protocol URL I'm interacting with in
itself. And it seemed like here with this oi open ID for VP example, it's
kind of trying to put that URL in there. but wouldn't it be preferable if
my interaction URL has that exchange URL as a standalone value? I can sort
of query in parallel that I'm going through the exchange protocol.

Dave Longley: So I might be getting twisted up on when we talk about client
and…

Dave Longley: getting the state. because from the wallet's perspective, if
the wallet speaks DICOM, it's only going to use DICOM to interact with the
exchange. It's not going to also somehow know about VCOM.

Patrick St-Louis: Yes. Okay.

Dave Longley: So the VCOM part of it is for the coordinator the issuing or
verifying what it's only on that coordinator side and that is already well
specified.

Dave Longley: It's the exchange If they do a get on the exchange URL
itself, they will get the state of the exchange and that never changes
regardless of the protocol that the wallet chooses to interact with.

Patrick St-Louis: Yeah. But my question is …

Patrick St-Louis: how do you uniformly convey that exchange URL…

Patrick St-Louis: and…

Dave Longley: I see…

Patrick St-Louis: why IDC forb here.

Dave Longley: what you're saying. When you create the coordinator creates
the exchange,…

Patrick St-Louis: Yeah. But…

Dave Longley: when they create it, they receive the exchange URL and they
will know based on either creating it or fetching the slash protocols on
the end of that exchange URL what protocols are offered by that exchange.

Patrick St-Louis: but with the introduction of the initiating interaction
the L to get the interaction protocols doesn't need to be the exchange URL
it can just a short URL in the example we have here issuer example SL
interaction 1223 IUV yeah

Dave Longley: So, the coordinator knows and has all that information.

Dave Longley: Yeah. There's a difference between the fact that the Exchange
server will serve protocols and that's always going to be available on your
Exchange server. That's not the same thing that you necessarily share at
all with your client. I'm just pointing out that the coordinator has that
window into asking the exchange for those protocols…

Patrick St-Louis: Right. Perfect. Uh-huh.

Dave Longley: if it wants to. And one way to implement your interaction URL
on your coordinator is use whatever URL you want. And when that URL gets
hit, you have some kind of state or me way to map it to an exchange where
you could fetch the protocols from the exchange as a proxy and then send it
to the client.

Dave Longley: But the client is not the one that's directly interacting
with the protocols endpoint on the exchange They directly interact with
your interaction They get whatever is in that protocols object which you
could have proxied or you could have manually created whatever process you
want on your coordinator. And then the wallet makes a choice of protocol
and starts interacting with the exchange. And once the exchange becomes
active, the coordinator can be polling or…

Dave Longley: set up call backs to rece to be notified when the state
changes on the exchange and the coordinator can pull information from the
exchange to find out what has been provided, what protocol was selected,
all of that sort of stuff. Yeah.

Patrick St-Louis: Okay. …

Patrick St-Louis: I'll take that, reflect on it a little bit more, do some
more tests. still not 100% clear to me, but I think I understand a bit more
the intention here. the Yeah.

Dave Longley: and feel free to reach out to myself or to others in the
group and I'd be super interested to I'm sure we all would to see an
implementation of DICCom writing on top of this especially if it gets to
the point where you could speak direct oid for VP and DITCOM on the same
exchange that would be
00:30:00

Patrick St-Louis: So, I've been tasked with some task on the Bifold wallet.
So, I'm starting to look at that QR code scanning. And one of the nice
thing I'd like to have is it's able to just, scan these exchange and then
just use its, natural because there's already the didcom logic in there.
So, it's just to be able to recognize these URL and be able to process
start with just didcom to start. and yeah.

Dave Longley: Sounds good.

Manu Sporny: All right. yes, a plus one to seeing kind of the progress,
Patrick, as you make it. very interested to see, if it slots in we think it
is going to. all right. I have completely lost where we are on 556.

Kayode Ezike: So, yeah, it's all good. So, I was just explaining what it
was and that's what left the discussion, which was fruitful either way, but
the only thing left is for me to incorporate the comment that Dave put
inside of the PR.

Kayode Ezike: So, I'll work on that. And then I think we said we would try
to get it in asynchronously. So,

Manu Sporny: All right.

Manu Sporny: Plus one to that. Thank you. that sounds good. All right. next
PR is 559 update API component tables.

Manu Sporny: Eric, I think you were kind of processing this. I see Dave
Longley is kind of plus one. merging it. how are we doing on this one?

Eric Schuh: Yeah, as far as I'm concerned,…

Eric Schuh: this one should be good to go. I guess with the caveat that the
respspec OAS repo also needs updates for this to take effect.

Manu Sporny: And I have still not gotten around to merging that. So, I will
try to remember to do that.

Eric Schuh: Just a note on that I did see that tall made some comments on
the respect OAS PR that I submitted.

Eric Schuh: I think it was entirely just updating language in comments I
left in the code.

Manu Sporny: Okay.

Eric Schuh: They all looked good to me. So, if you're reviewing it, feel
free to just accept what Ted has suggested and merge it.

Manu Sporny: Sounds good.

Dave Longley: I wanted to make a comment about that. I think a couple of
the PRs that you've put in, Eric, are conflicting with each other or
pulling different commits in. this one has the text that is in a different
PR for talking adding that description around the…

Eric Schuh: Yeah, I Yeah,…

Dave Longley: how readers should think about the architecture.

Eric Schuh: I can explain what happened.

Eric Schuh: It's basically Yeah,…

Dave Longley: So Mike,…

Dave Longley: just quickly before you, we don't want to merge the one that
was just approved because those things got mixed and then we're going to
have some problems with that other PR. So, we need to get that sorted.

Eric Schuh: yeah, what happened is essentially just bad branch management
on my part. I pushed the original the 559 to main in my fork. which just
means that all of my subsequent branches incorporate those changes. so if
you'll see here everything from that October se 7th commit is what is in
the 559 modulo updates to the 559. so I not sure I can undo my two current
PRs. although I just want to introduce them today but once 559 is merged
the other two should I think be correct in that they are just some minor
updates to the index.html with language changes.

Manu Sporny: Okay, we're going to leave conflict resolution management to
you. just because this one, has a merge conflict, I think, at this point.
So, you're going to have to resolve something probably because of the one
that we just pulled in from Coyote. that but you're saying this is pretty
much ready to go.

Manu Sporny: Modulo figuring out the history

Dave Longley: So if you…

Dave Longley: if you click on files changed there just before we go to the
next PR and you scroll down to the text that says below. on that text right
there 518 through 525 we're going to see in conflict is under discussion in
another PR.

Dave Longley: Keep that in mind. Yes, that's…

Eric Schuh: That's nasty though.

Eric Schuh: That's how it did it.
00:35:00

Dave Longley: what I'm trying to say. If we merge this PR,…

Eric Schuh: Okay.

Dave Longley: we're going to have even more problems. So, something has to
undo that. All the changes that are in this PR are in the other PRs as
well, and they're currently under discussion.

Eric Schuh: I guess I'm learning how GitHub handles branches on forks. I
Yeah.

Manu Sporny: So what's all this? Yeah, I'm trying to think of an easy way
to Let's look at the other ones. and…

Dave Longley: So, one possible resolution,…

Manu Sporny: then Go ahead, Patrick.

Dave Longley: just to put this out there, is to change the other PRs so
that they merge into your main one, but then we would don't have any way to
review them. and then merge the main one at the end. The other way is to
back stuff out of the main one.

Patrick St-Louis: Something works with fork on other project is I create a
fork but then I don't merge from my main I keep my main synced with the
main and I create branch for the things I want to merge and I just merge
from my branch into the main of that other repo. and if there's a conflict
I can just update my main branch and then rebase. it's sometime depending
on the…

Patrick St-Louis: how complicated the rebase is it can be complicated but
most of the time it's only small things. would that solve the issue here?

Eric Schuh: Yeah, it would I guess the problem I ran into when I was
submitting these two new PRs was that I had already pushed the original 559
one to my main branch in my fork.

Eric Schuh: So I would have had to I guess reset my main branch. I don't
know.

Patrick St-Louis: Yeah, I think this is the …

Patrick St-Louis: if you would add separate branch and just keep just in
sync with the other main you never push to your main directly.

Eric Schuh: Yeah. Yeah.

Patrick St-Louis: I think that would help a lot. yeah.

Eric Schuh: Certainly for the future that is the plan.

Eric Schuh: I guess I'm just trying to figure out if the easiest way for me
to do this is to just reset my fork entirely and then create three new
branches and resubmit the three PRs separately. That might be the cleanest
way to do this, but the two branches for the two new PRs are …

Patrick St-Louis: Yeah, you can probably revert the merge to your main.

Patrick St-Louis: I don't know if is your branch still open Yeah.

Eric Schuh: but that was the original problem was that I didn't have a
branch for this PR559.

Patrick St-Louis: I see.

Dave Longley: So, an alternative to that might be to branch off of your
main with…

Eric Schuh: It was Yeah.

Dave Longley: what you have in this PR and…

Eric Schuh: Okay.

Dave Longley: fix it up and just submit that one fix and then clean up
reset your main to match the remote end and…

Dave Longley: then you can keep your other two PRs and you don't have to
mess with those.

Manu Sporny: All right.

Manu Sporny: So other than that, is there anything to discuss? Do you
think, my recollection was this was pretty much ready to go?

Eric Schuh: I don't believe so. No. I thought it was ready to go.

Manu Sporny: All so I will wait for you to signal a new PR or something or
modification this one or force push or whatever and then we can merge it
before the weekend once you get those fixes in there. next item is update
architecture section to include statement about implementing multiple
components. This is 562 562.

Manu Sporny: go ahead and take us through this one.

Eric Schuh: Sure.

Eric Schuh: So, once again, you're going to see, as we just discussed, some
branching problems. Dave's comments, I think, highlight the relevant
section here. if we just want to look at that one, and he's already
provided, fairly extensive rewrite or just reordering maybe of what I
submitted. So the primary purpose of this was to handle sorry let me forgot
the number issue 558 and to effectively make it clear that the architecture
that we are describing in terms of individual components can be implemented
in any combination of the components for a given software.

Eric Schuh: package. Ted, I tried to incorporate, I think, the statement
that you provided last week as well in here.
00:40:00

Manu Sporny: Go ahead.

Eric Schuh: But this is effectively just a new paragraph at the beginning
of the architecture section before we then describe each component in
detail.

Dave Longley: Yeah, my edit here was so the original statement was
something along the lines of the architecture seen below is one way to do
this and then we say you can do what you want and then we say why we did
the architecture this way. And so I rewarded this to say the architecture
that we did below is one way to do it. Here's why we did it that way.
However, this isn't prescriptive. You can do what you want. and then I felt
like I needed to put some other words in there, but that could further be
word smith and perhaps made more concise if others have good suggestions.
But the main thing I wanted to do was we're presenting an architecture, why
we're presenting it this way, and then say, "Hey, but you don't have to
literally do it that way in your software.

Manu Sporny: All right. sounds good. was that the key section? it was
really just about the Arctic.

Dave Longley: That should be the only edit in this PR.

Manu Sporny: All So once you get this kind of merged and then rebased ic or
if you need to rebase it…

Eric Schuh: Yes, that is supposed to be the only edit in the PR is this
paragraph.

Eric Schuh: Yeah. Yeah.

Manu Sporny: then it should be good to go.

Eric Schuh: Once I fix up my fork and get everything cleaned up, this
should be fairly straightforward, I think.

Manu Sporny: Okay, sounds good. last PR is 563 clarify interaction path
requirements.

Manu Sporny: This one is also your PR, Eric. Go ahead.

Eric Schuh: So, you'll see similar issues in this one if you go to the
index.html monu which I guess is where we are. if you scroll down to the
initiate interactions or the interaction URL format. I can get the line
number if it helps.

Manu Sporny: This one

Eric Schuh: There we go. Yeah. So, this one is trying to handle issue 557
which we talked about last week. And it's basically just adding a note to
clarify the expected component that this interaction L originally lives on.
as well as just a note to clarify some of the requirements about from the
notes we took in issue 557 last week.

Manu Sporny: Yes, that's good.

Eric Schuh: I don't believe anyone's had a chance to review this, but feel
free to suggest language updates if

Dave Longley: We might want to instead of just saying business rules might
modulate actions. we also probably want to say that the origin of a
coordinator can also be an important trust signal for consumers.

Manu Sporny: Are you going to put that in as a change?

Dave Longley: I can in try to insert it somewhere or…

Manu Sporny: I don't know if you were asking me to do it or if you were
going to do it.

Dave Longley: is the suggestion going to go get destroyed…

Dave Longley: if we rewrite this rewrite the branch.

Eric Schuh: No.

Eric Schuh: I'll make sure to grab anything before I make any changes that
might overwrite

Manu Sporny: All so that one feels fairly straightforward as well,…

Eric Schuh: Yeah, that was the only change that was intended for this one.

Manu Sporny: And that was the only change in this one, I think. All That
one looks good as Any other comments on All then we'll go ahead and merge
that one as well. As soon as you get the updates in, or rather, by the
weekend, it'll probably be merged. Okay, those are all of the PRs.
00:45:00

Manu Sporny: Let's go ahead and jump over to issues that don't have ready
for assigned to them. There's only a handful. I think we're deferring the
BBS support until we have an implementation. add an issue of VC request
example. Good. Demetri is here. We postponed discussing this until you were
here, Dimmitri. And then let's see. Insure exchange OS for empty object.
this one's ready for PR, isn't it?

Dave Longley: Yeah, I think that was just a minor oversight in the OAS
files.

Manu Sporny: All right.

Manu Sporny: So that one is good. All right, let's get back into this
discussion at an issue of VC request example. this one the use case is go
ahead Demetri if you want to just really quickly review the use case and…

Manu Sporny: then we can kind of continue the discussion.

Dmitri Zagidulin: Yeah. …

Dmitri Zagidulin: so since we last talked about this on a previous call
here. Yeah. But first to address your point, what's the Quick summary is
there's a number of web applications that help the user compose verifiable
credentials, right? either compose self-issued ones or institutionally
issued ones or arrange multiple variable credentials into some bigger
package either a VP or the resume author takes a bunch of your credentials
and puts them into sections allows you to create an overall container
credential which contains all the other credentials.

Dmitri Zagidulin: all these web apps need to be able to sign the resulting
credential. and that's one piece that we don't have that enables mobile
wallets, edge wallets to sign a given unsigned credential with keys on the
device. So this is like an issuer except the an endpoint. The issuer is a
mobile wallet and you'll see Nate Auto has weighed in on this as well. he
also has that same pain point and had a long sort of side conversation with
Dave Longley.

Dmitri Zagidulin: I think Dave was expressing the position that can't we
just use the r API endpoint? and I think what it came down to is he was
assuming that wallets have access to an external cloud issuer. whereas
there's a number of wallets that keep the keys on the device that don't
have cloudkms etc.

Manu Sporny: Kill that straight.

Patrick St-Louis: Couldn't that I'm not sure understand exactly what the
problem is can't the wallet called an issuing sort of point local issuing
endpoint in a way like what's the Right.

Dmitri Zagidulin: the problem is we don't have syntax for a web application
to say hey wallet please sign this object. That's the problem.

Manu Sporny: Go ahead, Dave.

Patrick St-Louis: …

Dave Longley: Go ahead,

Patrick St-Louis: I was just going to say isn't that very similar to a
wallet binding operation? the wallet needs to send back something that it's
signed as part of an exchange. isn't that similar for zero knowledge proof
or…
00:50:00

Patrick St-Louis: so on I'm thinking about anreds right now I know the
wallet needs to sign the presentation request so that the issuer can bind
it to the key that the wallet shared. okay.

Dmitri Zagidulin: Yeah, could be similar.

Dmitri Zagidulin: I'm just saying we don't have syntax for it in this
particular case.

Patrick St-Louis: So, that sounds like this is just a very specific
workflow,…

Patrick St-Louis: That would need to be defined. And is that just the case
here? we want to define this kind of pattern that the wallet needs to sign
with something that it knows and…

Dmitri Zagidulin: Yeah. Yes.

Dmitri Zagidulin: Yes. Exactly.

Patrick St-Louis: only it knows not a cloud wallet, but something local.

Dmitri Zagidulin: Yeah. Yeah.

Patrick St-Louis: I guess at that point it doesn't even matter, if it's
local or not. it's just the having that step that return me something you
signed. interesting.

Manu Sporny: GV.

Dave Longley: So, I want to get on the queue to support the use case. but
to say lots and lots of dragons, as Nate's saying here, we want to be
careful. There are a couple things I want us be about. We want to be
careful that we don't create a system where we send people arbitrary blobs
and they sign them with their wallets making assertions about them which is
very different from putting an authentication signature on a verifiable
presentation request that's based on basic wallet functionality which is
display the credentials the claims from the credentials you're going to
share.

Dave Longley: That's an expectation already that wallets are going to have
that feature surface to their users and then the users are going to sign
off and saying yes this is me handing this over. if we're saying you can
send arbitrary blobs and you're going to sign the thing wallets now need to
effectively provide an issuing interface for that. because if they don't,
then you could end up signing claims that the user wouldn't, understand,
and that would be a problem. and if you're going to require wallets to do
that, wallets become that much more challenging to implement, which can
create problems with competition in the marketplace. And so, there's a
number of different things to consider here.

Dave Longley: And maybe there's a better way to do it architecturally where
we still can support the feature of when you end up putting the signature
on this, it can go through an end device that has a key on a device,
however we end up making that work. I get that complication. but we need to
be careful here. I don't think it's a simple let's make an interface and
send some data and you sign the thing.

Manu Sporny: Let's see I put myself on the queue to plus one the use case
me meaning I think it's self attested data is very important right I mean I
think there's broad consensus on that and then the question is okay so if
we accept that use case as valid and us wanting to achieve it what's the
best way to achieve it I'm wondering two things that I didn't hear come up
one of them

Manu Sporny: why is it not okay for this resume builder service to just
issue something like sign and issue it but effectively say that the terms
of use are we take no responsibility this was self attested information
yada so that's one approach and I understand one of the downsides there is
the issuer is issuing something they're making statements about something
but I'm wondering if they can have a caveat in there saying "Yeah, we're
issuing this, but we don't stand behind it. It was just all self-attested
information from, rébuilder.com <http://xn--rbuilder-b1a.com> or something
like that. that's one The other approach is to basically give it to the
individual and don't sign it at all. just construct a verifiable
credential, but don't put a proof on it. Just hand it over to the
individual.

Manu Sporny: And then and this is where it gets a little dicey, if the
individual wants to present it to someone else, they put it into a
presentation and present it. There's no signature or proof on the
credential, right? It's just a bunch of information, but there is something
on the presentation so that the individual is saying, "Hey, I'm delivering
this information." there is still a whole bunch of issues around consent
screen like what's the wallet supposed to say when it's sharing this
information or how but that could be like I don't know I mean it's like
you've got to have some kind of trust relationship with this resume builder
site that it's not going to do something problematic anyway and just adding
those two approaches that do fit into the architecture that we have right
now that doesn't require the individual to
00:55:00

Manu Sporny: necessarily digitally sign the verifiable credential. I'll
also note that we are out of time but Patrick go ahead and then we can
continue the discussion a week after next.

Patrick St-Louis: Yeah, I was just like the only use case I can think…

Dmitri Zagidulin:

Patrick St-Louis: where you might need a sign credential then you want to
upload that rumé VC to a rumé bank right of some sort. otherwise I'm
thinking what's the point of the proof if the wallet signed it and it has a
credential. I mean it could resign it at any time. It could change the
proof. So, I agree that why would the wallet need to sign it as part of
that interaction? depending who keeps that resume afterwards the only
reason I could see is that if your resume actually stays on that rumé
building site after you signed it and you want to make sure that it doesn't
get changed or…

Patrick St-Louis: So that was just Yeah.

Dmitri Zagidulin: the resume actually stays on a wallet attached storage
instance.

Dmitri Zagidulin: But that's besides the point

Manu Sporny: All right. we will continue this discussion we're at time.
Thank you everyone for the great discussion. as always we will not have the
meeting next week because of the internet identity workshop and a number of
you are going to be have fun. and then we will reconvene the following week
to keep going through poll requests and…

Manu Sporny: All right. But yep. Mhm. BC HTTP API.

Dmitri Zagidulin: Quick mono quick question.

Dmitri Zagidulin: The CCG calendar has another VCHTTP API special topic
call after this. is that still happening this week and next? Okay.

Manu Sporny: I don't see it on my calendar. I don't see it on my What day
and time, Dimmitri?

Dmitri Zagidulin: Tuesdays at 4:00 p.m.

Dmitri Zagidulin: So immediately the hour after this.

Manu Sporny: No.

Manu Sporny: I don't see that on my CCG or W3C calendar.

Dmitri Zagidulin: Okay. Thank you.

Manu Sporny: It might be a stale.

Dmitri Zagidulin: Might be a glitch. Yeah. Got it.

Manu Sporny: All thank you everyone. Have fun at IW and we'll see you in
two weeks. Take care. Bye.
Meeting ended after 00:57:48 👋

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