[MINUTES] VC API 2025-04-15

VC API Community Group Meeting Summary - 2025/04/15

*Topics Covered:*

   - *IIW40 Report-out:* No significant updates from the Internet Identity
   Workshop #40 regarding verifiable credential protocols.
   - *PR 473: Bootstrapping Individuals into VC API Exchange Workflow:*
   This PR focuses on a protocol-agnostic method for bootstrapping users into
   VC API exchanges, primarily using HTTPS URLs encoded in QR codes. The goal
   is to improve interoperability between different protocols (oidc4 VP, VC
   API, DIDCOM, etc.).

*Key Points:*

   - *Protocol Agnosticism:* The current scheme-specific QR code approach
   is problematic due to trust issues and lack of interoperability. The
   proposed solution uses HTTPS URLs to leverage existing web trust
   mechanisms. This approach is also designed to be peer-to-peer, allowing
   initiation by either holder or issuer.
   - *Trust Signals and HTTPS:* The use of HTTPS URLs provides crucial
   trust signals, enabling delegation and reducing the need for complex
   encryption schemes required by protocol-specific URLs.
   - *Interaction URL Structure:* The PR proposes a standardized URL format
   including API version and interaction-specific identifiers. The inclusion
   of a version number is debated, with potential for removal in future
   versions. A query parameter to signal the intended interaction type is
   considered important for diverse QR code handling.
   - *Website Interaction Protocol:* The necessity of always including
   support for the website protocol was debated extensively. A consensus was
   not reached and further discussion is required. This allows for redirecting
   the user to a website for further interaction.
   - *Registry for Protocols:* The need for a registry of supported
   protocols was acknowledged, but concerns about managing such a registry
   were raised.
   - *Wallet Backends:* The requirement for wallets to have backends to
   generate interaction URLs is being considered to ensure accessibility for
   wallets without backends. The possibility of using Bluetooth protocols was
   mentioned as an alternative.
   - *User Experience and Protocol Selection:* Discussion focused on user
   experience, particularly how to present protocol choices to users in a
   clear and understandable way. The expectation is software, not users, will
   make protocol selections. Use of camera apps to scan QR codes and their
   potential for handling these interactions was noted.
   - *Future Considerations:* The possibility of generalizing the solution
   beyond VC API and VCs, and expanding it to handle other protocols and local
   connections in the future was acknowledged. This includes the possibility
   of future versions supporting protocols besides HTTPS.

*Action Items:*

   - Further discussion and refinement of PR 473 are needed, particularly
   regarding the necessity of the website interaction protocol and the version
   number in the URL.
   - Clarification on the requirements and design of the user interaction
   when presented with multiple protocol options is needed.
   - The PR will be updated to incorporate the discussions from this
   meeting.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-vc-api-2025-04-15.md

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

Benjamin Young, Dave Longley, Eric Schuh, Gabriele Bellini, Joe Andrieu,
John's Notetaker, Kayode Ezike, Manu Sporny, Parth Bhatt, Patrick St-Louis,
Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right, let's go ahead and get started. just let's see.
Yeah, let's go ahead and get started. Let me go ahead and pull up the
agenda on the agenda today is just covering any news from the internet
identity workshop number 40. If anything of relevance came up last week, we
can cover it here. and then we'll be spending some time to talk through
good to see a number of folks that have left some comments on their
attending.

Manu Sporny: So, we'll spend a good chunk of our time talking about what
changes we want to see in PR473. and then we'll jump into our standard
issue processing and assignment tasks. and that's it for the agenda today.
Are there any updates or changes to the agenda? Anything else folks would
like to discuss? with that, we've got some new people on the call. If you'd
like to introduce yourself, please feel free to do so. We usually do kind
of a short sentence on who you are short paragraph on who you are, what
interests you here, what you're kind of looking to get out of the calls.
does anyone want to introduce themselves?

Parth Bhatt: Yeah, I can go. thank you so much, let me turn on my camera.
Hey everyone, Parth here. I'm a technical product manager at MOI and I am
here to contribute more about verifiable credential API. So this is my
first goal to learn more about the VC API and it's been 3 and a half years
I have been working in the identity space specifically revolving around
decentralized identity and verifiable credentials. So yeah happy to
contribute here.
00:05:00

Manu Sporny: Wonderful, wonderful to have you here, welcome to the call.
Thanks for joining us.

Parth Bhatt: Thank you.

Manu Sporny: Okay. Anyone else want to introduce themselves? Okay. If not,
let's go ahead and continue on to a first agenda item which is anything of
significance that came out of IIW, any meetings held, conversations had
around verifiable credential protocols in general.

