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

Tom Jones thomasclinganjones at gmail.com
Tue Jul 13 03:29:42 UTC 2021


this thread is about the DHS RFI proposal!

Be the change you want to see in the world ..tom


On Mon, Jul 12, 2021 at 7:02 PM David Waite <david at alkaline-solutions.com>
wrote:

> 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> 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
>>
> _______________________________________________
> 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/27f63d7e/attachment-0001.html>


More information about the Openid-specs-ab mailing list