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

[David Waite]

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> 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
> 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/20230830/d0e3cf3c/attachment.html>