Manu Sporny: any report outs from IIW40. All right. If not, let's go ahead
and continue into our first PR, which is PR 473. this PR is one I raised
this. This one has to do with how do you bootstrap an individual into a VC
API exchange workflow?

Manu Sporny: so this largely has to do with if you are a regular person
with a mobile phone and you've got a digital wallet on that mobile phone
how do you engage with another entity in the ecosystem meaning bootstrap
into a protocol of some kind but do it in a protocol agnostic So the main
way that we have to bootstrap into some of these protocols are things like
scheme specific protocols.

Manu Sporny: So oid4 VP, hype, hip, all of those things can encode the URL
and protocol directly into a QR code and then another wallet scanning it
can engage in an interaction. the benefit there is that you have this very
simple way to kind of bootstrap the connection The downside it is very prol
specific. So imagine a world where we have multiple different protocols for
exchanging data.

Manu Sporny: then that would mean that you would have to select a protocol
before you generated the QR code which is not great right but because we
have multiple protocols so for example we at least have oid4 VP we've got
VC API we've got DIDCOM and then that's not even counting the Bluetooth
mechanisms Wi-Fi mechanism things like that. So, we need some way of kind
of initiating the engagement between two parties that's protocol agnostic
ideally. Dave, you're on the queue, please.

Dave Longley: Yeah, I wanted to mention from my perspective there's an even
bigger problem with that approach which is when you generate such a URL and
a QR code if it's specific to a protocol then the receiving and scanning
device doesn't necessarily have any idea whether it should trust the origin
of whatever's in that request. So if you go and make a protocol specific
URL and a device scans it, how do you decide whether or not to trust
whatever it is you might fetch from that L? And the way that some of these
other protocols have handled that is they've created sort of complex
schemes to do encryption and checking of messages and key management.

Dave Longley: which becomes necessary if you want to have a website that
might use a thirdparty provider to implement the protocol and that sort of
thing because it's necessary for that and it's necessary if you don't have
an HTTPS URL because you don't know what that origin is and the receiving
device doesn't have any way to put any trust signals up so you have to
design infrastructure around that and so this PR also speaks to that
problem by using HTTPS URLs to get back into the same trust signals people
are familiar with the web.
00:10:00

Manu Sporny: Yes, plus one to that. Thanks, So, what this BR is trying to
do is provide a way of addressing all of those, issues with the current
scheme based approach to generating R codes. this PR is also meant to be a
peer mechanism. It doesn't necessarily matter who initiates it. At least
with the VC API, it can be initiated by a holder. It can be initiated by an
issuer. it doesn't matter who generates the code. they can find each other
through that code. okay.

Manu Sporny: So, let's go ahead and kind of take a look at the PR. There
are a number of comments that each of you have sent in. I know Lane, you
had a couple. Ted, you did a good review. Dave, you've got some commentary
in here, as does I think Coyote, if I remember correctly. It's not showing
up here. Maybe it's in the actual files changed. so we're gonna go through
all of that today. and just have a discussion about So think the first
thing is this is what one of these QR codes looks like and it is an actual
protocol interaction app interaction a QR code.

Manu Sporny: It is quite literally just a HTTPS URL that has a certain kind
of format and form. let's see, let me try and find there's been some
reformatting that happened at the top here. That doesn't really matter, so
what we have actually, what? Let me try and bring up sites local and what
is the SVC API? hopefully this has the branch. Yeah.

Manu Sporny: So the thing that this PR does is add section 3.12 initiating
interactions the QR code format the protocols response the website
interaction protocol and the BC API interaction protocol and we can also do
oid for VCI4 VP hype all those things you can do over this mechanism as
well so let's look at the kind of the first thing here. we kind of talked
about the highle use case, but this is the flow diagram. can I open this?
Let me try and get this a little bit bigger. Hopefully folks can let me see
if hopefully folks can see this.

Manu Sporny: so what we have here is a holder coordinator so a wallet or an
app of some kind and then a verifier coordinator on this side. And what the
holder is trying to do is they're trying to tell the verifier how to start
interacting with them. so the use case here is it's a ret one of them you
can think of as a retail use case. So, you walk into a store, you put
things in your shopping basket, and you want to check out you would go to
your wallet app, you would click the checkout button, it would generate a
QR code, and you would scan it at the point of sale, and the entire VC API
or whatever protocol stuff would be set up from there. that's what this
whole process is doing. so, this is the holder opening their wallet.

Manu Sporny: They click something like a share credential button. The
wallet knows how to generate a proper interaction It knows how to render it
into a QR code and then it puts it on the screen. The holder then shows it
to the verifier coordinator system. So it could be a point of sales system.
It could be somebody else holding their phone. It could be a kiosk at a
stadium or an arena that's asking for a ticket. It could be one of those
things.

