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

Sat Dec 3 17:30:57 UTC 2022

There is actually a cautionary tale in that. A single QR code was
sufficient to carry one, two or maybe even three FHIR vaccination "events",
but with 5 or more, the FHIR prolixity has overflowed to a second QR code,
which doesn't really work with the primary display purpose on a
smartphone.  The lesson here is the long creds carry a penalty which may
not be fully understood for years after the std is created.
..tom

On Fri, Dec 2, 2022 at 11:33 PM Kristina Yasuda via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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>:
>
>
> 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>:
>
>
> 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>:
>
> 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 listOpenid-specs-ab at lists.openid.nethttps://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
> 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
> 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/20221203/c57d06b4/attachment.html>