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

Tom Jones thomasclinganjones at gmail.com
Mon Jul 12 23:33:57 UTC 2021


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/99bf146a/attachment-0001.html>


More information about the Openid-specs-ab mailing list