Manu Sporny: that kiosk or point of sale system scans the QR code and then
because it does an HTTP get on literally the URL that's in the QR code that
the URL has kind of like this form so it's a regular HTTPS URL it's got a
action specific speific ID. this is wrong. I will update that in a bit. but
it also lists basically the API version and we'll go into why we do that in
a bit. the point of sale or the thing does it could also do a fetch through
Bluetooth.
00:15:00

Manu Sporny: So, it doesn't have to go over HTTPS, but that's a little
more, involved of a protocol. Let's just do HTTPS for now. So, it gets back
a really simple JSON object that has all the different protocols. The
wallet knows how to speak. The point of sale system or the kiosk selects
among the protocols that it knows how to speak. So, it might not know how
to speak oid4 or it might not know how to speak VCAPI or it might not know
how to speak DIDCOM, but it's got five to pick from. It'll probably be able
to pick at least one of those. It selects its protocol and then goes to
transmit the protocol selection.

Manu Sporny: And then it kind of proceeds from there. go ahead, Ch.

Joe Andrieu: Yeah, I just thought in this diagram you might want to tease
out that this is the go to website protocol that was selected here this is
not necessarily an NFC flow or…

Joe Andrieu: an open ID flow.

Manu Sporny: Yeah, that's a good point. I don't know if I'm spe Yeah,
that's here is where it is very much a good website selection. Yeah, good
point, Joe. I'll make sure to update the PR with that. And if you don't
mind,…

Manu Sporny: Joe, making a comment if you have it up just so I don't
forget. go ahead, Dave.

Dave Longley: Yeah, I was going to make the same comment.

Dave Longley: And in addition to that we might want to so this approach is
also what is used for just presenting credentials on the web except it's
the coordinator that goes and talks to its own system to produce the
interaction that creates a QR code that a digital wallet can scan. And so
I'm not sure which one of these should come first. to me it seems like the
case with the verifier should come first because it's more commonly used
today.

Dave Longley: Of course, doing this might become commonly used as well in
the future, but we should definitely capture that because this entire thing
is used both to get a message an start an interaction with a digital wallet…

Dave Longley: where it starts on a coordinator website and it is used in
the reverse. And so we should definitely have both and talk about both and
how it works in both directions. I think it should go in this PR and…

Manu Sporny: Plus one to that.

Manu Sporny: That go in this or should it go in a separate one?

Dave Longley: this is debatable like I was saying but I feel like that's
the first most obvious example for at least people familiar with this
ecosystem today would be seeing…

Dave Longley: if I go to a coordinator website I'll click some button it
will generate this interaction URL for my wallet. to scan and then that's
the most common interaction that's already happening on websites today.
Yeah.

Manu Sporny: All right.

Manu Sporny: Do you mind just putting a comment just to track that as well?
go ahead, Eric.

Eric Schuh: Yeah, so I guess my comment is kind of more 10,000 foot level.
but really this interaction mechanism and…

Manu Sporny: Mhm.

Eric Schuh: the selection of the interaction protocol in some ways doesn't
have anything explicitly to do with VCs or VPs, right? You could have any
given piece of software generate the initiating QR code or URL and pass it
to any other software on any other system in whatever way it wants. so I
guess my question is more broad of this obviously is one place that this
could be specified, but is this the place it should be?

Eric Schuh: Or is there a plan in the future to try to generalize this a
little bit more?
00:20:00

Eric Schuh: Because I feels a little bit strange to have this connected to
the VC API directly to me.

Manu Sporny: Yep. Yes,…

Manu Sporny: that's a good question. I couldn't figure out where to put
this. I was like, " we put it in the VP request spec." And does it really
belong there because we've got some protocoly bits we need to call out and
it does, concretely we want to at least point to a protocol that's using
it. that's VC API, Could we put in the VC spec? No. Could we, put it? so I
went through all the other specs and this is the best one I could find.
Other than making it a total standalone spec, at which point I'm kind of
like, I don't know if that people are going to buy into that because then
the argument might be like, let's not put it in the VCWG e either. Let you
know, it needs to go into its own working group.

Manu Sporny: So those things were going on in the back of my mind Eric as I
was kind of putting it together so I was like let's start with a very
concrete use case right in a concrete flow and one that's very specific to
VC API and in the future if people want to generalize it beyond here which
I totally agree with you it is a very general solution then we can pull it
out into its own spec kind of like,…

Manu Sporny: the multibase and multiash stuff really don't belong in the
controlled identifier spec. They should be out in their own specs, but for
whatever reason, we had to put it somewhere to get the first version of it
out there and have people using it and then insist that it's a standalone
thing. hope that helps.

