[Openid-specs-ab] OpenID for Verifiable Presentations over BLE (Request for WG Adoption)

Sat Dec 3 07:33:26 UTC 2022

Smart health cards display User’s credential (main use case being vaccination credential) in a QR code and in those scenarios it was not necessary for a verifier to display any QR code, user knew QR code of which credential to show.

For large size credentials, there is smart health links, where a QR code contains a URL to a credential. In which case, a request from the verifier is also not defined - user knows QR code of what cred to show.
https://docs.smarthealthit.org/smart-health-links/

https://docs.smarthealthit.org/smart-health-links/
Cheers,
Kristina

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Sent: Friday, December 2, 2022 7:33:36 AM
To: Torsten Lodderstedt <torsten at lodderstedt.net>
Cc: David Chadwick <d.w.chadwick at verifiablecredentials.info>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] OpenID for Verifiable Presentations over BLE (Request for WG Adoption)

On 02/12/2022 15:04, Torsten Lodderstedt wrote:

Am 02.12.2022 um 15:59 schrieb David Chadwick <d.w.chadwick at verifiablecredentials.info<mailto:d.w.chadwick at verifiablecredentials.info>>:

On 02/12/2022 13:48, Torsten Lodderstedt wrote:

Am 02.12.2022 um 12:46 schrieb David Chadwick <d.w.chadwick at verifiablecredentials.info<mailto:d.w.chadwick at verifiablecredentials.info>>:

On 02/12/2022 11:24, Torsten Lodderstedt wrote:
Hi David,

Am 23.11.2022 um 19:14 schrieb David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>:

Hi Torsten

excellent work. I fully support its adoption by the WG

Thanks.

I note however that if the Verifier uses a QR code to kick off the transaction, then the wallet could equally well display a QR code containing the vp_token (assuming the VC is small enough) in which case BLE will not be needed. This flow should be supported.

Do you mean the wallet would show a QR code in response to the request encoded in the verifier’s QR code?

Yes, the wallet can display a QR code in answer to the verifier's request (in a QRcode). This only works for small VP/VC due to the size restrictions of QR codes,

The QR code only contains a small amount of data sufficient to establish a secure connection. The presentation request itself is sent over BLE. Putting the whole request in the QR Code would result in a much bigger QR Code.

So you are using the ISO mDL model where the initial message only kicks off the BLE, then the request and response are sent via BLE. I misunderstood. I thought the request was in the QRcode (as per the cross device flow) and would have an additional parameter such as UseBLE=True; - a bit like we do with Post=True for the response)

If you use this model then you dont need a special message to kick off the BLE do you?

I would suggest to treat this is a another protocol besides BLE.

Surely it would be better if the RP could display one QRcode with it containing the choices that the wallet can take, instead of multiple QR codes each for a different mode of interaction?

This makes the protocol more complex than it is right now and the QR Code back and forth is not super use friendly.

Actually we found it was liked by users in user trials that we performed at a cinema during lockdown.

The cinema displayed a QR code on its window. The customer scanned this into their wallet whilst queuing, then on arrival at the ticket desk showed their QR code on their wallet to the receptionist which scanned it in, and if OK, they were let into the cinema. In our case the QRcode was a pointer to a COVID VC, but it could just have well been the VC itself. (We built a generic model that could cope with any size of VC and any number of VCs in the VP, which is why we used a pointer rather than the VC itself).

Kind regards

David

I would be reluctant to introduce additional complexity if we find out the BLE solution is quick and has a great UX.

Kind regards

David

but it will be a lot simpler than setting up a BLE session (which I always find is tedious to do - e.g. between my car and mobile phone).

You don’t need to setup a BLE session yourself with the QR Code approach. That will happen automatically. UX is key!

Kind regards

David

best regards.
Torsten.

Kind regards

David

On 23/11/2022 17:52, Torsten Lodderstedt via Openid-specs-ab wrote:
Hi all,

Kristina, Kenichi, Sasi, Ramesh, and myself have been working for a couple of month on a specification to enable VC presentation over BLE.

Here is the link the individual draft: https://tlodderstedt.github.io/openid-for-verifiable-presentations-offline-1_0-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftlodderstedt.github.io%2Fopenid-for-verifiable-presentations-offline-1_0-00.html&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb957c71aaf0e42b8373908dad47a9ea3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638055920409907444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uBiTIfhrC0iy8Z8HHftP4ArY8XLL2aRXXb60OYW0GMQ%3D&reserved=0>

We think this would be a valuable extension to the OpenID 4 VCs protocol family as it would allow offline presentation (e.g. at the entrance of a conference or a restaurant) using the mechanisms we already have in OpenID4VPs.

An implementation of the spec is under way at MOSIP.

We ask the WG to consider this draft for adoption as WG document.

best regards,
Torsten

_______________________________________________
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb957c71aaf0e42b8373908dad47a9ea3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638055920409907444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kclziXCuhOX2fIfI6qFpfu76VRl0r4o8GiRKdIoek6Y%3D&reserved=0>

_______________________________________________
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cb957c71aaf0e42b8373908dad47a9ea3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638055920409907444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kclziXCuhOX2fIfI6qFpfu76VRl0r4o8GiRKdIoek6Y%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20221203/b11e3eb6/attachment-0001.html>