Document mixed OIDC DTBD format and new claims.

Clarify mixed DTBD array behavior for _any ACR flows and add documentation for mid_pk_aal3 and mid_profile_signer_cert_chain claims in OIDC guides.

Author: phaupt

docs/oidc-integration-guide/getting-started.md

@@ -93,7 +93,7 @@ The following request query string parameters are supported:
 | `id_token_hint` | SHALL NOT be used | |
 | `claims` | SHALL NOT be used | |
 | `login_hint` | CAN be set to provide a login hint to the authorization server about the end-user's phone number(s) or LDAP username. Must be in a JSON format. | See [Login Hint Examples](/oidc-integration-guide/getting-started#login-hint-examples) below. |
-| `dtbd` | CAN be set to overwrite the default authentication message displayed to the end-user if the authentication method is either Mobile ID SIM or Mobile ID App. | See [DTBD Parameter](/oidc-integration-guide/getting-started#dtbd-parameter) below. |
+| `dtbd` | CAN be set to overwrite the default authentication message displayed to the end-user if the authentication method is either Mobile ID SIM or Mobile ID App. Supports plain string, JSON object, or mixed JSON array. | See [DTBD Parameter](/oidc-integration-guide/getting-started#dtbd-parameter) below and [Message Formats](/oidc-integration-guide/message-formats). |
 
 #### Login Hint Examples
 
@@ -142,6 +142,8 @@ The `dtbd` message should include these keywords:
 - `#SESSION#` — A unique transaction number. In case MFA Number Matching is enabled, this keyword will be replaced with the matching number.
 - `#CLIENT#` — Relying Party Display Name.
 
+For requests using `_any` ACR values (for example `mid_al2_any` or `mid_al3_any`), the final method can be resolved at runtime. In this case, you can send mixed `dtbd` (JSON array with one Classic string and one Transaction Approval object) so SIM and App are both covered in one request. See [Message Formats](/oidc-integration-guide/message-formats#mixed-dtbd-classic--transaction-approval).
+
 The default authentication message is:
 
 | Language | Message |
@@ -170,6 +172,7 @@ Given below is the list of supported scopes that can be requested during the aut
 | `mid_profile` | `mid_profile_recovery_code_status` | boolean | `true` | Whether a recovery code has been set |
 | | `mid_profile_serial` | string | `MIDCHEYUD1YE4QB1` | Mobile ID serial number |
 | | `mid_pk_keyringid` | string | `MIDPK123A567B90` | Passkey keyring identifier |
+| | `mid_profile_signer_cert_chain` | string[] | `["MIIF...","MIIE..."]` | Signer certificate chain (Base64-encoded DER certificates) |
 | | `mid_profile_sim_status` | string | `active` | SIM card activation status |
 | | `mid_profile_sim_pin_status` | string | `active` | SIM PIN status |
 | | `mid_profile_sim_mcc` | string | `228` | Mobile Country Code |
@@ -191,6 +194,7 @@ Given below is the list of supported scopes that can be requested during the aut
 | | `mid_pk_cred_fingerprint` | string | `pQECAyYgASFY...` | SHA-256 of the credential public key ([COSE](https://datatracker.ietf.org/doc/html/rfc9052)) |
 | | `mid_pk_auth_attachment` | string | `platform` \| `cross-platform` | Authenticator attachment modality |
 | | `mid_pk_os_family` | string | `iOS` \| `Android` \| `Windows` | OS family of the authenticator platform |
+| | `mid_pk_aal3` | boolean | `true` | Whether the passkey authenticator used in the transaction is NIST AAL3-compliant |
 
 ::: tip
 A Relying Party should always respect the user's privacy and keep the requested claims down to the very essential. For example, using scope `openid` only, the user sign-in will be anonymous. Neither the phone number nor any other user information will be passed on to the Relying Party's application.

docs/oidc-integration-guide/message-formats.md

@@ -1,6 +1,6 @@
 # Message Formats on the Mobile ID App
 
-Mobile ID App screens can present the Data-To-Be-Displayed (DTBD) in two formats.
+Mobile ID supports three request variants for the Data-To-Be-Displayed (DTBD): Classic, Transaction Approval, and a mixed format that contains both.
 
 ::: tip
 Use **Classic DTBD** for short confirmations and when you must support SIM users. Keep messages concise and always include the "DTBD Prefix".
@@ -21,10 +21,14 @@ Use **Transaction Approval** when readability matters (e.g., [PSD2](https://eur-
 
    Approve/Cancel becomes active only after the user scrolls to the end if content exceeds one screen.
 
-   RPs request this by sending a JSON object in the dtbd authorization parameter.
+   RPs request this by sending a JSON object in the `dtbd` authorization parameter.
 
    <img src="/img/message-formats-transaction-approval.png" alt="message-formats-transaction-approval" width="350">
 
+3. **Mixed DTBD** (JSON array with Classic + Transaction Approval) lets the RP send both representations in one request.
+
+   This is useful with `_any` ACR values (for example `mid_al3_any`) where the final method is resolved at runtime.
+
 
 ## Classic DTBD
 
@@ -72,6 +76,43 @@ How to request it: Send a JSON object via the `dtbd` authorization request param
 - **DTBD Prefix** (required): your configured prefix must be in the value of the first pair
   e.g., `{"key":"Company","value":"Acme AG: ..."}`
 
+## Mixed DTBD (Classic + Transaction Approval)
+
+Send a JSON array in `dtbd` that contains:
+
+- exactly one Classic DTBD string
+- exactly one Transaction Approval object
+
+The order does not matter. The OP detects element types by JSON type (string vs object).
+
+```json
+[
+  "MobileID: Confirm sign in to MyBank? Ref: #SESSION#",
+  {
+    "type": "MyBank Login",
+    "dtbd": [
+      { "key": "Username", "value": "MobileID: Nora Keller" },
+      { "key": "IP Address", "value": "185.45.16.238" },
+      { "key": "City", "value": "Basel" },
+      { "key": "Agent", "value": "Apple iPhone" },
+      { "key": "Reference ID", "value": "LOGIN-VRFY-XZ1" }
+    ]
+  }
+]
+```
+
+Selection behavior:
+
+- **SIM resolved:** Classic DTBD is used.
+- **App resolved:** Transaction Approval is used when present.
+- **Passkey resolved:** `dtbd` is ignored (existing behavior).
+
+Validation notes:
+
+- The `dtbd` array must contain one string and one object (max two elements).
+- Empty arrays, duplicate types, malformed JSON, or unsupported element types are rejected with `mid_auth_4000`.
+- Existing Classic and Transaction Approval limits apply unchanged inside the array.
+
 ## Transaction Approval Example
 
 ### Pretty JSON
@@ -141,10 +182,13 @@ Request an App ACR (e.g., `mid_al3_mobileapp`) if you want to ensure the App met
 
 i.e., the `dtbd` array only; the `type` label is not part of the signed bytes.
 
+**Mixed DTBD:** only the representation selected for the resolved method is signed (Classic text for SIM, Transaction Approval normalized content for App).
+
 ## Best practices
 
 ::: info
 - **Build → URL-encode → send:** generate the JSON with your library, then URL-encode as `dtbd`. Avoid hand-crafted strings. (Use PAR for large payloads/confidentiality.)
+- **Use mixed format for `_any` ACRs:** when method resolution may end on SIM or App, send both representations in one array.
 - **Select App method:** use `acr_values` (e.g., `mid_al3_mobileapp`) when you want to ensure App UX.
 - **Prefix rule:** include your DTBD prefix in the value of the first pair.
 - **Respect byte limits:** limits are in bytes, not characters; UTF-8 non-ASCII uses 2–4 bytes.

docs/oidc-integration-guide/passkey-authentication.md

@@ -186,9 +186,11 @@ To receive passkey-related claims, add the `mid_passkey` scope to the authorizat
 | | `mid_pk_cred_fingerprint` | string | `pQECAyYgASFY...` | SHA-256 of the credential public key ([COSE](https://datatracker.ietf.org/doc/html/rfc9052) format) |
 | | `mid_pk_auth_attachment` | string | `platform` \| `cross-platform` | Authenticator attachment modality |
 | | `mid_pk_os_family` | string | `iOS` \| `Android` \| `Windows` | OS family of the authenticator platform |
+| | `mid_pk_aal3` | boolean | `true` | Whether the authenticator used in the transaction is NIST AAL3-compliant |
 
 ::: tip Claim delivery and availability
 The `mid_pk_keyringid` claim is also available via the `mid_profile` scope, allowing RPs to retrieve the KeyRingID without requesting the full `mid_passkey` scope.
+The signer certificate chain claim `mid_profile_signer_cert_chain` is delivered via `mid_profile` scope (not `mid_passkey`).
 
 **ID Token** should carry the minimal set of claims needed for cryptographic proof (sub, iss, aud, acr, amr, nonce, etc.). **UserInfo endpoint** is the recommended delivery channel for passkey detail claims, as they may change and can be verbose.