- From: <meetings@w3c-ccg.org>
- Date: Tue, 15 Apr 2025 22:14:24 +0000
- To: public-credentials@w3.org
- Message-ID: <CA+ChqYd6CCmS6WV1hJDmyXZezrpR57fUC6d8x_FZMBdU_489OA@mail.gmail.com>
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.*
Received on Tuesday, 15 April 2025 22:14:34 UTC