Eric Schuh: Yeah, I think it's an okay spot to start.

Eric Schuh: So, thumbs up to that path. just wanted to share that and…

Eric Schuh: make sure it was recognized that this could be easily
generalized beyond VC API and VCs in general.

Manu Sporny: Yeah. …

Manu Sporny: so how about this? We should definitely, but I don't think the
current PR says that explicitly. We should add a note to say that
explicitly. plus one to that. Would you mind kind of adding a comment to do
that?

Eric Schuh: Yeah, I can do that.

Manu Sporny: Thank Patrick, you're up next.

Patrick St-Louis: Maybe I can just add an argument why I think this al
might be a good place for it is that the VC API spec sort of describes all
these different coordinator services and so on and this is pretty important
for these interactions. if you have the protocol in the same specification
that describes the different components it's less back and…

Patrick St-Louis: forth. you can reference them directly.

Manu Sporny: Yep. Less one.

Manu Sporny: I think that's a good argument for putting it in here. all
right.

Patrick St-Louis: I had another question. So I see here it says Wap_ API
and in the PR there was a discussion about IUV. is there a relationship
between these two parameters?

Manu Sporny: This is a typo. so there's another working group that's
working on this thing using it. that's at the Kexus standards setting body.

Patrick St-Louis: Okay.

Manu Sporny: they do global standards for the retail sector and it's the
wallet interaction working group. And so this was this meant wallet
interaction API, but as I was, and Eric's the lead editor for that
specification over there, Eric Shu, that's on this call. and as I was
typing this out, the exact same thing that Eric mentioned, popped into my
head where I'm like, it's not a wallet. it's an lication. Any application
can really use this. And so, Eric, I was kind of like, we need to rename
this, right?

Manu Sporny: And so the new thing I was suggesting is the interaction URL
version IUV totally not committed to that in any way shape or form. If we
come up with a different thing that would be good. it probably needs to be
short because the length of this URL determines the length of the QR code
and that sort of…

Patrick St-Louis: any reason why not just VC API?

Manu Sporny: because it's not specific to VC API.

Patrick St-Louis: Okay.

Manu Sporny: It's agnostic of it,…

Patrick St-Louis: Which comes back to the discussion like the point that
Eric raised…

Manu Sporny: right? That's right.

Patrick St-Louis: if that's the right place that they should

Manu Sporny: Yep. go ahead, Eric.

Eric Schuh: Yeah, I will just call out that when we were doing this for the
Kexus retail specification,…

Eric Schuh: the reason that a version number was included at all was
specifically because the point of sale vendors and the people that make the
point of sales software wanted a quick and easy way to disambiguate this
URL from other ones. I'm not sure that in this general specification we
have that same requirement. and I know that there were thoughts that
there's not really a need to have a version in this L. if you understand
the interactions kind of nomenclature. so I'm not sure that the version is
actually needed here outside of the retail context.
00:25:00

Patrick St-Louis: Yeah, for me as long as there is a query parameter to
signal what I should do with this that's my use case. for example, if I
have a device that's going to scan a QR code and that code, I know it's
designed to start a credential exchange interaction, but it might be A
short DICOM invitation, which is just a URL.

Patrick St-Louis: It might be a protocol exchange like this. and for
example, a didcom short URL is going to have a very specific query
parameter that I can look for to kind of know before I interact with the
URL what to expect. So, from my point of view, what's useful in here for me
right now, it's not so much the equal one, but it's more the query
parameter that I can sort of look for when I scan a URL.

Manu Sporny: So agreed with that. I think we do need something in the URL.
if we imagine a world that has 20 different types of QR codes that your app
might scan, some of them might be just G10 identifier. So GS1 has a
standard where it's a specific type of QR code that is a URL but it points
to a product versus one that initiates a didcom thing versus one that
initiates this interaction protocol thing versus something else.

Manu Sporny: If we have multiple URLs, we are in a position where we can't
tell the difference between them and we don't know what to bootstrap into.
So, while it's not perfect, it at least gives you some signal, something to
look for that helps your, scanner code determine what logic path to
execute, so, and I do think we need a version because what you end up doing
in version one might not be the same thing that you do in version two. for
all those reasons, I think, we need at least this thing. and I think later,
Eric, I'm debating whether or not we want to be specific about this
interactions path thing.

Manu Sporny: So, that's the interaction At a high level, in this version, I
didn't make slash interactions a requirement. I made that, it's in the
example, but it's not a requirement here. So, that's another way that we
kind of deviate from the retail spec here. Interested in kind of, thoughts
around that. the other language I tried to put in here is that it should be
an HTTPS URL without mandating that it has to meaning there may be another
type of peer-to-peer domain-based wireless protocol that comes out in the
future that we want to use.

