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

Latest revision as of 11:14, 27 August 2024

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.
• 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.
• The reader must have a private key and certificate signed by a competent authority. It is theoretically possible for the wallet to check the key.
• Revocation methods are mentioned in the standard, but are not defined.
• TLS is required OIDC transfers. TLS client is required, which appears to mean mutual TLS is required, although other methods are possible.
• One time tokens are required for server transfers. This typically means a packet ID or nonce is supplied.
• CBOR data is used from the mDL in CDDL tstr per RFC 8610 which is converted to json according the RFC 7049 section 4.1.
• All data element names are prefixed with “org.iso.18013.5.1:”. No provision for a header namespace declaration is defined.

The following are the data retrieval steps from 8.3.3.2.2 using code flow, which seems utterly pointless for cases where the client is already certified. In which case only step 3 wold be needed.

1. It appears that configuration discovery using OpenID Connect Discovery is required to get the authz endpoint. This seems inefficient and probably unneccessary.
2. The reader requires a clientid which can be obtained from a client registration process (but that seems to conflict with the idea that all readers are registered.)
3. Reader (client) sends authorization endpoint the clientid and token from mdoc as login_hint.
   1. For some unexplained reason the authz resp is send to the mdoc with the authz code.
4. Reader (client) sends authz code to "token" endpoint.
   1. The Token endpoint sends the id_token.

Taxonomy

Problems

• If the Reader might use the internet for some transactions, but not all, then the type of access can leak 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.

Example 1

Managing mDL ISO 18013-5 Credentials using OpenID using a Verifiable Presentation from WaltID.

Issue, store and verify mDL credentials via OID4VC/VP via WaltID issuer, verifier and wallet API services.

Check out the guides below to get started:

• Issuer API: https://bit.ly/3YD9why
• Verifier API: https://bit.ly/4dGH56B
• Wallet API: https://bit.ly/3YJXcME

Example 2

From 18013-5

Step 3 Authorisation Authorisation Request:

GET /connect/authorize?client_id=ac55a761d4e74b35a9f2de06c3ea4f63
  & scope=openid org.iso.18013.5.1:given_name org.iso.18013.5.1:family_name org.iso.18013.5.1:birthdate org.iso.18013.5.1:portrait
  & redirect_uri=com.company.isomdlreader://login& response_type=code
  & login_hint=TOKEN-FROM-MDL-HOLDER HTTP/1.1

