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

John Bradley ve7jtb at ve7jtb.com
Mon Jul 12 23:39:07 UTC 2021 

If it is offline then it is not SIOP, unless I am missing something.

A QR to set up a local BLE or Ultra wideband connection is a separate 
thing, and not subject to the same sort of Phishing attack.

John B.
------ Original Message ------
From: "Tom Jones" <thomasclinganjones at gmail.com>
To: "John Bradley" <ve7jtb at ve7jtb.com>; "Artifact Binding/Connect 
Working Group" <openid-specs-ab at lists.openid.net>
Cc: "Kristina Yasuda" <kristina.yasuda at microsoft.com>
Sent: 7/12/2021 7:33:57 PM
Subject: Re: [Openid-specs-ab] DHS mDL RFI response from OpenID 
Foundation

>I don't think that the DHS or ISO imagined that the QR would be used in 
>a fully on-line scenario. The issue is off-line support. Inclusion is 
>important for state issued identification.
>
>..tom
>
>
>On Mon, Jul 12, 2021 at 4: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>
>>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>
>>>
>>_______________________________________________
>>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/00dcf442/attachment.html>

More information about the Openid-specs-ab mailing list