Manu Sporny: the Wi-Fi aware stuff, comes to mind where we don't
necessarily want to mandate that it's an HTTPS URL. We're saying it should
be because we know how to deal with that today, but I'm concerned about,
painting us into a corner too early. Go ahead, Dave.

Dave Longley: we should provide some rationale around why HTTPS is here and
it's not just because it exists but because of those trust signals that I
was mentioning and how it enables delegation you can retrieve this from an
origin and that origin can delegate to some other service that provides the
protocol and interaction or exchange and whatever system needs to do
whatever it needs to do and that delegation is really important because you
can
00:30:00

Dave Longley: you talk to the origin of trust over a secure channel like
TLS to retrieve from that origin where that origin has delegated service
providers and so you don't need to have the service provider sort of leak
details of the abstraction around we're going to the way that these other
protocols work is they have the service provider register like a
cryptographic

Dave Longley: key at some location at the origin and then you have a
protocol around fetching that and checking all this additional trust stuff
that is not necessary because of the use of HTTPS and this delegation and
so we should mention that in this section and if you're not going to use
HTTPS that should all be considered in whatever it is you do use whether or…

Dave Longley: not you're going to continue to get those features or not.
Yeah.

Manu Sporny: Yeah, plus one to that.

Manu Sporny: Could you add that please as a comment just to keep a running
set of modifications? Thank you. Patrick, you did have your hand up, but
then you lowered it.

Patrick St-Louis: Yeah I was just going to say this could be defined by
future version might support other protocols…

Patrick St-Louis: but decided not might as well just make

Manu Sporny: Yeah, I mean that's an argument for us to just make this into
a must in version one URLs must be HTTPS.

Manu Sporny: I'd like to keep it a little loose for now. I don't think
we're hurting anything by not making this a must.

Manu Sporny: and then if it ends up that it's causing us more pain than
it's worth in the future, we can always crank it down to be a must. and
tighten it up. All right. So, adding that thing that, Dave mentioned to
this section here. The QR code format is just standard. it follows ISO
1804, which is the code format. we say a couple of things like don't make
it larger than 400 alpha numeric characters the URL because then the QR
code gets so big it starts becoming hard to read there's an upper limit on
QR code URL size it's four hopefully no one's going to do a 4,000 character
plus QR code but you could do it so that's why we're saying it must not is
just kind

Manu Sporny: for repeating a normative requirement in 1804. the is just for
usability reasons. and then you should be as short as possible ideally
because that'll make the QR code easier to read. And so this URL encoded in
QR code format. It's not very dense at all which is good. Means it can be
scanned fairly easily and readily. So what happens when you do a get on
this URL? You get back a protocols object which looks like this. So it's
literally a JSON object. It has a field in it called a property called
protocols. And then you have the protocol name and the URL associated with
the protocol name, URL associated with the protocol.

Manu Sporny: And you could have didcom, you could have Bluetooth, you could
have a variety of other things listed in here. go ahead, Patrick. Yeah.

Patrick St-Louis: for these website vapi ID for VP. Is there going to be an
official registry or how would that play out? Yeah. Yeah.

Manu Sporny: Yeah, it's a good question. There's probably a registry of
some kind. I mean, those of us that have had to manage registries don't
like having to manage registries. but yeah, I mean, I think what's on the
left here, just don't stomp on anyone else. Hopefully, they're not more
than a handful of protocols, 10 or 15, right? and I don't know if we really
need to police this space.

Manu Sporny: so yeah I think the answer to your question Patrick is
there'll be registry go ahead Eric

Patrick St-Louis: Yeah. I mean, it's always good that software would
recognize the same properties.

Eric Schuh: Yeah, just to share…

Eric Schuh: what we're doing in the retail standard for this. the retail
standard specifies that the website protocol which is literally just
redirect the initiator to a website is a must for support. so that there is
one common protocol in the retail space that is expected that should work
every time. and then everything else is left as possible extensions.
00:35:00

Eric Schuh: So if the wallet advertises something that's not website and…

Eric Schuh: the retailer understands it, then feel free to go ahead. so I
think in that space we were not expecting to have a registry, but W3C is
probably more appropriate for some registry type of thing if desired.

Manu Sporny: Yeah, that's a good point,…

Manu Sporny: I said the website protocol is a must, but we should probably
do that here, too. I don't see any reason why to because that's kind of
like the bare minimum implementation, right? so yeah, Eric, do you mind
adding it some?

Dave Longley: I was trying to follow that.

Manu Sporny: Dave,…

