Use a URI Schema instead of new format for "VP1-"

[vitorpamplona]

I want to suggest turning the "VP1-" prefix into a URI schema type ("VP1:"). You should use a colon, not a dash to represent your payload type. 99% of the QR codes out there are URI, it would be nice if the team could follow the same practice. It makes the life of a verifier much easier.

I would also recommend changing from "VP:" to something like "CBOR32:", because the URI Schema of your payload structure should not be about the JSON or the data in it, but about the minimization procedures used to fit a bigger object into the QR. By knowing that a QR data is CBOR-LD, a verifier can follow the instructions defined by the schema, uncompress the QR to the JSON and then see that it is a Verifiable Presentation.

In that way, you don't need a version number in the schema type for every Verifiable Presentation out there. You can evolve the Presentation specification as you wish without changing the minimization technique and the URI schema type.

This will fit well with other modes VC minimization, such as:

• Consensas' JSONXT (JXT:)
• PathCheck's PaperCreds (CRED:)
• SmartHealth Cards (SHC:)

[dlongley]

So using a URI scheme was the first thing we tried doing and it created a number of failures in real world tests with QR code scanners. We'll also want to document potential security issues with taking that approach. @dmitrizagidulin can you speak more to this? We'll want to mention the design choice in the README or an explainer somewhere as well.

[dlongley]

There were also security considerations, including a threat where applications could register for the URI scheme and immediately, upon scan, gain access to sensitive VCs that they should not have access to (e.g., see link hijacking). We should document these threats as well.

[vitorpamplona]

That's interesting. I have not seen issues with URIs yet. Do you remember what was the problem? I am happy to dive deep into this since it could affect us as well.

Schema registration should be a feature, not a bug. Apps should be able to register to load all types of VCs on their wallets. At least for those of us working with Serverless VCs ecosystems, it makes a lot of sense.

[dlongley]

That's interesting. I have not seen issues with URIs yet. Do you remember what was the problem? I am happy to dive deep into this since it could affect us as well.

I don't -- I know it was an issue on iphones. We'll need to document it.

Schema registration should be a feature, not a bug. Apps should be able to register to load all types of VCs on their wallets. At least for those of us working with Serverless VCs ecosystems, it makes a lot of sense.

Yes, it would be nice if it were only a feature, but it is also a potential threat. Any application can register for the scheme -- and then receive what should have been a confidential VP. Just imagine an evil Android application that a typical user installs and it registers for the "VP:" scheme. Even if the OS presents a prompt for the registration the user is unlikely to understand it and click through to allow registration.

Then, when the user later scans a VP during a confidential interaction, the evil app steals it. If no scheme is used, this attack is not possible. The user must instead start a trusted application (e.g., their wallet app) that uses an appropriate scanning API to perform the scan, ensuring confidentiality.

[vitorpamplona]

Applications can also register for HTTP and HTTPS calls, take control over the browser and see everything the user sees. If the user's phone has an evil app, it's not the automated schema loader that will prevent the app from seeing the VP.

[dlongley]

Applications can also register for HTTP and HTTPS calls, take control over the browser and see everything the user sees. If the user's phone has an evil app, it's not the automated schema loader that will prevent the app from seeing the VP.

I could interpret the above comment at least a couple of different ways.

If the premise is that it is impossible to protect the security and privacy of the user from evil applications, I would reject it. If this premise were true, it would signal that the entire permissions/capabilities model provided on Android and iOS (and other OSes) is a futile effort. Rather, these models are intended to help the user only give applications the capabilities that they need -- and such capabilities should be narrowly targeted to avoid granting more authority than the user can reasonably understand. Some applications will be granted significantly more authority by users -- but this is generally because they are more trusted.

I don't believe that (at least at the time of writing this) users understand URL scheme registrations very well -- and they may not even be prompted when applications register. This is ok for many use cases as the URLs do not carry sensitive data. I expect the opposite to be true for most Verifiable Presentations. We should carefully consider this.

Another way I could interpret your comment was to think of it as an argument that could be potentially rewritten as "If it is possible for an evil application to use X to gain access it should not have, then we should not care whether it can use Y to do the same". In this case, I can't agree that the conclusion follows. We should be closing whatever security holes we can, not leaving them open because others exist -- whether or not they may enable similar exploits.

I'm sorry if both of these interpretations are significantly off from what you intended.

[vitorpamplona]

What I was saying is that the security delta between VP1- and VP1: for evil apps exist, but it is irrelevant compared to the User Experience gains for good apps. If you are making an evil app to capture all VPs, it's definitely not the schema that will stop you or will slow you down. It's a little harder for sure, but the "little" is trully little. And for that added, I'd even called it, "fake" sense of security, you block good apps from developing excellent user experiences.

Let the OS solve the schema grab permissions, consent, and disclosure needs for this.

[dlongley]

I think we should look into what's been written regarding security considerations around similar use cases, such as otpauth: -- links containing 2FA secrets, etc. hopefully there's some good advice/prior experience we can learn from in that area.

[vitorpamplona]

