--- title: Verifying a mobile document from a passport framework: identitydocumentservices role: article role_heading: Article path: identitydocumentservices/verifying-a-mobile-document-from-a-passport --- # Verifying a mobile document from a passport Validate a response from mobile document information derived from a passport. ## Overview Overview Beginning in iOS 26.1 and watchOS 26.1, people can add passports in the form of mobile documents (mdocs) to their Wallet using a valid government-issued passport. If approved, those credentials are signed by Apple and provisioned to an iOS or watchOS device. You can validate a passport Digital ID response using the ISO/IEC 23220-2 standard. It inherits the functionality of ISO 18013-5 standard. A Digital ID is a way for people to securely create an ID in Wallet using information from their U.S. passport and present their ID with an iPhone or Apple Watch. You can verify the authenticity, integrity, and validity of a Digital ID response in following scenarios: Your iOS app accepts mdocs using the Verify with Wallet API. For more information, see Requesting identity data from a Wallet pass. Your website accepts Verify with Wallet on the Web. For more information, see Requesting a mobile document on the web and Implementing as an identity document provider. Your iOS app reads the mdoc’s response using ProximityReader’s MobilePhotoIDRawDataRequest. Your ISO 18013-5 capable terminal wants to accept mdoc responses. note: Using the MobileDocumentDisplayRequest or MobilePhotoIDDataRequest API in the ProximityReader framework automatically verifies Digital IDs. Verify the passport mobile document response You can validate a Digital ID response by verifying the issuer and device signatures. The following object shows an mdoc’s response containing an array of documents and its structure, as defined in Section 8.3.2.1.2.3 of the ISO/IEC 18013-5: DeviceResponse version [documents] docType issuerSigned issuerNameSpaces (credential data) issuerAuth MSO (Mobile Security Object) version validityInfo deviceKeyInfo status identifier_list deviceSigned nameSpaces (device-signed data, if any) deviceAuth errors important: If your system or fraud rules require assurance that the original government-issued document the credential is derived from is still valid, supplement Digital ID presentment with other validation methods. Digital ID isn’t connected to the government-issued document’s system of record or any associated lost and stolen document revocation lists. The following steps can validate an mdoc’s response by verifying the issuer and device signatures: Decode the deviceResponse. Verify issuer signatures. Verify device signatures. The following table is a list of elements in the ISO/IEC 23220 issuer namespace: | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decode the device response The device response is a CBOR (RFC 8949 Concise Binary Object Representation) encoded byte array. You can check the validity of the response by using a CBOR library or parser in your chosen programming language. A valid Digital ID device response has: A version equal to or greater than 1.0 A nonempty documents object A docType that matches the expected value of org.iso.23220.photoid.1 If this step fails, you can choose to allow users to retry or fall back to a different verification method. Validate the device response and Mobile Security Object You can validate the deviceResponse by verifying the issuer and device signatures. Section 9.1.2 of ISO/IEC 18013-5 defines a procedure for validating the issuer data in the device response. This procedure helps your app authenticate data to ensure it comes from a source you trust. Before you extract the issuer-signed data, you need to first validate the Mobile Security Object (MSO), its validity period, and the revocation list, then verify the issuer authentication hashes. The MSO serves as a cryptographic anchor for the passport mdoc. Apple, the issuing authority, digitally signs this object. After it’s signed, it can’t be modified without invalidating the signature. The MSO expiration is set to 35 days, passport expiration, or birth date, whichever occurs first. You can see a complete list for validating the device response and MSO in Section 9.1.2 of ISO/IEC 18013-5. The following is a nonexhaustive, high-level list to validate the MSO: Check that the signature attached to the MSO is correct. Ensure the MSO version is at least 1.0 and not higher than the version of the device response. Ensure the date properties of validityInfo are valid. Ensure the docType matches the deviceResponse, org.iso.23220.photoid.1. Next, validate the document signer certificate, which signs the MSO. You can validate the document signer certificate by doing the following: Ensure that you’ve validated the Apple Issuing Authority root CA (IACA) and added it to your trust store. The IACA root CA certificates and associated policy documents and agreements are available in ISO/IEC 18013-5 section 9.1.2. Ensure that there’s a valid X.509 chain of trust to the Apple Issuing Authority Certificate Authority (IACA). Verify that the issuer is the same as the subject of the Apple IACA certificate. Verify that the certificate chain matches the certificate profile requirements described in Table B.3 of ISO/IEC 18013-5. Verify that countryName exists and contains a ISO 3166-1 alpha-2 code as per ISO/IEC 18013-5. Verify that all certificates are active. After you validate the MSO and its validity period and you verify the issuer authentication hashes, you can validate the MSO revocation list, which adds an extra layer of security. The MSO object contains a status structure with a publicly accessible URL that points to an MSO revocation list. Because the MSO revocation list is signed daily, each partition consists of a COSE_Sign1 structure that contains the leaf certificate used to validate the signature of the KRL partition. The leaf and intermediate CA certificate are in the COSE_Sign1 header and are checked against the root certificate, as defined by ISO/IEC 18013-5 second amendment section 9.1.2.6. note: Apple systems generate the revocation list when a Digital ID is removed from Wallet, becomes inactive for more than 60 days, or is deleted by the user in Find My or via Apple Care. The list doesn’t contain government-sourced data. For offline use cases, download and cache all partitions with a maximum cache duration of one day. Validate the data elements Verify that the user information in the response matches the data from the issuing authority. The MSO includes an array of digests or hashes, covering every element in the mdoc. To validate the date elements, ensure that each data element in the response matches its digest in the MSO by doing the following: Get the digestAlgorithm from the MSO as defined on ISO/IEC 18013-5 section 9.1.2.5. Get the valueDigests from the MSO. Validate each namespace by computing the digest for each signed item. Make sure its digest is present in the issuer authentication. There can be more digests than you see in the issuerSigned items structure because you only receive signed items for each element you request. Verify the device signatures Section 9.1.3 of ISO/IEC 18013-5 defines a procedure for authenticating mdocs. This procedure helps your app verify that the response came from the issued device. Using this procedure helps prevent mdoc cloning to an unauthorized device and intermediary attacks. Digital ID credentials use Elliptic Curve Digital Signature Algorithm (ECDSA) for mdoc authentication. You can see a complete list for verifying the device signature in Section 9.1.2 of ISO/IEC 18013-5. The following is a nonexhaustive, high-level list for verifying the device signature: Get the deviceKey from DeviceKeyInfo, encoded as a COSE_Key from the MSO. Extract the deviceSigned structure. Confirm the deviceKey from the MSO matches the key used to sign the deviceSigned object by validating the COSE_Sign1 signature in the deviceSigned.deviceAuth using the public key encoded in the MSO’s COSE_Key. note: If verifying the device signatures fails, you can choose to reject the Digital ID presentment response and optionally prevent the use of fallback verification methods. ## See Also ### Essentials - [Requesting a mobile document on the web](identitydocumentservices/requesting-a-mobile-document-on-the-web.md) - [Implementing as an identity document provider](identitydocumentservices/implenting-as-an-identity-document-provider.md)