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

Torsten Lodderstedt torsten at lodderstedt.net
Wed Jun 30 20:06:28 UTC 2021


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 <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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210630/d6a93e20/attachment.html>


More information about the Openid-specs-ab mailing list