Host: {BASE_URL}
Authorisation Response:
{ 
   "Query": { 
      "code": [
          "1ad358e1fbc55e7cce0e515966f7b72699b9d47ce7fd6a1a63423820c9ed8f42" 
      ], 
      "scope": [ 
         "openid org.iso.18013.5.1:given_name org.iso.18013.5.1:family_name org.iso.18013.5.1:birthdate org.iso.18013.5.1:portrait"
      ] 
   }, 
   "Headers": { 
      "Cache-Control": [
         "no-cache"
      ],
      "Connection": [ 
         "Keep-Alive"
      ],
      "Accept": [ 
         "*/*"
      ],
      "Accept-Encoding": [
         "gzip, deflate"
      ],
      "Cookie": [
         "idsrv=……………………………………………….."
      ],
      "Host": [
         "{BASE_URL}"
      ],
      "Referer": [
         "https://{BASE_URL}/connect/authorize/callback?client_id= ac55a761d4e74b35a9f2de06c3ea4f63&scope=openid%20org.iso.18013.5.1:given_name%20org.iso.18013.5.1:family_name%20org.iso.18013.5.1:birthdate%20org.iso.18013.5.1:portrait&redirect_uri=com.company.isomdlreader://login&response_type=code&login_hint=VIENNAS-TOKEN" 
      ],
      "X-Original-Proto": [ 
         "http"
      ], 
      "X-Original-For": [
         "127.0.0.1:58873"
      ]
   }
}
Step 4 Get ID Token
Token Request:
POST /connect/token HTTP/1.1
Content-Type:application/x-www-form-url
encodedHost: {BASE_URL} 
redirect_uri:com.company.isomdlreader://login
grant_type:authorization_code
code:385b19cf37ddb9bd35a29e6db85d2d52a178c96009fd7a14d43ccc4b324f6322
client_id: ac55a761d4e74b35a9f2de06c3ea4f63
client_secret: OoZlNbaKSPQKWSLSc6AHTUFmpPOssio1
Token Response
{
   "id_token":
"eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1NzEzMjMzMDYsImV4cCI6MTU3MTMyMzYwNiwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NTAwMSIsImF1ZCI6IjdiMGQyZGU0OTVmOTQ5ZWY5YmIxMzRlMDA1NWMxYjZjIiwiaWF0IjoxNTcxMzIzMDM1LCJhdF9oYXNoIjoiSWluQTE2X3oxUVFXd2k1aE1LbFdCZyIsInN1YiI6IjE0Njg3ODUyMiIsImF1dGhfdGltZSI6MTU3MTMyMjkzNiwiaWRwIjoibG9jYWwiLCJkb2NUeXBlIjoib3JnLmlzby4xODAxMy41LjEubURMIiwib3JnLmlzby4xODAxMy41LjE6cG9ydHJhaXQiOiJfOWpfNEFBUVNrWkpSZ0FCQVFFQThBRHdBQURfNFFDS1JYaHBaZ0FBVFUwQUtnQUFBQWdBQndFYUFBVUFBQUFCQUFBQVlnRWJBQVVBQUFBQkFBQUFhZ0VvQUFNQUFBQUJBQUlBQUFFeEFBSUFBQUFRQUFBQWNsRVFBQUVBQUFBQkFRQUFBRkVSQUFRQUFBQUJBQUFBQUZFU0FBUUFBQUFCQUFBQUFBQUFBQUFBQUFEd0FBQUFBUUFBQVBBQUFBQUJjR0ZwYm5RdWJtVjBJRFF1TVM0MkFQX2JBRU1BS2gwZ0pTQWFLaVVpSlM4dEtqSV9hVVFfT2pvX2dWeGhUR21aaHFDZWxvYVRrYWk5OHMyb3MtVzFrWlBTXzlYbC12X19fXy1qeV9fX19fX184dl9fX19fYkFFTUJMUzh2UHpjX2ZFUkVmUC11azY3X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19BQUJFSUFDZ0FLQU1CSWdBQ0VRRURFUUhfeEFBZkFBQUJCUUVCQVFFQkFRQUFBQUFBQUFBQUFRSURCQVVHQndnSkNndl94QUMxRUFBQ0FRTURBZ1FEQlFVRUJBQUFBWDBCQWdNQUJCRUZFaUV4UVFZVFVXRUhJbkVVTW9HUm9RZ2pRckhCRlZMUjhDUXpZbktDQ1FvV0Z4Z1pHaVVtSnlncEtqUTFOamM0T1RwRFJFVkdSMGhKU2xOVVZWWlhXRmxhWTJSbFptZG9hV3B6ZEhWMmQzaDVlb09FaFlhSGlJbUtrcE9VbFphWG1KbWFvcU9rcGFhbnFLbXFzck8wdGJhM3VMbTZ3c1BFeGNiSHlNbkswdFBVMWRiWDJObmE0ZUxqNU9YbTUtanA2dkh5OF9UMTl2ZjQtZnJfeEFBZkFRQURBUUVCQVFFQkFRRUJBQUFBQUFBQUFRSURCQVVHQndnSkNndl94QUMxRVFBQ0FRSUVCQU1FQndVRUJBQUJBbmNBQVFJREVRUUZJVEVHRWtGUkIyRnhFeUl5Z1FnVVFwR2hzY0VKSXpOUzhCVmljdEVLRmlRMDRTWHhGeGdaR2lZbktDa3FOVFkzT0RrNlEwUkZSa2RJU1VwVFZGVldWMWhaV21Oa1pXWm5hR2xxYzNSMWRuZDRlWHFDZzRTRmhvZUlpWXFTazVTVmxwZVltWnFpbzZTbHBxZW9xYXF5czdTMXRyZTR1YnJDdzhURnhzZkl5Y3JTMDlUVjF0ZlkyZHJpNC1UbDV1Zm82ZXJ5OF9UMTl2ZjQtZnJfMmdBTUF3RUFBaEVERVFBX0FOU2lpb3BUeUJRQV9ldnJUcXJWSkVlU0tBSktLUTBVQU9wa2k1NUZQcUZuSlBIQW9BWlVpTGprMHplM3JRSElQUElvQWxORk56UlFBOV91R29LS0tBRXBwb29vQWxYN29vb29vQV9fMlEiLCJvcmcuaXNvLjE4MDEzLjUuMTpnaXZlbl9uYW1lIjoiSk9ITiIsIm9yZy5pc28uMTgwMTMuNS4xOmZhbWlseV9uYW1lIjoiRE9FIiwib3JnLmlzby4xODAxMy41LjE6YmlydGhkYXRlIjoiMTk4NS0wMy0zMCIsImFtciI6WyJwd2QiXX0.LpgOQfGycgEXRGFV-vLUEup9oxKfTzDyU179mtTFTodXBwx0aWaZAvslWH2rt-ET1RQG2Pa3ccNE4anfqPHT9Q",
   "access_token":
"eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1NzEzMjMwMzUsImV4cCI6MTU3MTMyMzMzNSwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NTAwMSIsImF1ZCI6Imh0dHBzOi8vbG9jYWxob3N0OjUwMDEvcmVzb3VyY2VzIiwiY2xpZW50X2lkIjoiN2IwZDJkZTQ5NWY5NDllZjliYjEzNGUwMDU1YzFiNmMiLCJzdWIiOiIxNDY4Nzg1MjIiLCJhdXRoX3RpbWUiOjE1NzEzMjI5MzYsImlkcCI6ImxvY2FsIiwic2NvcGUiOlsib3JnLmlzby4xODAxMy41LjE6cG9ydHJhaXQiLCJvcmcuaXNvLjE4MDEzLjUuMTpnaXZlbl9uYW1lIiwib3JnLmlzby4xODAxMy41LjE6ZmFtaWx5X25hbWUiLCJvcmcuaXNvLjE4MDEzLjUuMTpiaXJ0aGRhdGUiLCJvcGVuaWQiXSwiYW1yIjpbInB3ZCJdfQ.NjjUPRIgZ2opFeEJdJTV2_Hy2JSH_15ntoQho54SKSn1ZAtqXw6q-Yiulmo3L8ZAUa6_ARAA8VdNr219upULmA",
   "expires_in": 300,
   "token_type": "Bearer"
}