Dave Longley: You're saying you have to always include a website in the
protocols because I don't think that's required.

Manu Sporny: no. Your implementation must always support the website
protocol at least.

Dave Longley: I don't know why that would need to be the case.

Manu Sporny: though read the consumer has to at least support the go to
website thing the Google objection on you don't

Dave Longley: And when you say your implementation, you mean the piece of
software that's generating this list of protocols. Are you talking about
the consumer of the protocols? we could do that. I don't see why that's
necessary. …

Manu Sporny: have a single thing implemented here. It's a meta thing and
you can't.

Dave Longley:

Dave Longley: it's in the VC back. I would think that since it's in the VC
API protocol would be implemented and show up in test suites. the reason
why I'm hesitant here is because there already are existing implementations
that use all this and the one thing they don't use is website.

Manu Sporny: So, we should come back to that.

Manu Sporny: Patrick, you're on the queue.

Patrick St-Louis: Can I just ask what's website?

Patrick St-Louis: What's is just return to HTTP website? it returns a HTML
file and…

Manu Sporny: Yeah, it's No.

Patrick St-Louis: you render it.

Manu Sporny: So let's say you have a digital wallet, Patrick, and…

Patrick St-Louis: Yeah. Yeah. Yeah.

Manu Sporny: then let's say I'm a point of sales system. you're in a store,
you're buying something. I'm a point of sales system.

Manu Sporny: on your app. You click, generate You show it to me, the point
of sale. I read it. I go out and…

Patrick St-Louis: Okay. Right. Okay,

Manu Sporny: get the list of protocols from your wallet. Your wallet says,
I support the website protocol thing. And what that means is as the point
of sale, I can tell your wallet, I want you to redirect Patrick to my
retailer website. So I will push my website to your wallet under the
website protocol. I'll tell your wallet, send Patrick here. Your wallet
will pop up a consent screen. So you'll see, do you want to go to little co
retailer?

Manu Sporny: If you click yes in your wallet, your web browser will open
up. You'll go to the little website and then you'll see my retailer site
and it could be something like a checkout like a basket like what's in your
basket and…

Manu Sporny: what are you buying that kind of stuff something transaction
specific. Did that make sense? say that again.

Patrick St-Louis: Yeah, I think so.

Patrick St-Louis: I think so. Yeah, be nice to see it in action. so the
wallet generates that website URL and then the vendor sends another website
to that URL and the wallet redirects.

Manu Sporny: I think the answer is yes.

Manu Sporny: Yes. Yep.

Patrick St-Louis: So the value here https app example redirects z8 that's
the wallet that generates this in the scenario I just explained and…

Patrick St-Louis: then whoever is scanning the QR code is going to look at
this it's going to send a post request to that endpoint with the actual
website he wants the wallet to redirect to.

Manu Sporny: Exactly right.

Patrick St-Louis: Okay, perfect.

Manu Sporny: Yep. Good.

Dave Longley: Yeah, this is almost an inbox for URLs that you can to go to.
It's like the wallet would create an inbox and…

Dave Longley: say here's the inbox and the only kind of messages I accept
are URLs that tell me to redirect somewhere.

Patrick St-Louis: Is there somewhere like a specification?

Manu Sporny: Yeah. Yeah.

Patrick St-Louis: Is there somewhere? Okay, it should be in there in this
PR.

Dave Longley: Yeah, that's in this PR.

Patrick St-Louis: Perfect. Okay. Okay.

Manu Sporny: So, example three shows you what the point of sale, would post
to your wallet, Patrick. So,…

Patrick St-Louis: Tell your user,…

Manu Sporny: I'd say this is the URL I want you to go to.

Manu Sporny: This is what I want you to show the individual if the wallet's
okay with doing that. There's usability issues there about tricking the
person on go to your government's website,…
00:40:00

Patrick St-Louis: right? Yeah. Just spoofing and…

Manu Sporny: right? Yeah,…

Patrick St-Louis: Yeah. Yeah.

Manu Sporny: and then the reference ID for debugging purposes if you know
whatever.

Patrick St-Louis: Or compact tanking supports, whatever.

Manu Sporny: Yep. go ahead Coyote. Yes. Yeah.

Kayode Ezike: Yeah. have you considered use cases for wallets out there
that don't have a back end for the website generation piece?

Manu Sporny: And that becomes a lot more involved I think we can do this
over Bluetooth right where one of the protocols is Bluetooth and it tells
you how to connect to the local app phone over Bluetooth including password
just the encryption strings and all that kind of stuff and then the local
point of sale could connect over Bluetooth and then you could have a big
exchange just purely over It is Mhm.