Makes sense. I don't know if you have shipped an app that grabs a scheme before, but it's not as easy as just adding the String on your Manifest. You have to go through approvals from Apple, Google, and Microsoft and, if you use Windows, be an Administrator to register the URI grab. Both Apple and Google are refining their Permission systems to include URI grabs as well.

[dmitrizagidulin]

@vitorpamplona - So, what @dlongley is referring to there is -- both Apple and Android are trying to move developers away custom protocol handlers (and towards universal links). See for example https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app

"While custom URL schemes are an acceptable form of deep linking, universal links are strongly recommended."

That's corporate speak for "please don't use those, but we don't want to panic existing developers, and we want to be backwards-compatible." :)

[vitorpamplona]

@dmitrizagidulin agree. They might end up rejecting all URI grabbing applications. Hopefully, after they figure out how to correctly disclose and build a permissions architecture around it, URI grabbing comes back.

[vitorpamplona]

Of course, Apple blocking custom protocol handlers doesn't mean that the QR code spec should not use it.

[dmitrizagidulin]

Of course, Apple blocking custom protocol handlers doesn't mean that the QR code spec should not use it.

I dunno, I'd honestly be reluctant to use it, as an implementer. And it's not just Apple - Google has the same recommendation.

[vitorpamplona]

Reading or Generating QRs with custom URIs does not trigger Apple and Google's review. In fact, by itself, it has nothing to do with URI grabbing. I don't understand the hesitancy here.

[dmitrizagidulin]

@vitorpamplona reading or generating QRs - no. But developing apps that register custom protocols, that's the questionable part.

[msporny]

@vitorpamplona wrote:

Of course, Apple blocking custom protocol handlers doesn't mean that the QR code spec should not use it.

No, that's exactly what it means -- Apple is blocking custom protocol handlers because they're dangerous.

Others are expected to follow suit. It's only when custom protocol handlers are supported by everyone in the ecosystem that we would consider changing the behavior.

One of these approaches is clearly safer than the other... if we depend on scheme handlers, there are very clearly attacks that one can perform on individuals (as described above). If we don't, that attack surface is eliminated and you have to scan a QR code using an app that you have opened and placed into that mode (which isn't a terrible experience).

Also keep in mind that we can always upgrade the QR Code format later to use a scheme handler... it's just at this point in time, it's not safe to do so.

I suggest we use this issue to document these positions more clearly...

[vitorpamplona]

No, that's exactly what it means -- Apple is blocking custom protocol handlers because they're dangerous.

I am talking to them. That's not what they say. They are not blocking the use of custom URIs (otherwise all DIDs would go caput). They are simply taking a good look of the URI grab from apps, which is perfect for us. We can use whatever we want in the QR.

Also keep in mind that we can always upgrade the QR Code format later to use a scheme handler... it's just at this point in time, it's not safe to do so.

Keep in mind we are talking about printed credentials and not easily renewable digital ones. These QRs will last forever. Just ask Divoc's 145 million RSA-based Verifiable QR codes shipped in India. They not only cannot be changed but It's expected these QR codes to show up in the next 50 YEARS. All verifiers need to support this older/inadequate version of the protocol and signature.

[msporny]

I am talking to them. That's not what they say.

Great, please get them to comment on this thread. We want to do the right thing here. If you have access to the Android team, please get them to comment as well.

Keep in mind we are talking about printed credentials and not easily renewable digital ones. These QRs will last forever... All verifiers need to support this older/inadequate version of the protocol and signature.

Which is exactly why we want to get this right, and in order to do that, we need to fully document the current thinking from the security teams working on Apple and Android core libraries that will be reading QR Codes.

Since you have access to them, please get them to communicate their intention wrt. best practices with QR Codes -- URI-based or clear-text based... (or does it matter, will they sniff all QRCodes and base the reaction on a byte header?).

[vitorpamplona]

I have been trying to get them to say something for 9 months :) As you probably know, they don't even reply on their own forums.

But as you can find online, all of their current public policies only relate to URI registrations by applications that are shipped through Apple and PlayStores. That's where the security is high. On the app review process, not to read a custom URI QR, but to grab the URI from the browser/camera. Everything else has no policy. You can use URI registration in any downloaded app for macs and there is no restriction on the use of custom URIs on QR codes, JSONs or app databases.

[vitorpamplona]

FYI, we are suggesting the use of "CBLD:" as a URI schema for any CBOR-LD on Base32 object.

The reason to not go with VP1- is simply because the schema should describe how to unpack the rest of the URI, not its content. For the unpacker/verifier, it doesn't matter if the payload is a Presentation, a Credential, or any other LD object; And knowing it just increases the amount of "ifs" in the code to process multiple content types in the same app.

Instead of doing this:

• VP1 for Presentations
• VC1 for Credentials
• etc...

One can simply use CBLD: for all of them, unpack to the JSON and then figure out what this object is by looking at the type.

Simpler, better.

You can see a live demo here: https://github.pathcheck.org/eu.dgc.html

[vitorpamplona]

You might have seen it already, but Apple's implementation is out: https://developer.apple.com/videos/play/wwdc2021/10089/

Importing "SHC:" URIs into the Health App from the main Camera App