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

John Bradley ve7jtb at ve7jtb.com
Mon Jul 12 23:28:24 UTC 2021 

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>
To: "Kristina Yasuda" <kristina.yasuda at microsoft.com>
Cc: "Torsten Lodderstedt" <torsten at lodderstedt.net>; 
"Openid-specs-ab at lists.openid.net" <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>:
>>
>>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>
>>Sent: Saturday, June 26, 2021 1:35 AM
>>To: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
>>Cc: 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>:
>>>
>>>
>>>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>
>>>送信日時: 2021年6月14日 1:43
>>>宛先: Artifact Binding/Connect Working Group 
>>><openid-specs-ab at lists.openid.net>
>>>CC: Kristina Yasuda <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>:
>>>>
>>>>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
>>>>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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210712/3854690f/attachment-0001.html>

More information about the Openid-specs-ab mailing list