[Openid-specs-ab] DHS mDL RFI response from OpenID Foundation

Tue Jul 13 01:52:00 UTC 2021

I could be wrong, but I believe the use case Jeremie had was to initiate SIOP via a remote QR code, by scanning it on the device with the OP.

The use case for this would be field deployment where the verifying party has limited technology available:
1. The ability to display a static QR code (perhaps on paper)
2. The ability to get updates from some infrastructure, perhaps via one-way data delivery.

Meanwhile the holder has a camera that can scan a QR code and internet access.

In this case, the verifier would show the static QR code which might contain a URL that would initiate SIOP, with client identifier being that of hosted infrastructure for the verifier.This could be a link to the verifier infrastructure first - e.g. allow a hosted service to generate a fully dynamic OIDC request from a static invocation URL in the QR code.

When I send my identity, it would be to the hosted verifier infrastructure - a one-way push would deliver the appropriate information to the verifying party in the field.

The holder might be tricked into releasing information to/authenticating into a service that they didn’t intend to, but presumably that would have to be a service that intended to support this flow. The authentication session that results would be within a user agent on the local device of the holder - the field verifier would be notified of success as a side-effect by the verifier infrastructure.

-DW

> On Jul 12, 2021, at 5:28 PM, John Bradley via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> There may be limited cases where the device presenting a QR code is trusted, but any general system using a QR code presented in the browser or CIBA opens a huge Phishing opportunity.
> 
> The attacker only needs to reverse proxy the QR code and will wind up capturing the session once the user authenticates in the back channel.
> 
> I would not recommend this as a general cross device solution. 
> 
> John B.
> 
> ------ Original Message ------
> From: "Torsten Lodderstedt via Openid-specs-ab" <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>>
> To: "Kristina Yasuda" <kristina.yasuda at microsoft.com <mailto:kristina.yasuda at microsoft.com>>
> Cc: "Torsten Lodderstedt" <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>>; "Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>" <Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>>
> Sent: 6/30/2021 4:06:28 PM
> Subject: Re: [Openid-specs-ab] DHS mDL RFI response from OpenID Foundation
> 
>> Hi Kristina,
>> 
>>> Am 29.06.2021 um 18:48 schrieb Kristina Yasuda <kristina.yasuda at microsoft.com <mailto:kristina.yasuda at microsoft.com>>:
>>> 
>>> Hi Torsten, 
>>> 
>>> > Can you please elaborate? SIOP as it Stands today is tied to the response type „id_token“, i.e. the RP sends the user agent to the SIOP on the same device. Transaction integrity is ensured by binding the nonce in the request to a cookie in this user agent. How do you envision to cross the boundary between devices and what are the consequences on the security of the flow? Can you share a sequence diagram?
>>> 
>>> The cross device flow could look like this:
>>> 1/ The user browses to the RP website
>>> 2/ The RP displays a QR code with request_uri in the user browser on device A
>>> (deeplink will be used in same-device flow)
>>> 3/ The user uses device B (Mobile Wallet) to scan the QR code, dereference it and fetch SIOP request object from the request_uri
>>> (processes like DID resolution can occur in-between)
>>> 4/ Mobile wallet sends ID Token (with embedded VP when VP is returned) in HTTP POST request to the RP
>>>  
>>> Sequence diagram of the implementation can be found here (note that some element of the flow might have changed from Dec. 2020):
>>> https://us02web.zoom.us/rec/play/BRBDWWUtB9HsmE88cJQwC9OH4k-QM9cdg8UYJXm6wwj-Yt54f7QMPPFqmQn-vtGAVNJgV9fGBeGN3eZR.QYMKFKYkJzdmdyaG <https://www.google.com/url?q=https://us02web.zoom.us/rec/play/BRBDWWUtB9HsmE88cJQwC9OH4k-QM9cdg8UYJXm6wwj-Yt54f7QMPPFqmQn-vtGAVNJgV9fGBeGN3eZR.QYMKFKYkJzdmdyaG&source=gmail-imap&ust=1625590112000000&usg=AOvVaw1_bCqMWMvMUEJk1Ap7exgk>
>>> It is a presentation at DIF Interoperability WG.
>> 
>> That’s an interesting flow, but not a standard SIOP flow for the following reasons: 
>> 
>> - the RP needs to distinguish on device and split device flow. A standard OIDC RP should just send the request (with or w/o request object) to the SIOP on the same device via redirect. 
>> - will most likely be received by the backend of the RP, whereas in the post respond mode, the OP is supposed to send the response to the RP through the front channel. Why is this important? Well, it allows the RP to (directly or indirectly) pick up the nonce from a Cookie and compare that to the nonce in the ID Token. This would ensure transaction integrity and prevents replay attacks, which is impossible in this flow simply because the RP does not have access to any data on the originating device.
>> 
>> Question: is the user supposed to scan a QR code shown on the device of the police officer when presenting her mDL? 
>> 
>>>  
>>> > I think the SIOP should expose a CIBA style interface to allow direct engagement from the verifier with the reader. The device engagement data could be used to share the endpoint location and so on.
>>>  
>>> Interesting. Do you mean holder sending a request direcly to the reader's Backchannel Authentication Endpoint? I am not very familiar with CIBA flows but we should probably explore more (cc: Tony)
>> 
>> yes. That’s what I mean. 
>> 
>> best regards,
>> Torsten. 
>> 
>>>  
>>> Thank you,
>>> Kristina
>>>  
>>> From: Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> 
>>> Sent: Saturday, June 26, 2021 1:35 AM
>>> To: Kristina Yasuda <Kristina.Yasuda at microsoft.com <mailto:Kristina.Yasuda at microsoft.com>>
>>> Cc: Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>>> Subject: Re: [Openid-specs-ab] DHS mDL RFI response from OpenID Foundation
>>>  
>>> Hi Kristina,
>>> 
>>> 
>>> Am 26.06.2021 um 04:32 schrieb Kristina Yasuda <Kristina.Yasuda at microsoft.com <mailto:Kristina.Yasuda at microsoft.com>>:
>>> 
>>> 
>>> Thank you for the feedback, Torsten. Please find comments in-line below.
>>> @Everyone, I am attaching the current version of the response. Kind reminder that we set the new deadline for comments to be June 30th.
>>>  
>>> - the example on p7 uses „verified_claims“ syntax, so it might be worthwhile mentioning OpenID Connect 4 Identity Assurance in the document
>>> -> I added the following text after the example on p7. Let me know if you want it changed. 
>>> "The “verified_claims” container element used in the example above is taken from OpenID Connect for Identity Assurance 1.0 specification (ekyc-ida) in OpenID Foundation. The usage of “verified_claims” container element allows to include information how the identity of a natural person has been verified in compliance with a certain law."
>>> Note that the Annex part has been submitted to the ISO mDL WG prior to this DHS response document, and this change will be proposed in the ISO document in the next revision cycle.
>>>  
>>> - section 7.1.3.4.4: how is the request sent from the reader to the SIOP? I’m asking since I thought those parties would live on different devices
>>> ->"Over the Internet", to borrow the terminology used in ISO. RP does not have to be on the same device as SIOP.
>>>  
>>> Can you please elaborate? SIOP as it Stands today is tied to the response type „id_token“, i.e. the RP sends the user agent to the SIOP on the same device. Transaction integrity is ensured by binding the nonce in the request to a cookie in this user agent. How do you envision to cross the boundary between devices and what are the consequences on the security of the flow? Can you share a sequence diagram?
>>> 
>>> 
>>> The question made me think that mDL specification does have a specific "device engagement" step during which registration/discovery information is passed in CBOR over NFC or QR code, so maybe we can leverage that for SIOP discovery/registration - need to think more.
>>>  
>>> I think the SIOP should expose a CIBA style interface to allow direct engagement from the verifier with the reader. The device engagement data could be used to share the endpoint location and so on.
>>> 
>>> 
>>>  
>>> - Generally: would it be possible to share more context with the WG? It seems like a lot of knowledge about ISO/IEC 18013-5 is required to understand the proposal
>>> -> Currently, OIDC in mDL is used for the verifier to talk to the Issuing authority to retrieve mDL data using the access token received from the user. This direct path to the Issuing Authority has raised concerns from verifiers and resulted in the need for "over the internet" solution directly between user and the verifier, so the SIOP was proposed. 
>>>  
>>> - typo on p2 2nd paragraph: "OpenII Connect“ -> OpenID Connect 
>>> -> corrected.
>>>  
>>> 
>>> best regards,
>>> Torsten.
>>> 
>>> Best,
>>> Kristina
>>> 差出人: Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>>
>>> 送信日時: 2021年6月14日 1:43
>>> 宛先: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>>
>>> CC: Kristina Yasuda <Kristina.Yasuda at microsoft.com <mailto:Kristina.Yasuda at microsoft.com>>
>>> 件名: Re: [Openid-specs-ab] DHS mDL RFI response from OpenID Foundation
>>>  
>>> Hi,  
>>>  
>>> thanks for sharing the draft response. 
>>>  
>>> Here are my comments:
>>>  
>>> - the example on p7 uses „verified_claims“ syntax, so it might be worthwhile mentioning OpenID Connect 4 Identity Assurance in the document
>>> - section 7.1.3.4.4: how is the request sent from the reader to the SIOP? I’m asking since I thought those parties would live on different devices
>>> - Generally: would it be possible to share more context with the WG? It seems like a lot of knowledge about ISO/IEC 18013-5 is required to understand the proposal
>>> - typo on p2 2nd paragraph: "OpenII Connect“ -> OpenID Connect 
>>>  
>>> best regards,
>>> Torsten. 
>>> 
>>> 
>>> Am 14.06.2021 um 09:32 schrieb Kristina Yasuda via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>>:
>>>  
>>> Dear All,
>>>  
>>> As discussed during the last Connect WG call, circulating the draft response from OpenID Foundation to DHS RFI on mDL (mobile Driving License).
>>> We wrote it with Tony and Tom Jones, and it has been reviewed by Gail, Mike and Nat.
>>> If you have any comments please send them by June 16th to the ML, so that we have time to reflect them before the submission deadline on June 18th.
>>> Apologies for circulating last minute. We can also discuss the questions and comments at tomorrow's Pacific Connect WG call.
>>>  
>>> Below are links to the original RFI from DHS:
>>> - https://www.govinfo.gov/content/pkg/FR-2021-04-19/pdf/2021-07957.pdf <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://nam06.safelinks.protection.outlook.com/?url%253Dhttps%25253A%25252F%25252Fwww.google.com%25252Furl%25253Fq%25253Dhttps%25253A%25252F%25252Fwww.govinfo.gov%25252Fcontent%25252Fpkg%25252FFR-2021-04-19%25252Fpdf%25252F2021-07957.pdf%252526source%25253Dgmail-imap%252526ust%25253D1624260775000000%252526usg%25253DAOvVaw1aQ3sHxbIfB3aUEbHijNiu%2526data%253D04%25257C01%25257CKristina.Yasuda%252540microsoft.com%25257Ce30e241796ab495de8d708d92f10778b%25257C72f988bf86f141af91ab2d7cd011db47%25257C1%25257C0%25257C637592570519543639%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C1000%2526sdata%253D1m5%25252BWMnsfw2%25252FthhyDTIMmjQ1kcFMESE1HYl2AYyzNG4%25253D%2526reserved%253D0%26source%3Dgmail-imap%26ust%3D1625279576000000%26usg%3DAOvVaw25ODNKS8bcom3UuBgSzHm_&source=gmail-imap&ust=1625590112000000&usg=AOvVaw1YlLh-3clOQc3phpnjy2vF>
>>> - https://www.aamva.org/21_4_19-Legislative-Alert-DHS-Requests-Information-for-REAL-ID-Mobile-Drivers-License-Rulemaking/ <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://nam06.safelinks.protection.outlook.com/?url%253Dhttps%25253A%25252F%25252Fwww.google.com%25252Furl%25253Fq%25253Dhttps%25253A%25252F%25252Fwww.aamva.org%25252F21_4_19-Legislative-Alert-DHS-Requests-Information-for-REAL-ID-Mobile-Drivers-License-Rulemaking%25252F%252526source%25253Dgmail-imap%252526ust%25253D1624260775000000%252526usg%25253DAOvVaw2bNG6F2m2_TGCHTp7Q4ykE%2526data%253D04%25257C01%25257CKristina.Yasuda%252540microsoft.com%25257Ce30e241796ab495de8d708d92f10778b%25257C72f988bf86f141af91ab2d7cd011db47%25257C1%25257C0%25257C637592570519553602%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C1000%2526sdata%253DvvUYqsUJGAqbo1dfdTphxDzcc65B%25252BxJwUFiZdbQIJ3c%25253D%2526reserved%253D0%26source%3Dgmail-imap%26ust%3D1625279576000000%26usg%3DAOvVaw3tYuhjE_rs-z1J6wxOAJt8&source=gmail-imap&ust=1625590112000000&usg=AOvVaw0Qat_vFb0I0UHzHlT9Z_Ge>
>>>  
>>> Kindest Regards,
>>> Kristina
>>>  
>>>  
>>> <Draft DHS RFI Response - mDL_v01.pdf>_______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>>> https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ab&source=gmail-imap&ust=1624260775000000&usg=AOvVaw2b8TMjt7LljoUVyGDrXZOz <https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://nam06.safelinks.protection.outlook.com/?url%253Dhttps%25253A%25252F%25252Fwww.google.com%25252Furl%25253Fq%25253Dhttp%25253A%25252F%25252Flists.openid.net%25252Fmailman%25252Flistinfo%25252Fopenid-specs-ab%252526source%25253Dgmail-imap%252526ust%25253D1624260775000000%252526usg%25253DAOvVaw2b8TMjt7LljoUVyGDrXZOz%2526data%253D04%25257C01%25257CKristina.Yasuda%252540microsoft.com%25257Ce30e241796ab495de8d708d92f10778b%25257C72f988bf86f141af91ab2d7cd011db47%25257C1%25257C0%25257C637592570519563554%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C1000%2526sdata%253D83eU9%25252FL%25252FtJznWQyuB0uyK3Thh%25252FrNJoB5Ef0Lr7buzI8%25253D%2526reserved%253D0%26source%3Dgmail-imap%26ust%3D1625279576000000%26usg%3DAOvVaw1SJcRdEpSQPS2MOiNBmSol&source=gmail-imap&ust=1625590112000000&usg=AOvVaw1blbDFPs71NhRC1z4Le5UZ>
>>>  
>>> <Draft DHS RFI Response - mDL_v02.docx>
>> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://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/20210712/6f812f59/attachment.html>