Kayode Ezike: Yeah, I only mentioned it to go back to the point around if
we make that field required then you would just pretty much block out those
use cases.

Manu Sporny: Yep. that's a good point. which field required

Kayode Ezike: The website if the wallet needs to be able to generate a

Dave Longley: Yeah,…

Dave Longley: sorry to jump Q real quick, but It's just that the protocols
would be transmitted over Bluetooth and we're not covering that. this
message that's on the screen is something that's returned through HTTPS.
and that wouldn't even be the case for the interaction URL that the wallet
would provide would include some kind of Bluetooth information in the URL.
And then the recipient would contact the wallet over Bluetooth and receive
this message. and it's an open question as to whether or not you could
respond to the website I don't know if that website URL that's there on the
screen could then also have a Bluetooth descript description at the end
where you could send the website there's ways that could still work.

Manu Sporny: Yeah, like HTTP over Bluetooth.

Kayode Ezike: Okay. Thanks,

Manu Sporny: And I mean, it's a good question, Coyote. I think I tried to
stay away from those more advanced use cases to try and get the base PR in
before we started kind of adding those more advanced things on top.

Manu Sporny: But yeah, plus one. good question. Go ahead, Eric.

Eric Schuh: Yeah, I think I'll just add that in the retail specification,…

Eric Schuh: we're requiring the website for the first version of the retail
spec. I think in the future it's entirely expected to, converge to what
we're looking at more here in the W3C. but the reason that the website was
a must in the retail specification was because of expectations around
technology that retailers have. most of them understand how to set up
websites. whereas there's a lot more work to support other local
connections that to so in the future I would expect that that for the
website even in the retail specification should go away.

Eric Schuh: It was just some decisions that were made to get things working
sooner.

Manu Sporny: Plus one to that.

Manu Sporny: Go ahead, Dave.

Dave Longley: Yeah, real quick. I feel like I'm still jumping. Patrick, I
also just wanted to mention because Coyote mentioned what if the wallet
doesn't have a backend. The service that that could receive those websites
could also just be an independent service that could work with a number of
wallets that don't have backends and it could push messaging or whatever it
needs to use. So, you could independently implement this piece and…

Dave Longley: have and have it work with a variety of different wallets
that don't have backends, as you

Kayode Ezike: External state.

Manu Sporny: All right.

Manu Sporny: Patrick Yeah.

Patrick St-Louis: Yeah, just so I'm wondering so this seems to be a
requirement like that's very industry specific isn't there a reason…

Patrick St-Louis: why it couldn't just be a requirement for that specific
industry and not be part of the general specification here.

Manu Sporny: You mean the go to website thing?

Patrick St-Louis: other requirements about what you need to support this
specific thing. okay.

Manu Sporny: Right. Yeah. I think where we're landing is, Patrick, is not
saying you need to support it. I think we're just going to define it and
say, "Hey, these are the options. Use whichever ones you want to."

Manu Sporny: and fundamentally both sides need to pick a protocol at some
point right and if they don't have any protocols in common that they speak
then they just won't be able to communicate in and that's fine as a failure
scenario right s just they don't speak any of the same languages the end
and it's detectable when that happens okay we talked a bit about the
website interaction protocol. This is literally all it is. It's just the
remote system sends the website it wants you to go to and you either go to
it or you don't. That's it. The VC API interaction protocol is just an
exchange. it's participating in an exchange.
00:45:00

Manu Sporny: the remote system will post a VPR to the system, if it selects
VC API here, the very first message that the remote system will send is a
BPR, And that's it. and then the rest of it is just section 3114 which is
already in here which is how do you participate in an exchange okay that's
basically it in its entirety. I know we're running out of time so we're
probably not going to be able to get to everyone's comments but let me go
ahead and reset.

Manu Sporny: I wanted to Coyote, you had a good comment in here, and I
can't see it. you had multiple,…

Manu Sporny: but there was one specifically I wanted to talk about.

Kayode Ezike: I know that I reviewed it.

Kayode Ezike: I don't recall if I had a com I had a comment in the render
method one recently. Maybe that's what it was up with.

Manu Sporny: I'm getting confused. Yep, never mind.

Kayode Ezike: Yeah. Yeah.

Manu Sporny: That was the other one. All right. So, Let's go down from the
top here. let's see. I think we covered this today. Yes. So, you added
that. Thanks, Dave. I'll try to make a iteration on that. I'll follow this
up, Ted.

Manu Sporny: comment. Okay. Yeah, that's a good change. Never that should
go rationale for PS. Good. We discussed that today. you're saying Okay.

Dave Longley: I'm just noting there might be no hyphen in existing
implementations. We should check

