Mobile Driver's License with Reader - Revision history

Tom: /* Problems */

2022-08-01T21:56:02Z

‎Problems

Tom: /* References */

2021-08-09T15:01:19Z

‎References

Tom: /* Context */

2021-05-23T23:55:19Z

‎Context

Tom: /* Problems */

2021-05-23T23:30:56Z

‎Problems

Tom: /* Problems */

2021-05-23T23:29:38Z

‎Problems

Tom: /* Context */

2021-05-23T22:05:26Z

‎Context

Tom: /* Context */

2021-05-23T21:45:09Z

‎Context

Tom: Created page with "==Full Title== How to use any Reader with a Mobile Driver's License (mDL) compliant with ISO 18013-5, ==Context== * If the mDL reader receives the token and URL from the..."

2021-05-23T21:40:53Z

Created page with "==Full Title== How to use any Reader with a Mobile Driver's License (mDL) compliant with ISO 18013-5, ==Context== * If the mDL reader receives the token and URL from the..."

New page

==Full Title==
How to use any Reader with a [[Mobile Driver's License]] (mDL) compliant with ISO 18013-5,

==Context==
* If the mDL reader receives the token and URL from the mDL, either during device engagement or device data retrieval, it may retrieve mDL data from the issuing authority via the Internet or locally. If the reader chooses to use the internet, either OIDC or WebAPI can be used to retrieve the information.
* This context discusses only server retrieval using OIDC over the Internet. (It may be that Device retrieval has been attempted before server retrieval.)
* Data elements are signed by the issuing authority (IA).
* The mDL produces a signature or message authentication code over session data. The private key used to authenticate the session data is stored only in the mDL. The corresponding public key in turn is signed by the IA.
* Communications between mDL and mDL reader are encrypted and authenticated. The method is not defined.

===Taxonomy===

{|border="1" padding="2" width="899px"
| Term || mDL Purpose or Behavior || OIDF term or concept
|-
| Holder|| The person that has the license to drive || the subject
|-
| Wallet || the device software that holds the mDL (aka mdoc) || software statement
|-
| Reader || the device used by the verifier to get data from the mDL || client (RP)
|-
| user agent || A program, such as a browser or other Web client, that mediates the communication between holders, issuers, and verifiers. (This does not match DID core well at all.)|| Place to store Cookies
|-
| Attacker || a bogus wallet that is attempting to illicitly gain access or steal data from the reader || Used in FAPI
|-
| Issuing Authority || typically the DMV or other state agency.|| used in Federation
|}

==Problems==
* If the Reader might use the internet for some transactions, but not all, then the type of access can lead information from the reader to an attacker.
* Activation of the mDL is not defined in the standard and there are two access methods: NFC and QR. Other access methods available to the wallet MUST not be used for activation.
** Oddly the issuing authority is responsible to avoid unauthorized access by an mDL reader when mDL activation is triggered by NFC or QR.
** Nothing is said about the holder's role in activation.
** The reader must support both NFC and QR according to the standard.
* Protect storage of holder data in the wallet is not defined in the standard. Again, the issuing authority is given responsibility for storage in the wallet.
* The OIDC standard does not make any claim about data contained in JWT packets. The local implementation needs to clarify the protect levels needed by the transfers.

==Solutions==
* The transaction has been designed such that it is not necessary for the mDL holder to physically hand over the mobile device to the mDL verifier.
* A wallet that wants to be activated only from local devises should never use and radios than NFC as the others can be very distant from the holder.
* Even after reading data from the wallet, the reader can still decide to go to the Internet to retrieve data on the holder.

==References==

[[Category: Best Practice]]
[[Category: Authentication]]
[[Category: Profile]]
[[Category: Identifier]]

← Older revision		Revision as of 15:01, 9 August 2021
Line 49:		Line 49:
	[[Category: Profile]]		[[Category: Profile]]
	[[Category: Identifier]]		[[Category: Identifier]]
		+	[[Category: Mobile]]

@@ Line 33: / Line 33: @@
 * Activation of the mDL is not defined in the standard and there are two access methods: NFC and QR. Other access methods available to the wallet MUST not be used for activation.
 ** Oddly the issuing authority is responsible to avoid unauthorized access by an mDL reader when mDL activation is triggered by NFC or QR.
-** Nothing is said about the holder's role in activation.
+** Nothing is said about the holder's role in activation even though they should be the only ones to [[Consent]] to access the data.
 ** The reader must support both NFC and QR according to the standard.
 * Protected storage of holder data in the wallet is not defined in the standard. Again, the issuing authority is given responsibility for storage in the wallet.

@@ Line 8: / Line 8: @@
 * Data elements are signed by the issuing authority (IA).
 * The mDL produces a signature or message authentication code over session data. The private key used to authenticate the session data is stored only in the mDL. The corresponding public key in turn is signed by the IA.
-* Communications between mDL and mDL reader are encrypted and authenticated. The method is not defined.
+* Communications between mDL and mDL reader are encrypted and authenticated. The method is selected by the various parties.

@@ Line 36: / Line 36: @@
 ** The reader must support both NFC and QR according to the standard.
 * Protect storage of holder data in the wallet is not defined in the standard. Again, the issuing authority is given responsibility for storage in the wallet.
-* The OIDC standard does not make any claim about data contained in JWT packets. The local implementation needs to clarify the protect levels needed by the transfers.
+* The OIDC standard does not make any claim about data contained in JWT packets. The local implementation needs to clarify the protection levels needed by the transfers.
 ==Solutions==

@@ Line 3: / Line 3: @@
 ==Context==
-* If the mDL reader receives the token and URL from the mDL, either during device engagement or device data retrieval, it may retrieve mDL data from the issuing authority via the Internet or locally. If the reader  chooses to use the internet, either OIDC or WebAPI can be used to retrieve the information.
+* If the mDL reader receives the token and URL from the mDL, either during device engagement or device data retrieval,
 * This context discusses only reader retrieval from the doc. (It may be that Device retrieval has been attempted before server retrieval.)
 * Data elements are signed by the issuing authority (IA).