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

David Waite david at alkaline-solutions.com
Tue Jul 13 02:02:17 UTC 2021


Offline support requires bidirectional information flow; presenting a QR code response or establishing a data transfer over an ad-hoc/networkless channel.

I could imagine either:
1. The response message being encoded into potentially several QR codes, that the verifier must scan
2. the QR code would not be SIOP but rather a link for a native app/PWA to initiate a bluetooth channel and then request/response messages would flow across that channel
3. the initiation would be a normal SIOP request, with the redirect uri (or other mechanism to return results) indicating they need to be returned over a negotiated channel such as bluetooth.

-DW

> On Jul 12, 2021, at 5:33 PM, Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> 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 <mailto: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 <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> _______________________________________________
> 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/4b6d2942/attachment-0001.html>


More information about the Openid-specs-ab mailing list