ID_TOKEN decoded

{
  "nbf": 1571323306,
  "exp": 1571323606,
  "iss": "https://localhost:5001",
  "aud": "7b0d2de495f949ef9bb134e0055c1b6c",
  "iat": 1571323035,
  "at_hash": "IinA16_z1QQWwi5hMKlWBg",
  "sub": "146878522",
  "auth_time": 1571322936,
  "idp": "local",
  "docType": "org.iso.18013.5.1.mDL",
  "org.iso.18013.5.1:portrait": "_9j_4AAQSkZJRgABAQEA8ADwAAD_4QCKRXhpZgAATU0AKgAAAAgABwEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAQAAAAclEQAAEAAAABAQAAAFERAAQAAAABAAAAAFESAAQAAAABAAAAAAAAAAAAAADwAAAAAQAAAPAAAAABcGFpbnQubmV0IDQuMS42AP_bAEMAKh0gJSAaKiUiJS8tKjI_aUQ_Ojo_gVxhTGmZhqCeloaTkai98s2os-W1kZPS_9Xl-v____-jy_______8v_____bAEMBLS8vPzc_fEREfP-uk67____________________________________________________________________AABEIACgAKAMBIgACEQEDEQH_xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv_xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5-jp6vHy8_T19vf4-fr_xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv_xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4-Tl5ufo6ery8_T19vf4-fr_2gAMAwEAAhEDEQA_ANSiiopTyBQA_evrTqrVJEeSKAJKKQ0UAOpki55FPqFnJPHAoAZUiLjk0ze3rQHIPPIoAlNFNzRQA9_uGoKKKAEppoooAlX7oooooA__2Q",
  "org.iso.18013.5.1:given_name": "JOHN",
  "org.iso.18013.5.1:family_name": "DOE",
  "org.iso.18013.5.1:birthdate": "1985-03-30",
  "amr": [
    "pwd"
  ]
}

References