Manu Sporny: All Eric, the other thing that I did here is I took away all
the capitalization. others feel differently. I think we should just
lowerase everything and then maybe replace.

Dave Longley: My only consideration is existing implementations there. I
know that it might be that OID for VP had capitals. I don't remember.

Manu Sporny: Okay. Yeah. Yeah. Okay. Okay. That's fine.

Manu Sporny: For VC API lowercase, no hyphen. Is that what we're saying?
Potentially. Okay.

Dave Longley: I think that's what it is, but we should just double check
and match existing implementations. I don't see a reason to Switch it.

Manu Sporny: And seeing the plus one from Joe. I made an attempt at
addressing this, Dave, but I think some of the stuff we talked about today
might cover this. the trust signals one. Okay, I did write something around
this. I didn't do the trust signals one, but that's noted above. this is
the trust signals one as well. and this is kind of a trust signals one. So,
I'll try to take all this into account when I write that other PR.

Manu Sporny: acknowledged on that change. Yeah, that's fine. We can modify
that. I think this was just a copy paste out of the VP request spec. Okay,
I think those are all the comments. So, it sounds like we need a couple
more changes to the overall. Does anyone have any heartburn over the PR and
kind of mentioning this in the specification? I know we already talked
about that, but now that we're at the end of the discussion, any particular
concerns about the Go ahead, Coyote.

Kayode Ezike: First of all, thank you for this. I mean, I think it seems to
me like there's going to be the need regardless for Wallace to have to
understand multiple different types of these drug codes. And that's just I
think this kind of going to be hard to get around that. But at the very
least, if there's going to be the ability to understand specific paths and
patterns that we can know how to handle is useful. And so wherever that can
be done, that's great. I think one thing that I'm desiring I like that
there was the content negotiations to enable wallets to be able to do the
automated exchanges.
00:50:00

Kayode Ezike: I think one thing that I'm thinking is how from the
standpoint of the verifier when they actually stand up to these interaction
sites actually designing it in a way that is consumable and that makes
sense for the users to be able to know okay which of these should I select
right and so that's the open question that I'm trying to get around and
maybe part of the solution to that is giving guidance on what those site
could look like but then there's also a desire to be able to handle the
case where and maybe still thinking, maybe not, but if you're just using
the basic camera app for example, QR code scanner at the moment, it's going
to default to getting you to that whatever that interaction site would look
like, which gives you all the different options, which is, great.

Kayode Ezike: I'm wondering if there's a way to enable the ability to
default or to let's say that eventually the camera apps start to recognize
this particular specification and they say okay this is something we want
to actually include if there's a way to enable that sort of ability to
either default to a set of options or just to one particular option that
the user has decided that they wanted to go with. Complexity there would be
obviously that multiple apps can support multiple different protocols. But
you're just thinking out loud as how could that potential use case be
served where basically just going with the camera app are able to handle
some of these use cases to make it more convenient for the wallet holder.

Kayode Ezike: So, I said a few things there, but does that kind of make
sense when I'm

Manu Sporny: Yeah, I certainly understand.

Manu Sporny: Yeah. what the questions are. good questions. Dave, you're on
the queue.

Dave Longley: Yeah, you might have been about to speak to this. It's on the
screen there. One part of the mitigation for this is if the camera apps
used, it's going to fetch the site using text HTML on a browser and that
site must render what's going on for the user. I also wanted to make the
comment that I don't expect users to be making protocol selections, but
their software should be able to do so. and the other comment is if you're
on a device and you scan you in using the regular camera app and you go to
a web page like that web page could then also potentially present you with
something like a DC API button or something else that would keep you on the
same device to continue the interaction from that place.

Dave Longley: And if you choose VC API or the interaction protocol through
DC API or Chappie for example, you can get this whole protocol calls object
sent to your wallet and then the wallet can then make a choice for the
protocol to use from there. So all of those things should integrate nicely.

Dave Longley: We do have some places to handle these sort of edge cases if
people end up you know doing what you were saying.

Manu Sporny: All right.

Kayode Ezike: really cool.

Kayode Ezike: Thank you.

Manu Sporny: And then we're out of time, so we'll continue that discussion
next week. I'll try to get this PR updated with all the input that we have
from the call today. and then we'll go over it again next week to make sure
folks are okay with it before we merge okay, that's it for the call today.
Thank you everyone for the great discussion as always. we will meet again
next week and keep going through PRs. I think we just had a new one opened
my co coyote.

Manu Sporny: So, we'll take a look at that next week as well. Thanks,
Coyote for opening that's it for the call this week. We'll see you again
next week. have a wonderful rest of your day. Take care. Bye.

Parth Bhatt: Thank you.
Meeting ended after 00:54:47 👋

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