[Openid-specs-ab] OpenID for Verifiable Presentations over BLE - draft 00 ready for review

Thu Aug 31 08:11:21 UTC 2023

Hi David,

I am not sure whether I got your last paragraph correctly, but I suggested to include a commitment to the BLE channel in the signed request: openid / connect / issues / #1997 - [OpenID4VP over BLE] Active MITM can violate injective agreement — Bitbucket <https://bitbucket.org/openid/connect/issues/1997/openid4vp-over-ble-active-mitm-can-violate> 

This way, the client could detect that there is a MITM by noticing that “h(BLE keys in request) != h(BLE keys used)”.

Best,

Felix

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of David Waite via Openid-specs-ab
Sent: Wednesday, August 30, 2023 11:50 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: David Waite <david at alkaline-solutions.com>
Subject: Re: [Openid-specs-ab] OpenID for Verifiable Presentations over BLE - draft 00 ready for review

Hello Tom,

The current text is unclear, but my _assumption_ is that you establish an unauthenticated (anonymous) channel between the two parties (wallet and verifier), then send OpenID4VP messaging over it.

Setting up such a channel could presumably be done entirely through ephemeral mechanisms, with no information leakage - although it appears there is some information in the “Identify Request” today that may be sensitive, marked up with notes.

The QR code is a mechanism to bootstrap creation of that channel. If the channel is unauthenticated, signing the contents in the QR code for integrity protection won’t really help - you don’t know what would make a signature identify a legitimate verifier. It also wouldn’t help the case where the user starts their wallet directly rather than by scanning the QR code.

The trend is for the initiation of the channel to be unauthenticated because wireless advertisements are very low bandwidth - e.g. the BLE advertising data and scan response together are only 62 bytes, and some of those bytes are reserved. 

You can exchange integrity protected (authenticated) information over such a channel. We’ve done this for ages, because redirection via URLs are also not an authenticated channel - those URL could have been created/modified by anyone. This is why there are specs like JAR to sign the requests, why there are restrictions to where responses are sent, and why there are verification steps to make sure the answers you got were to the questions you asked.

The piece I haven’t seen so far is how to bind the request/response to the negotiated channel, to prevent a MITM from seeing the successful responses to a legitimate verifier’s request. One heavily-used mechanism for this today is the restriction of allowed redirect_uri, not so useful over a wireless channel.

-DW

On Aug 30, 2023, at 11:41 AM, Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> > wrote:

The QR code should be signed JSON see spec for shc

thx ..Tom (mobile)

On Wed, Aug 30, 2023, 10:24 AM <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net> > wrote:

Torsten.

Am 23. Aug. 2023, 10:23 +0200 schrieb Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> >:

I am 100% with you on this. Random QR code scanning is equivalent to clicking a URL from an unknown sender.

What options exist to secure the QR code scanning?

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net> 
https://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230831/44b23185/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5719 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230831/44b23185/attachment-0001.p7s>