Difference between revisions of "Mobile Driver's License with OIDC"

From MgmtWiki
Jump to: navigation, search
(Problems)
(Problems)
Line 10: Line 10:
 
* Reader - the device used by the verifier to get data from the mDL.
 
* Reader - the device used by the verifier to get data from the mDL.
 
* Attacker - a bogus wallet that is attempting to illicitly gain access or steal data from the reader.
 
* Attacker - a bogus wallet that is attempting to illicitly gain access or steal data from the reader.
 +
 +
* This context discusses only server retrieval using OIDC over the Internet. (It may be that Device retrieval has been attempted before server retrieval.)
  
 
==Problems==
 
==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.
 
* 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 seven access methods available including bluetooth which works over long distance.
+
* 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 unauthorised access by an mDL reader when mDL activation is triggered by NFC.
+
** 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 user's role in activation.
 +
** The reader must support both NFC and QR according to the standard.
 +
* Protect storage of user data in the wallet is not defined in the standard. Again, the issuing authority is given responsibility for storage in the wallet.
  
 
==Solutions==
 
==Solutions==

Revision as of 15:08, 21 May 2021

Full Title

How to use OpenID Connect (OIDC) 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.

Taxonomy

  • Holder - the subject
  • Wallet - the device software that holds th mDL.
  • Reader - the device used by the verifier to get data from the mDL.
  • Attacker - a bogus wallet that is attempting to illicitly gain access or steal data from the reader.
  • This context discusses only server retrieval using OIDC over the Internet. (It may be that Device retrieval has been attempted before server retrieval.)

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 user's role in activation.
    • The reader must support both NFC and QR according to the standard.
  • Protect storage of user data in the wallet is not defined in the standard. Again, the issuing authority is given responsibility for storage in the wallet.

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