<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi David,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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: <a href="https://bitbucket.org/openid/connect/issues/1997/openid4vp-over-ble-active-mitm-can-violate">openid / connect / issues / #1997 - [OpenID4VP over BLE] Active MITM can violate injective agreement — Bitbucket</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This way, the client could detect that there is a MITM by noticing that “h(BLE keys in request) != h(BLE keys used)”.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Best,<o:p></o:p></p><p class=MsoNormal>Felix<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> <b>On Behalf Of </b>David Waite via Openid-specs-ab<br><b>Sent:</b> Wednesday, August 30, 2023 11:50 PM<br><b>To:</b> Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br><b>Cc:</b> David Waite <david@alkaline-solutions.com><br><b>Subject:</b> Re: [Openid-specs-ab] OpenID for Verifiable Presentations over BLE - draft 00 ready for review<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hello Tom,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-DW<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Aug 30, 2023, at 11:41 AM, Tom Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>The QR code should be signed JSON see spec for shc<o:p></o:p></p><div><p class=MsoNormal>thx ..Tom (mobile)<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Aug 30, 2023, 10:24 AM <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div name=messageSignatureSection><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Torsten.<o:p></o:p></p></div></div><div name=messageReplySection><div><p class=MsoNormal>Am 23. Aug. 2023, 10:23 +0200 schrieb Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #1ABC9C 1.0pt;padding:0cm 0cm 0cm 8.0pt;margin-left:3.75pt;margin-top:3.75pt;margin-right:3.75pt;margin-bottom:3.75pt'><p class=MsoNormal><br>I am 100% with you on this. Random QR code scanning is equivalent to clicking a URL from an unknown sender.<o:p></o:p></p></blockquote><div><p class=MsoNormal><br>What options exist to secure the QR code scanning?<o:p></o:p></p></div></div></div></blockquote></div><p class=MsoNormal>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br><a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>