12.2.2. Flusso di Prossimità¶
Questa sezione descrive come un'Istanza di Relying Party richiede la presentazione di un Attestato Elettronico mdoc-CBOR a un'Istanza del Wallet come dettagliato nella Specifica ISO 18013-5.
La fase di presentazione di alto livello è strutturata in tre ampie sotto-fasi come illustrato nella figura seguente:
Fig. 12.13 Flusso di Presentazione di Alto Livello in prossimità.¶
Le sotto-fasi sono descritte di seguito:
1. Device Engagement: Questa sottofase inizia quando l'Utente viene invitato a divulgare attributi specifici dagli mdoc. L'obiettivo di questa sottofase è stabilire un canale di comunicazione sicuro tra l'Istanza del Wallet e l'Istanza di Relying Party, in modo che le richieste e le risposte mdoc possano essere scambiate durante la sottofase di comunicazione. I messaggi scambiati in questa sottofase sono trasmessi attraverso tecnologie a corto raggio per limitare la possibilità di monitorarli o intercettarli da parte di terzi. I dati di Device Engagement possono essere trasferiti utilizzando QR code o NFC.
2. Session Establishment: Durante la fase di Session Establishment, l'Istanza di Relying Party configura una connessione sicura. Tutti i dati trasmessi su questa connessione sono cifrati utilizzando una chiave di sessione, che è nota sia all'Istanza del Wallet che all'Istanza di Relying Party. La sessione stabilita PUÒ essere successivamente terminata in base alle condizioni dettagliate in [ISO18013-5 #12.2.4].
1. Comunicazione - Device Retrieval: L'Istanza di Relying Party cifra la Richiesta mdoc con la chiave di sessione appropriata e la invia all'Istanza del Wallet insieme alla sua chiave pubblica nel messaggio di Session Establishment. L'Istanza del Wallet utilizza i dati del messaggio di Session Establishment per derivare la chiave di sessione e quindi per decifrare la Richiesta mdoc. Durante la sottofase di comunicazione, l'Istanza di Relying Party ha l'opzione di richiedere informazioni dall'Istanza del Wallet utilizzando richieste e risposte mdoc. La modalità principale di comunicazione è il canale sicuro stabilito durante la configurazione della sessione. L'Istanza del Wallet cifra la Risposta mdoc utilizzando la chiave di sessione e la trasmette all'Istanza di Relying Party mobile tramite un messaggio di Session Data.
Le Istanze di Relying Party e Wallet registrate nell'ecosistema IT-Wallet DEVONO supportare almeno:
Flusso di Recupero del Dispositivo Supervisionato dove un supervisore umano supervisiona il processo di verifica in persona, in contrasto con il flusso non supervisionato dove la verifica potrebbe avvenire attraverso sistemi automatizzati senza supervisione umana (WP_095).
Autenticazione dell'Istanza di Relying Party seguendo i meccanismi definiti nella ISO18013-5 per il reader authentication (WP_098).
Tipo di Documento domestico e Namespace definiti in questa specifica tecnica in aggiunta a quelli già definiti nell'ISO18013-5 per l'mDL (vedi Attestato Elettronico in formato mdoc-CBOR per maggiori dettagli) (WP_099).
Validazione dell'Istanza del Wallet attraverso l'Attestato del Wallet.
La tabella seguente mostra le tecnologie di Device Engagement supportate (WP_097), specificando quali sono obbligatorie.
Tecnologia di trasmissione |
ISO 18013-5 |
ISO 18013-5 |
IT Wallet |
IT Wallet |
|---|---|---|---|---|
Istanza del Wallet |
Istanza di Relying Party |
Istanza del Wallet |
Istanza di Relying Party |
|
QR code |
Ca |
M |
DEVE |
C – DEVE se il dispositivo è dotato di una fotocamera o lettore QR code e BLE. |
NFC |
Ca |
M |
RACCOMANDATO |
C – DEVE se il dispositivo è dotato di un lettore NFC. |
Legenda: C = Condizionale | M = Obbligatorio | a Il supporto per almeno uno di questi metodi è obbligatorio (WP_097a)
La tabella seguente mostra le tecnologie di Device Retrieval supportate, specificando quali sono obbligatorie.
Tecnologia di trasmissione |
ISO 18013-5 |
ISO 18013-5 |
IT Wallet |
IT Wallet |
|---|---|---|---|---|
Istanza del Wallet |
Istanza di Relying Party |
Istanza del Wallet |
Istanza di Relying Party |
|
BLE |
Ca |
M |
DEVE |
C – DEVE se il dispositivo è dotato di una fotocamera o lettore QR code e BLE. |
NFC |
Ca |
M |
RACCOMANDATO |
C – DEVE se il dispositivo è dotato di un lettore NFC. |
Legenda: C = Condizionale | M = Obbligatorio | a Il supporto per almeno uno di questi metodi è obbligatorio (WP_096b)
Nota
Dalla seconda edizione, versione 3, ISO18013-5 non definisce o supporta Server Retrieval come opzione di trasporto. Sono specificati solo metodi di recupero di prossimità (NFC, BLE e opzionalmente Wi-Fi Aware) (WP_096). Pertanto, Server Retrieval non è considerato in questo flusso (WP_096a and PPR-023).
La figura seguente illustra il flusso di basso livello conforme a ISO 18013-5 per il flusso di prossimità.
Fig. 12.14 Flusso di Presentazione di Basso Livello in prossimità.¶
Passo 1: L'Utente apre l'Istanza del Wallet avviando il processo.
Passo 2: L'Utente si autentica all'Istanza del Wallet. Questo può essere fatto dall'Istanza del Wallet o da un Wallet Secure Cryptographic Application (WSCA). È un prerequisito per accedere ai dati sensibili e presentare attributi (WP_100).
Passo 3: L'Utente seleziona la funzionalità di presentazione di prossimità.
Passo 4: [Opzionale] Se l'autenticazione iniziale nel Passo 2 non è stata effettuata tramite WSCA, PUÒ essere richiesta un'autenticazione separata tramite WSCA (WP_100).
Passo 5: L'Istanza del Wallet genera una nuova coppia di chiavi effimera per la comunicazione sicura (WP_101). La chiave pubblica (EDeviceKey.Pub) sarà scambiata con l'Istanza di Relying Party per derivare una chiave di sessione condivisa, successivamente utilizzata per cifrare la sessione (processo di Device Engagement).
Box A
L'Istanza del Wallet e l'Istanza di Relying Party scambiano dati di Device Engagement tramite QR code o tramite NFC Connection Handover (WP_097).
Fare riferimento a:
Sez 8.2.2.1 per
DeviceEngagementtramite QR codeSez 8.2.2.2 per
DeviceEngagementtramite NFC
Passo 6: L'Istanza di Relying Party genera la sua coppia di chiavi effimera (EReaderKey.Priv, EReaderKey.Pub). La chiave privata (EReaderKey.Priv) DEVE essere mantenuta segreta, e la chiave pubblica (EReaderKey.Pub) DEVE essere utilizzata nel Session Establishment (PPR-002).
Passo 7: L'Istanza del Wallet e l'Istanza di Relying Party DEVONO derivare indipendentemente le chiavi di sessione utilizzando la loro chiave effimera privata e la chiave effimera pubblica dell'altra parte attraverso un Key Agreement Protocol opportuno. Questo garantisce lo scambio di messaggi cifrati nella sessione. In questo particolare passo, l'Istanza di Relying Party DEVE calcolare la sua chiave di sessione (PPR-002 and WP_097).
Passo 8: L'Istanza di Relying Party DEVE preparare il SessionEstablishment. Questo messaggio DEVE essere firmato dall'Istanza di Relying Party (autenticazione dell'mdoc reader come specificato in [ISO18013-5 #12.5]) e cifrato utilizzando la chiave di sessione derivata nel passo precedente. Il messaggio SessionEstablishment DEVE includere la EReaderKey.Pub e una richiesta per specifici attributi (PPR-002).
Di seguito è riportato un esempio non normativo nella notazione diagnostica di un messaggio SessionEstablishment CBOR che contiene una Richiesta mdoc per una Wallet Attestation insieme a un Attestato Elettronico mDL.
{
"version": "1.0", % Version
"docRequests":
[
{
"itemsRequest":
24(<< % Embedded CBOR data item
{
"docType": "org.iso.18013.5.1.mDL",
"nameSpaces":
{
"org.iso.18013.5.1":
{
"family_name": true,
"document_number": true,
"driving_privileges": true,
"issue_date": true,
"expiry_date": true,
"portrait": false
}
}
}
>>)
},
{
"itemsRequest":
24(<< % Embedded CBOR data item
{
"docType": "it.wallet.trust-registry.WalletAttestation",
}
>>)
}
],
"readerAuthAll":
[
h'a10126', % COSE_Sign1 authentication header
{
33: h'308201253081cda00302010202012a300a06082a8648ce3d0403023020311e301c06035504030c15536f6d652052656164657220417574686f72697479301e170d3233313132343130323832325a170d3238313132323130323832325a301a3118301606035504030c0f536f6d6520526561646572204b65793059301306072a8648ce3d020106082a8648ce3d03010703420004aa1092fb59e26ddd182cfdbc85f1aa8217a4f0fae6a6a5536b57c5ef7be2fb6d0dfd319839e6c24d087cd26499ec4f87c8c766200ba4c6218c74de50cd1243b'
},
null, % No additional reader authentication
h'58a0d421a7e53b7db0412a196fea50ca6d4c8a530a47dd84d88588ab145374bd0ab2a724cf2ed2facf32c7184591c5969efd53f5aba63194105440bc1904e1b9' % Reader authentication signature
]
}
Box B
L'Istanza di Relying Party DEVE trasmettere il messaggio SessionEstablishment cifrato e firmato all'Istanza del Wallet su una connessione NFC o BLE sicura stabilita sulla base delle informazioni contenute nel Device Engagement (PPR-003).
Fare riferimento a:
Sez 8.2.2.3 per
SessionEstablishmenttramite BLE, eSez 8.2.2.5 per
SessionEstablishmenttramite NFC
Passo 9: L'Istanza del Wallet DEVE calcolare la chiave di sessione, come descritto nel Passo 7 (PPR-002).
Passo 10: Al ricevimento del SessionEstablishment, l'Istanza del Wallet DEVE decifrarlo utilizzando la chiave di sessione calcolata al Passo 9 e DEVE verificare la firma dell'Istanza di Relying Party (come specificato in [ISO18013-5 #12.5 mdoc reader authentication]) per garantire l'autenticità del messaggio (PPR-002 and WP_105–106).
Passo 11: L'Istanza del Wallet DEVE decifrare la richiesta di attributi e DEVE chiedere all'Utente il consenso per il rilascio degli attributi richiesti (WP_107). DEVE inoltre visualizzare il contenuto del Certificato di Registrazione della Relying Party per garantire l'autenticità, la trasparenza sui dati richiesti e sul suo scopo registrato (WP_107b).
Passo 12: L'Utente esamina la richiesta e le informazioni di registrazione della Relying Party e quindi approva la presentazione degli attributi richiesti.
Box C
Dopo aver ricevuto l'approvazione dell'Utente, l'Istanza del Wallet DEVE recuperare gli Attestati Elettronici mdoc richiesti (PPR-006 and WP_108). Deve quindi preparare un messaggio SessionData contenente questi Attestati Elettronici Digitali, e DEVE firmare i dati di autenticazione richiesti (come parte del processo di autenticazione mdoc, come specificato in [ISO18013-5 #12.4]) come specificato in (WP_109–110). L'Istanza del Wallet DEVE cifrare il SessionData utilizzando la chiave di sessione stabilita prima di trasmetterlo all'Istanza di Relying Party tramite il canale sicuro (WP_111). La firma garantisce il binding del dispositivo e l'integrità dei dati. La risposta mdoc DEVE essere codificata in CBOR, con la sua struttura delineata in [ISO18013-5 #10.3] (PPR-029, PPR-030, and WP_112).
Fare riferimento a (WP_112a–112b):
Sez 8.2.2.4 per
SessionDatatramite BLE, eSez 8.2.2.5 per
SessionDatatramite NFC
Di seguito è riportato un esempio non normativo di SessionData nella notazione diagnostica che contiene la Risposta mdoc di una Wallet Attestation e un Attestato Elettronico mDL.
{
"version": "1.0",
"documents":
[
{
"docType": "org.iso.18013.5.1.mDL",
"issuerSigned":
{
"nameSpaces":
{
"org.iso.18013.5.1":
[
24(<<
{
"digestID": 0,
"random": h'790401ed5d0822d1aced942e4b0c41f754eee67b89c5ee3b8fd2c97491a96406',
"elementIdentifier": "family_name",
"elementValue": "Rossi"
}
>>),
24(<<
{
"digestID": 3,
"random": h'0c8f68d1ec3aa445ef68aa10b7a5875fa18ca222a821e23890a227cdc7d25e8f',
"elementIdentifier": "issue_date",
"elementValue": 1004(2025-03-27)
}
>>),
24(<<
{
"digestID": 4,
"random": h'0a9ed0d4937673152e52fb3fac0722baf4252e0d0c9869919e3339670203178e',
"elementIdentifier": "expiry_date",
"elementValue": 1004(2030-03-27)
}
>>),
24(<<
{
"digestID": 8,
"random": h'88e94c0365c611b523518d9a1b179ae52e242383576249f4965c40c6c97cf214',
"elementIdentifier": "document_number",
"elementValue": "XX1234567"
}
>>),
24(<<
{
"digestID": 9,
"random": h'944758b43602b01ad68911b062349845492c04c6a78129bcf8cb5fb1396af2fc',
"elementIdentifier": "portrait",
"elementValue": h'ffd8ffe000104a46494600010101009000900000ffdb004300130d0e110e0c
13110f11151413171d301f1d1a1a1d3a2a2c2330453d4947443d43414c566d5d4c51685241435f82
606871757b7c7b4a5c869085778f6d787b76ffdb0043011415151d191d381f1f38764f434f767676
76767676767676767676767676767676767676767676767676767676767676767676767676767676
76767676767676ffc00011080018006403012200021101031101ffc4001b00000301000301000000
000000000000000005060401020307ffc40032100001030303020502030900000000000001020304
0005110612211331141551617122410781a1163542527391b2c1f1ffc40015010101000000000000
00000000000000000001ffc4001a110101010003010000000000000000000000014111213161ffda
000c03010002110311003f00a5bbde22da2329c7d692bc7d0d03f52cfb0ff75e7a7ef3e7709723a1
d0dae146ddfbb3c039ce07ad2bd47a7e32dbb8dd1d52d6ef4b284f64a480067dfb51f87ffb95ff00
eb9ff14d215de66af089ce44b7dbde9cb6890a2838eddf18078f7add62d411ef4db9b10a65d6b95a
147381ea0d495b933275fe6bba75c114104a8ba410413e983dff004f5af5d34b4b4cde632d0bf1fd
1592bdd91c6411f3934c2fa6af6b54975d106dcf4a65ae56e856001ebc03c7ce29dd9eef1ef10fc4
47dc9da76ad2aee93537a1ba7e4f70dd8eff0057c6dffb5e1a19854a83758e54528750946ec67048
50cd037bceb08b6d7d2cc76d3317fc7b5cc04fb6707269c5c6e0c5b60ae549242123b0e493f602a0
75559e359970d98db89525456b51c951c8afa13ea8e98e3c596836783d5c63f5a61a99fdb7290875
db4be88ab384bbbbbfc7183fdeaa633e8951db7da396dc48524fb1a8bd611a5aa2a2432f30ab420a
7a6d3240c718cf031fa9ef4c9ad550205aa02951df4a1d6c8421b015b769db8c9229837ea2be8b1b
0d39d0eba9c51484efdb8c0efd8d258daf3c449699f2edbd4584e7af9c64e3f96b9beb28d4ac4093
1e6478c8e76a24a825449501d867d2b1dcdebae99b9c752ae4ecd6dde4a179c1c1e460938f9149ef
655e515c03919a289cb3dca278fb7bf177f4faa829dd8ce3f2ac9a7ecde490971fafd7dce15eed9b
71c018c64fa514514b24e8e4f8c5c9b75c1e82579dc1233dfec08238f6add62d391acc1c5256a79e
706d52d431c7a0145140b9fd149eb3a60dc5e88cbbc2da092411e9dc71f39a7766b447b344e847dc
ac9dcb5abba8d145061d43a6fcf1e65cf15d0e90231d3dd9cfe62995c6dcc5ca12a2c904a15f71dd
27d451453e09d1a21450961cbb3ea8a956433b781f1ce33dfed54f0e2b50a2b71d84ed6db18028a2
8175f74fc6bda105c529a791c25c4f3c7a11f71586268f4a66b726e33de9ea6f1b52b181c760724e
47b514520a5a28a283ffd9'
}
>>),
24(<<
{
"digestID": 10,
"random": h'577e4822125f55fe923117aba01fdaefcc67d4aea80018fc22efa8d48e17982f',
"elementIdentifier": "driving_privileges",
"elementValue": [
{
"vehicle_category_code": "A",
"issue_date": 1004("2020-09-17"),
"expiry_date": 1004("2031-06-10")
}
]
}
>>)
]
},
"issuerAuth":
[
<< {1: -7} >>,
{
33: h'30820208308201afa00302010202142eb39c647c81836bcf79fa9cd0b201ec0bf52307300a0
6082a8648ce3d0403023064310b30090603550406130255533113301106035504080c0a43616c6966
6f726e69613116301406035504070c0d53616e204672616e636973636f31133011060355040a0c0a4
d7920436f6d70616e793113301106035504030c0a6d79736974652e636f6d301e170d323530333237
3135353532305a170d3235303430363135353532305a3064310b30090603550406130255533113301
106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e63697363
6f31133011060355040a0c0a4d7920436f6d70616e793113301106035504030c0a6d79736974652e6
36f6d3059301306072a8648ce3d020106082a8648ce3d03010703420004f33da72d0dd0009b62221b
0e839099b12dab5e01021124ebf9060422e648f3c3ec6614a86da1e91e552b2ae35e04d3058ae82b5
c65a7f1f26800cb4499652a09a33f303d303b0603551d1104343032863068747470733a2f2f637265
64656e7469616c2d6973737565722e6f6964632d66656465726174696f6e2e6f6e6c696e65300a060
82a8648ce3d040302034700304402204d1f0819971652b79ebe4825547de3d5554d2f41410225e6b1
3dab949cda125e022079ba71b823619e49719dce5daa565bf745d3d97e2b87c7f7d6a626f981e653ed'
},
<<
24(<<
{
"version": "1.0",
"digestAlgorithm": "SHA-256",
"docType": "org.iso.18013.5.1.mDL",
"valueDigests": {
"org.iso.18013.5.1":
{
0: h'f46b65d5060ad060ab9be62ff22ea8633437619ebdc7fa81f2d151159e92bffe',
1: h'e506545f6a6fd5d982670b4d62fc2b0688dc8f26754e7b0c574d63f5d72a85ac',
2: h'cfcf96fa12d100eeed5f00183d3b6a0888baa47eae85b5b95037eca7bbc0d07e',
3: h'8b0772252b0e06b611676b6b3402eb33bf866eb145e49f4d5f23215e6a047772',
4: h'14135c96693e2ab08d956876ee491357d906a6dd125557196dfb9811ba54aa8d',
5: h'86dcbd99233fbb84a9a2dce3a864a425e6e809300067a4475e3ea2a4d233dc74',
6: h'2e9512d35ea225e69e7b2180ecc1678dcc3e77a16e36427e64b4f0e2861b4d3a',
7: h'4efe55c36f6249d23c473a125afc5181aa30633936494781554971b72ff13700',
8: h'cc44a4f9983c5b0b1efc0e82e2867c8d5bbdf89c34bff16a1953c923bb4e4b3e',
9: h'775eb2af0aa55f2071d62662b35c99698ae3bc0e2c4af5724ff88476cddd152f',
10: h'915d0ad53dd23dace34968c263d307c04701a9bb9dc9865af91dc409786fd833',
11: h'47d89ff4fb513044e6f2394236755ac0abf3e4f4a46f40454a458a59f8b7a6fb'
},
"org.iso.18013.5.1.IT": {
12: h'd665c50c4364c7cbf4ab9461b9bbb228f37ad278b9fb61283550951624d4d9ae',
13: h'dc9d032a64866e33d06f48a882989b5747da3638f0d216a2275191ed3395fdec'
}
},
"deviceKeyInfo": {
"deviceKey": {
1: 2,
-1: 1,
-2: h'f96b29873b61f05403e2963a7ecbc799c9aab28d8a6629e5848cfdef85442866',
-3: h'a9fef033a900c63e3894d8deb805a2a1fb55ef0d2b88e3c0d3336408186485ef'
}
},
"validityInfo": {
"signed": 0("2025-03-27T00:00:00Z"),
"validFrom": 0("2025-03-27T00:00:00Z"),
"validUntil": 0("2026-03-27T00:00:00Z")
},
"status": {
"status_list": {
"idx": 1340,
"uri": "https://statusprovider.example.org/statuslists/1"
}
}
}
>>)
>>,
h'd09f9acdf7a6be5e4aeb405bfb3b297b1b8003bcf52558a2f39fc6e5cffed40f18f49d2cc0e72a2a5645
8d8aade591dee8d6540e639bca637f94bd9fa56f345c'
]
},
"deviceSigned":
{
"nameSpaces": 24(<< {} >>),
"deviceAuth":
{
"deviceSignature":
[
<< {1: -7} >>,
{},
null,
h'E99521A85AD75943BF5AEAE68943BF5AE249943BF5AE943BF5AE43BF5AEDE99521A85AD75943BF5AEAE
68943BF5AE249943BF5AE943BF5AE43BF5AED'
]
}
}
},
{
"docType": "it.wallet.trust-registry.WalletAttestation",
"issuerSigned": {
"nameSpaces": {
"it.wallet.trust-registry.WalletAttestation": [
24(<<
{
"digestID": 0,
"elementIdentifier": "aal",
"elementValue": "https://wallet-provider.example.org/LoA/basic",
"random": h'bbc6b4df4282424ed5753b4218863923ab3256cb831822601d95a5806e2bd114'
}
>>),
24(<<
{
"digestID": 1,
"elementIdentifier": "sub",
"elementValue": "ec#1",
"random": h'0117942b3ecdad65f226a668466fa175b72563a392598ad18fa6d359ea9b1b2d'
}
>>),
24(<<
{
"digestID": 2,
"elementIdentifier": "wallet_link",
"elementValue": "https://wallet-provider.example.org",
"random": h'dc9d032a64866e33d06f48a882989b5747da3638f0d216a2275191ed3395fdec'
}
>>),
24(<<
{
"digestID": 3,
"elementIdentifier": "wallet_name",
"elementValue": "Wallet name",
"random": h'd665c50c4364c7cbf4ab9461b9bbb228f37ad278b9fb61283550951624d4d9ae'
}
>>)
]
},
"issuerAuth": [
<< {1: -7} >>,
{
33: h'825903B0...'
},
<<
24(<<
{
"version": "1.0",
"digestAlgorithm": "SHA-256",
"valueDigests": {
"org.iso.18013.5.1.IT": {
0: h'2f89a12f690fe570b9b18d96acd231a70b5cb97cef5edad81973b99eeb145c2f',
1: h'7541a38f61d686f72ca8fb9da87a3db9fc65d28caa4e0973b0a3d66181ff7997',
2: h'7049c3bfcd96d62833f2fdb892b12cb6fd983b4c3bf40b0c39cb233bfeb5b75f',
3: h'ce566344e76ff543c5084e7618bdb54223ff2750dbcb4a3c7c35fd56a47a1024'
}
},
"deviceKeyInfo": {
"deviceKey": {
-1: 1,
2: "ec#1",
1: 2,
-2: h'09a9028deb030705de45e4702d1ce6860e94c0e29f334359a476078c2d22b9c5',
-3: h'6b972cd32c19cd5e8c19e051f1e207cabb3c2a802abf40ee5baaaa4a464508c3'
}
},
"docType": "org.iso.18013.5.1.IT.WalletAttestation",
"validityInfo": {
"signed": 0("2025-06-27T07:40:21Z"),
"validFrom": 0("2025-06-27T07:40:21Z"),
"validUntil": 0("2025-06-27T08:40:21Z")
}
}
>>)
>>
h'97f223fd4c9c462454e4123df916dd0d672af14608727ce38470b8bd74fb496e11462113f0005d3e97bf6115074712991e1720eb085292edd894a116a305310c'
]
},
"deviceSigned":
{
"nameSpaces": 24(<< {} >>),
"deviceAuth":
{
"deviceSignature":
[
<< {1: -7} >>,
{},
null,
h'E99521A85AD75943BF5AEAE68943BF5AE249943BF5AE943BF5AE43BF5AEDE99521A85AD75943
BF5AEAE68943BF5AE249943BF5AE943BF5AE43BF5AED'
]
}
}
}
],
"status": 0
}
Passo 13: L'Istanza di Relying Party riceve il SessionData, quindi DEVE decifrarlo e DEVE verificare la firma dell'Istanza del Wallet per garantire l'integrità dei dati e che provengano dal dispositivo previsto (device binding). DEVE anche controllare la validità dell'mdoc, inclusa la firma del suo Fornitore di Attestati Elettronici. In caso di Attestati Elettronici Digitali di lunga durata, DOVREBBE anche controllare lo stato di revoca utilizzando il TOKEN-STATUS-LIST.
Passo 14: Una volta completato lo scambio di dati, una delle parti può terminare la sessione. La sessione può essere terminata inviando lo status code per la Session Termination in un messaggio SessionData; questo può essere inviato insieme a una la Richiesta mdoc o Risposta mdoc [ISO18013-5 #12.2.4] (WP_113c). Se viene utilizzato BLE, questo può comportare l'invio di uno status code per la Session Termination o il comando "End". In questo scenario, il Client GATT (Istanza di Relying Party) DEVE annullare l'iscrizione dalle caratteristiche e disconnettersi dal server GATT (Istanza del Wallet) (PPR-007, WP_113b, and WP_114).
Considerazione Finale: Il flusso di presentazione si è concentrato sullo scambio tecnico di dati in contesti di prossimità. È cruciale riconoscere che i flussi di prossimità supervisionati che coinvolgono un verificatore umano svolgono un ruolo vitale in molti casi d'uso (ad esempio, verifica dell'età in un negozio, controllo dell'identità da parte delle forze dell'ordine). L'elemento umano aggiunge un livello di verifica dell'identità attraverso l'ispezione visiva e il confronto, contribuendo agli aspetti di User Binding e garanzia di autenticazione complessiva non completamente catturati in un flusso di presentazione puramente tecnico.
Nota
Durante la presentazione di prossimità l'Istanza del Wallet potrebbe non essere in grado di recuperare una Wallet Attestation aggiornata, in questo caso, l'Istanza del Wallet DOVREBBE inviare l'ultima versione della Wallet Attestation (WP_108a). È demandato alla Relying Party di determinare se una presentazione con una Wallet Attestation valida ma scaduto è valida o meno.
12.2.2.1. DeviceEngagement tramite QR Code¶
La figura seguente illustra il flusso di basso livello conforme a ISO 18013-5 per DeviceEngagement tramite QR Code corrispondente al Box A nella Figura Flusso di Presentazione di Basso Livello in prossimità..
Fig. 12.15 Device Engagement tramite QR Code.¶
Passo 1: L'Istanza del Wallet presenta un QR Code all'Istanza di Relying Party. Il QR code DEVE contenere un URI con "mdoc:" come schema e la struttura DeviceEngagement specificata nella Sezione 9.1 codificata utilizzando, come percorso, base64url-without-padding, secondo RFC 4648 (WP_102a).
12.2.2.1.1. Esempio Non Normativo con BLE come Device Retrieval¶
Di seguito è riportato un esempio non normativo di``DeviceEngagement`` nella notazione diagnostica che utilizza QR per il Device Engagement e Bluetooth Low Energy (BLE) per il recupero dei dati.
{ 0: "1.1", % Version (Updated to 1.1 because Capabilities and OriginInfos are present) 1: % Security [ 1, % defines the cipher suite , which contains only EC curves 24(<< % embedded CBOR data item { 1: 2, % kty:EC2 (Elliptic curves with x and y coordinate pairs) -1: 1, % crv:p256 -2:h'5A88D182BCE5F42EFA59943F33359D2E8A968FF289D93E5FA444B624343167FE', % x-coordinate -3:h'B16E8CF858DDC7690407BA61D4C338237A8CFCF3DE6AA672FC60A557AA32FC67' % y-coordinate } >>) ], 2: % DeviceRetrievalMethods (Device engagement using QR code with BLE for retrieval) [ [ 2, % BLE 1, % Version { % BLE options 0: false, % no support for mdoc peripheral server mode 1: true, % support for mdoc central client mode 11: h'45EFEF742B2C4837A9A3B0E1D05A6917' % UUID of mdoc client central mode } ] ], 5: % OriginInfos (Required because Capabilities is present) [], 6: % Capabilities (Defines supported features) { 2: false, % HandoverSessionEstablishmentSupport (Supports negotiated handover) 3: true % ReaderAuthAllSupport (Supports reader authentication) } }
12.2.2.1.2. Esempio Non Normativo con NFC come Device Retrieval¶
Di seguito è riportato un esempio non normativo di DeviceEngagement nella notazione diagnostica che utilizza QR per il Device Engagement e NFC per il recupero dei dati.
{ 0: "1.1", % Version (Updated to 1.1 because Capabilities and OriginInfos are present) 1: % Security [ 1, % defines the cipher suite , which contains only EC curves 24(<< % embedded CBOR data item { 1: 2, % kty:EC2 (Elliptic curves with x and y coordinate pairs) -1: 1, % crv:p256 -2:h'5A88D182BCE5F42EFA59943F33359D2E8A968FF289D93E5FA444B624343167FE', % x-coordinate -3:h'B16E8CF858DDC7690407BA61D4C338237A8CFCF3DE6AA672FC60A557AA32FC67' % y-coordinate } >>) ], 2: % DeviceRetrievalMethods (Device engagement using QR code with BLE for retrieval) [ [ 1, % NFC 1, % Version { % NFC options 0: uint, % Maximum length of command data field 1: uint, % Maximum length of response data field } ] ], 5: % OriginInfos (Required because Capabilities is present) [], 6: % Capabilities (Defines supported features) { 2: false, % HandoverSessionEstablishmentSupport (Supports negotiated handover) 3: true % ReaderAuthAllSupport (Supports reader authentication) } }
Passo 2: Il verificatore utilizza la sua Istanza di Relying Party per scansionare il QR code e recuperare i dati DeviceEngagement dall'mdoc. Esso DEVE selezionare una delle tecnologie di trasmissione tra quelle fornite nella struttura DeviceEngagement.
12.2.2.2. DeviceEngagement tramite NFC¶
La figura seguente illustra il flusso di basso livello conforme a ISO 18013-5 per DeviceEngagement tramite NFC corrispondente al Box A nella Figura Flusso di Presentazione di Basso Livello in prossimità. (WP_103).
Fig. 12.16 Device Engagement tramite NFC.¶
DeviceEngagement tramite NFC è basato su NFC Forum Connection Handover Technical Specification, Versione 1.5. È supportata solo la modalità Reader/Writer utilizzando un Tag di Tipo 4. Il protocollo Connection Handover è sempre avviato dall'Istanza di Relying Party, che assume il ruolo di Handover Requester. L'Istanza del Wallet agisce come NFC Tag Device e l'Istanza di Relying Party come NFC Reader Device. L'Istanza del Wallet DEVE utilizzare Static Handover o Negotiated Handover:
- Static Handover: L'Istanza di Relying Party recupera un messaggio Handover Select direttamente dal Tag di Tipo 4 dell'Istanza del Wallet. Questo messaggio contiene almeno un Alternative Carrier Record, ognuno indicante un metodo di recupero supportato dall'Istanza del Wallet (WP_103a). L'Istanza di Relying Party DEVE selezionare una di queste tecnologie di trasmissione. (vedere Passo 1)
- Negotiated Handover: L'Istanza del Wallet include il servizio urn:nfc:sn:handover in un Service Parameter Record del messaggio NDEF (NFC Data Exchange Format) iniziale (WP_103b). Selezionando questo servizio, l'Istanza di Relying Party invia una Handover Request con un Alternative Carrier Record per ogni carrier che supporta. L'Istanza del Wallet risponde con un messaggio Handover Select contenente esattamente un carrier selezionato. (Vedere Passi 2-4)
Passo 1: L'Istanza di Relying Party legge il Tag NFC di Tipo 4 del Wallet per ottenere un messaggio Handover Select, che include: - Alternative Carrier Record: un record NDEF all'interno di un messaggio Handover Select o Handover Request. Punta a una possibile tecnologia di comunicazione (chiamata "carrier"), come NFC o BLE. Informa il lettore sul carrier supportato e un puntatore (Auxiliary Data Reference) a informazioni più dettagliate. L'Alternative Carrier Record per la tecnologia di trasmissione Device Retrieval NFC deve fare riferimento al Carrier Configuration Record con il riferimento ID "nfc". - Carrier Configuration Record: fornisce i parametri tecnici necessari per utilizzare effettivamente quel carrier. Per la tecnologia di trasmissione Device Retrieval NFC, DEVE avere il tipo "iso.org:18013:nfc" e il riferimento ID "nfc". Il contenuto binario del Carrier Configuration Record DEVE essere codificato secondo la Tabella 1 di [ISO18013-5 #9.2.2] (WP_103d).
Per esempio:
Per NFC, questo definisce le lunghezze massime di comando/risposta APDU (Application Protocol Data Unit);
Per BLE, definisce l'UUID del servizio dell'Istanza del Wallet, gli UUID delle caratteristiche, la dimensione MTU (Maximum Transmission Unit) e parametri di connessione opzionali;
Se è supportato il SessionEstablishment anticipato, elenca anche il nome del servizio TNEP (Tag NDEF Exchange Protocol) utilizzato per inviare il messaggio SessionEstablishment durante l'handover.
Nota
Per la tecnologia di trasmissione Device Retrieval NFC, i contenuti dell'Alternative Carrier Record e del/dei Carrier Configuration Record DEVONO essere conformi a [ISO18013-5 #9.2.2]. Per la tecnologia di trasmissione Device Retrieval BLE, i contenuti dell'Alternative Carrier Record e del/dei Carrier Configuration Record devono essere conformi a [ISO18013-5 #11.1.2].
Auxiliary Data Record DEVE trasportare la struttura
DeviceEngagementdall'Istanza del Wallet all'Istanza di Relying Party come parte del record NDEF ausiliario nel messaggio Handover Select. Questo record ha il tipoiso.org:18013:deviceengagement, il riferimento ID "mdoc", e utilizza il formato di tipo esterno del forum NFC (0x04). Per ogni record Alternative Carrier, l'Auxiliary Data Reference DEVE puntare al record NDEF contenente la StrutturaDeviceEngagement(WP_103e).
Passo 2: L'Istanza di Relying Party legge il messaggio NDEF (NFC Data Exchange Format) Iniziale dell'Istanza del Wallet, che contiene un service parameter record per urn:nfc:sn:handover, indicando che il Wallet supporta Negotiated Handover.
Passo 3: L'Istanza di Relying Party invia una Handover Request all'Istanza del Wallet elencando i carrier supportati.
Passo 4: L'Istanza del Wallet restituisce Handover Select costruito in risposta al messaggio Handover Request ricevuto. I contenuti del messaggio Handover Select sono gli stessi del Passo 1 (WP_103f).
Nota
L'uso di Negotiated Handover per il Device Engagement consente la negoziazione dei metodi di trasferimento. Per BLE, consente inoltre la negoziazione delle chiavi utilizzate dal livello di trasmissione. Questo fornisce un'esperienza utente migliorata e migliora la sicurezza della trasmissione dei dati [ISO18013-5 #9.2.1].
Nota
Procedere solo se le Capabilities di DeviceEngagement includono HandoverSessionEstablishmentSupport impostato su true (WP_103c). Altrimenti, saltare il SessionEstablishment anticipato. Il SessionEstablishment anticipato viene inviato tramite un servizio TNEP dedicato; lo stesso SessionEstablishment DEVE anche essere inviato nuovamente durante il Device Retrieval e DEVE corrispondere. Se non corrisponde, l'Istanza del Wallet termina (WP_103g). Se il SessionEstablishment anticipato non riesce a essere inviato, procedere normalmente (WP_103h).
Passo 5: [Opzionale] L'Istanza di Relying Party apre il servizio TNEP denominato [urn:placeholder] con l'Istanza del Wallet durante l'handover negoziato per consegnare il messaggio SessionEstablishment anticipato.
Passo 6: L'Istanza di Relying Party invia SessionEstablishment (ad esempio, EReaderKey + DeviceRequest cifrato). L'Istanza del Wallet lo elabora; il Device Retrieval non è ancora iniziato.
Passo 7: L'Istanza di Relying Party chiude il servizio TNEP.
Nota
Se un messaggio SessionEstablishment opzionale viene inviato durante Negotiated Handover (Passo 5), l'Istanza del Wallet DEVE verificare che corrisponda al messaggio SessionEstablishment ricevuto durante Device Retrieval (utilizzando BLE o canale sicuro NFC). Questa verifica è richiesta per garantire un corretto Session Binding.
12.2.2.2.1. Esempio Non Normativo¶
- Di seguito è riportato un esempio non normativo di una struttura
DeviceEngagementper Device Retrieval tramite BLE e NFC. { 0: "1.1", % Version (Updated to 1.1 because Capabilities and OriginInfos are present) 1: % Security [ 1, % defines the cipher suite , which contains only EC curves 24(<< % embedded CBOR data item { 1: 2, % kty:EC2 (Elliptic curves with x and y coordinate pairs) -1: 1, % crv:p256 -2:h'5A88D182BCE5F42EFA59943F33359D2E8A968FF289D93E5FA444B624343167FE', % x-coordinate -3:h'B16E8CF858DDC7690407BA61D4C338237A8CFCF3DE6AA672FC60A557AA32FC67' % y-coordinate } >>) ], 2: % DeviceRetrievalMethods (Absent when using NFC for device engagement) [], 5: % OriginInfos (Required because Capabilities is present) [], 6: % Capabilities (Defines supported features) { 2: true, % HandoverSessionEstablishmentSupport (Supports negotiated handover) 3: true % ReaderAuthAllSupport (Supports reader authentication) } }
12.2.2.3. SessionEstablishment tramite BLE¶
La figura seguente illustra il flusso di basso livello conforme a ISO18013-5 per SessionEstablishment tramite BLE corrispondente ai Box B nella Figura 8.10.
Fig. 12.17 Session Establishment tramite BLE.¶
Passo 1: L'Istanza del Wallet e l'Istanza di Relying Party stabiliscono una connessione BLE sicura [ISO18013-5 #11.1]. L'Istanza di Relying Party (central) si connette all'Istanza del Wallet (peripheral) utilizzando l'UUID del servizio dell'Istanza del Wallet fornito da DeviceEngagement, individua servizi/caratteristiche e abilita le notifiche secondo necessità (WP_112c).
Passi 2-5: [Opzionale] L'Istanza del Wallet avvia la verifica preparandosi a controllare l'identità della Relying Party tramite la caratteristica Ident, che è una caratteristica BLE GATT che trasporta un valore identificatore come descritto in [ISO18013-5 #11.1.3.2]. L'Istanza del Wallet deriva il valore Ident atteso e legge la caratteristica Ident della Relying Party, confrontandola con l'Ident atteso, e terminando la connessione BLE qualora non vi sia corrispondenza (WP_112d).
Nota
Lo scopo della caratteristica Ident è unicamente di verificare se l'Istanza del Wallet è connessa all'Istanza di Relying Party corretta prima di iniziare il Device Retrieval. Se l'Istanza del Wallet è connessa all'Istanza di Relying Party sbagliata, il Session Establishment fallirà. Connettersi e disconnettersi a un'Istanza di Relying Party richiede una quantità relativamente grande di tempo; pertanto, è più veloce implementare metodi per identificare l'Istanza di Relying Party corretta [ISO18013-5 #11.1.3.1].
Passo 6: L'Istanza di Relying Party invia il messaggio SessionEstablishment cifrato (includendo EReaderKey e DeviceRequest cifrato) tramite la connessione BLE stabilita.
Passi 7-8: [Opzionale] Se l'Istanza del Wallet riceve il messaggio SessionEstablishment durante Negotiated Handover, l'Istanza del Wallet DEVE verificare se questo messaggio SessionEstablishment corrisponde al messaggio SessionEstablishment ricevuto durante la fase di Device Retrieval (cioè, Passo 6). In caso di mancata corrispondenza, l'Istanza del Wallet deve terminare la connessione BLE [ISO18013-5 #9.2.3].
12.2.2.4. SessionData tramite BLE¶
La figura seguente illustra il flusso di basso livello conforme a ISO18013-5 per SessionData tramite BLE corrispondente ai Box C nella Figura 8.10.
Fig. 12.18 Session Data tramite BLE.¶
Passo 1: L'Istanza del Wallet invia l'APDU finale contenente l'ultimo blocco DeviceResponse (con attributi richiesti) o uno status code, dopo il quale la sessione può terminare o continuare con una nuova richiesta.
12.2.2.5. SessionEstablishment tramite NFC¶
Nota
Se il Device Engagement viene avviato tramite un QR code, l'Istanza di Relying Party non ha un modo standardizzato per segnalare la sua intenzione di utilizzare NFC per il successivo trasferimento di dati. Questo potrebbe portare a una peggiore esperienza utente, poiché l'Utente potrebbe non essere consapevole di dover utilizzare NFC. Questo problema viene evitato quando NFC viene utilizzato per il Device Engagement, poiché stabilisce implicitamente il metodo di trasferimento dati [ISO18013-5 #8.2.5].
Nota
A causa della velocità di trasferimento dati limitata di NFC, se è richiesta una grande quantità di dati per una transazione, potrebbe non essere né pratico né ragionevole per un Utente mantenere il dispositivo all'interno del campo RF dell'Istanza di Relying Party per la durata della transazione. Inoltre, quando un dispositivo lascia il campo RF il segnale viene perso necessitando l'avvio di una nuova transazione. Questo può essere evitato facendo sì che tutte le interazioni dell'Utente con l'Istanza del Wallet vengano effettuate mentre l'Istanza del Wallet rimane nel campo RF oppure, se non sono richieste interazioni dell'Utente durante la fase di trasmissione [ISO18013-5 #8.2.5].
La figura seguente illustra il flusso di basso livello conforme a ISO18013-5 per SessionEstablishment tramite NFC corrispondente al Box B nella Figura 8.10.
Fig. 12.19 Session Establishment tramite NFC.¶
12.2.2.5.1. Definizioni (Acronimi e Comandi)¶
Acronimo/Comando |
Descrizione |
|---|---|
PICC |
Proximity Integrated Circuit Card, implementata dalle Istanze di Wallet che agiscono come tag NFC. |
PCD |
Proximity Coupling Device, implementato dalle Istanze di Relying Party utilizzando scambi APDU. |
AID |
Application Identifier, ID univoco utilizzato nel comando SELECT APDU per coinvolgere l'Istanza del Wallet. |
APDU |
Application Protocol Data Unit, un formato di messaggio standard per la comunicazione tra Istanza di Relying Party (PCD) e Wallet (PICC) costituito da Command APDU (ad esempio, SELECT, ENVELOPE, GET RESPONSE) dal lettore e Response APDU dal wallet, che includono scambio di dati e fine scambio utilizzando status words (SW1/SW2). |
SELECT APDU |
Comando che apre l'Istanza del Wallet tramite AID. La risposta include File Control Information (FCI) e Status Word (SW1/SW2). |
ENVELOPE APDU |
Comando che trasporta messaggi di sessione (ad esempio, |
GET RESPONSE APDU |
Comando che recupera dati di risposta aggiuntivi quando il Wallet segnala che "più dati" sono disponibili (SW1=61). |
SW1/SW2 |
SW1/SW2 (Status Words) — status code a due byte alla fine di ogni risposta. Valori comuni: 90 00 = successo, 61 XX = more data, 6A 82 = file/applicazione non trovata. |
Passo 1: L'Istanza di Relying Party (PCD) invia un comando SELECT APDU con l'Application Identifier (AID: A0 00 00 02 48 04 00) per coinvolgere l'Istanza del Wallet.
Passo 2: L'Istanza del Wallet (PICC) risponde con File Control Information (FCI) e status words (SW1/SW2), confermando il successo (90 00) o indicando che ci sono più dati (61 XX) (WP_112e).
Passo 3: L'Istanza di Relying Party invia un ENVELOPE APDU che trasporta il messaggio SessionEstablishment, che contiene il DeviceRequest cifrato e la sua chiave pubblica effimera per la configurazione della sessione.
Passo 4: L'Istanza del Wallet elabora SessionEstablishment e restituisce una risposta APDU con SW1/SW2 (OK o more data da recuperare), confermando l'inizio del contesto di sessione sicura (WP_112f).
Passi 5-6: [Opzionale] L'Istanza del Wallet riceve il messaggio SessionEstablishment durante Negotiated Handover, l'Istanza del Wallet DEVE verificare che questo messaggio SessionEstablishment corrisponda allo stesso messaggio ricevuto durante la fase di Device Retrieval (cioè, Passi 3-4). In caso di mancata corrispondenza, l'Istanza del Wallet DEVE terminare la connessione NFC [ISO18013-5 #9.2.3].
12.2.2.6. SessionData tramite NFC¶
La figura seguente illustra il flusso di basso livello conforme a ISO18013-5 per SessionData tramite NFC corrispondente al Box C nella Figura 8.10.
Fig. 12.20 Session Data tramite NFC.¶
Passi 1-2: Finché l'Istanza del Wallet segnala che più dati sono disponibili (61 XX), l'Istanza di Relying Party emette GET RESPONSE APDU per richiedere il blocco successivo. L'Istanza del Wallet restituisce frammenti SessionData cifrati fino a quando tutti i dati sono consegnati.
Passo 3: L'Istanza del Wallet invia l'APDU finale contenente l'ultimo blocco DeviceResponse (con attributi richiesti) o un status code, dopo il quale la sessione può terminare o continuare con una nuova richiesta.
12.2.2.7. Device Engagement¶
La struttura del Device Engagement DEVE essere codificata in CBOR e avere almeno le seguenti componenti (PPR-001, PPR-021, PPR-022, and WP_102):
Componente |
Descrizione |
|---|---|
Version |
(tstr). Versione della struttura Device Engagement. |
Security |
(array). Contiene due valori obbligatori:
|
DeviceRetrievalMode-BLEOptions |
(map). Fornisce opzioni per la connessione BLE, come modalità Peripheral Server o Central Client, e l'UUID del dispositivo. Vedere Tabella 2 di ISO18013-5 per la mappatura dettagliata. Se l'Istanza del Wallet indica durante il Device Engagement che supporta entrambe le modalità, l'Istanza di Relying Party DOVREBBE selezionare la modalità mdoc central client [ISO18013-5 #11.1.3.1]. Presente solo quando si esegue Device Engagement utilizzando il QR code. Assente quando si utilizza NFC per eseguire Device Engagement. |
DeviceRetrievalMode-NFCOptions |
(map). Fornisce opzioni per le connessioni NFC, incluso il ruolo supportato (PICC o PCD) e le dimensioni massime di comando/risposta PDU. Vedere Tabella 2 di ISO18013-5 per la mappatura dettagliata. Nel caso in cui NFC venga utilizzato per Device Retrieval, l'Istanza del Wallet DEVE supportare la modalità PICC e l'Istanza di Relying Party DEVE supportare la modalità PCD [ISO18013-5 #11.2]. Quest'ultima è presente solo quando si esegue Device Engagement utilizzando il QR code, mentre è assente quando si utilizza NFC per eseguire Device Engagement. |
Capabilities |
(map). Dichiara le capacità opzionali supportate dall'mdoc, che sono:
|
OriginInfos |
(array). Descrive l'interfaccia utilizzata per ricevere e consegnare la struttura di engagement. OriginInfos PUÒ essere un array vuoto. |
12.2.2.7.1. Richiesta mdoc¶
I messaggi nella Richiesta mdoc DEVONO essere codificati utilizzando CBOR. La stringa di byte CBOR risultante per la Richiesta mdoc DEVE essere cifrata con la Chiave di Sessione ottenuta dopo la fase di Device Engagement e DEVE essere trasmessa utilizzando il protocollo BLE o NFC (PPR-026, PPR-027, PPR-028). Ogni Richiesta mdoc DEVE essere conforme alla seguente struttura e DEVE includere i seguenti componenti, a meno che non sia specificato diversamente:
Componente |
Descrizione |
|---|---|
version |
(tstr). Versione della struttura della Richiesta mdoc. Abilita la gestione della compatibilità tra diverse versioni o profili di implementazione. |
docRequests |
(array). Ogni voce è una DocRequest contenente:
|
readerAuthAll |
(COSE_Sign1, CONDIZIONALE). Utilizzato per autenticare la Relying Party una volta per tutte le DocRequest. La firma è calcolata sui dati ReaderAuthenticationAll, come definito in [ISO18013-5 #12.5]. Questo componente DEVE essere presente solo se |
Nota
Richiesta della Wallet Attestation
La Relying Party che richiede una Wallet Attestation DEVE aggiungere un oggetto nell'array docRequest che abbia solo il campo docType impostato come {Trust Anchor reverse domain}.{WalletAttestation} (si rimanda a Struttura del Catalogo degli Attestati Elettronici per dettagli ulteriori). La Relying Party NON DEVE includere il parametro nameSpaces nella richiesta (PPR-010).
Questo componente DEVE essere presente solo se ReaderAuthAllSupport è impostato su true nel messaggio di DeviceEngagement, e i campi individuali readerAuth non vengono utilizzati (PPR-025).
12.2.2.7.2. Risposta mdoc¶
I messaggi nella Risposta mdoc DEVONO essere codificati utilizzando CBOR e DEVONO essere cifrati con la Chiave di Sessione ottenuta dopo la fase di Device Engagement (PPR-029, PPR-030).
Ogni Risposta mdoc DEVE essere conforme alla seguente struttura e DEVE includere i seguenti componenti, a meno che non sia specificato diversamente:
Componente |
Descrizione |
|---|---|
version |
(tstr). Versione della struttura Risposta mdoc. Abilita il tracciamento delle modifiche e il mantenimento della compatibilità tra versioni dello standard o profili di implementazione. |
documents |
(array of Documents, OPZIONALE). Collezione codificata CBOR di documenti restituiti in risposta alla richiesta. Ogni documento include componenti issuerSigned e deviceSigned, e segue la struttura definita in [ISO18013-5 #10.3.3]. |
documentErrors |
(map, OPZIONALE). Una mappa di codici di errore per documenti non restituiti, come definito in [ISO18013-5 #10.3.6]. Ogni chiave è un docType, e ogni valore è un ErrorCode (int) che indica il motivo per cui il documento non è stato restituito. |
status |
(uint). Status code che indica l'esito della richiesta. Ad esempio, "status": 0 significa elaborazione riuscita. Per dettagli, vedere Tabella 3 (ResponseStatus) di [ISO18013-5 #10.3.5]. |
Ogni elemento in documents DEVE essere conforme alla seguente struttura e DEVE includere i seguenti componenti, a meno che non sia specificato diversamente (PPR-029):
Componente |
Descrizione |
|---|---|
docType |
(tstr). identificativo del tipo di documento. Ad esempio, per un mDL, il valore DEVE essere |
issuerSigned |
(bstr). Contiene la struttura IssuerNameSpaces, che include elementi dati firmati dal Fornitore di Attestati Elettronici, e la struttura issuerAuth, che garantisce la loro autenticità e integrità utilizzando il Mobile Security Object (MSO). Vedere Attestato Elettronico in formato mdoc-CBOR. |
deviceSigned |
(bstr). Contiene la struttura DeviceNameSpaces (elementi dati firmati dall'Istanza del Wallet), e la struttura deviceAuth, che include i dati di autenticazione firmati dall'Istanza del Wallet. Vedere la tabella sottostante per dettagli. |
errors |
(map, OPZIONALE). Una mappa di codici di errore per ogni elemento dati non restituito raggruppato per namespace. Ogni chiave rappresenta un namespace, e ogni valore è una mappa di identificatori di elementi dati ai corrispondenti codici di errore. Vedere [ISO18013-5 #10.3.6] per dettagli sulla struttura degli errori. |
Una struttura di dati deviceSigned DEVE essere conforme alla seguente struttura e DEVE includere i seguenti componenti (WP_111a):
Componente |
Descrizione |
|---|---|
nameSpaces |
(bstr). Contiene la struttura DeviceNameSpaces. PUÒ essere una struttura vuota. DeviceNameSpaces mappa identificatori di namespace verso un insieme di elementi dati firmati dall'Istanza del Wallet. Ogni namespace contiene uno o più DeviceSignedItem, dove ogni elemento include:
|
deviceAuth |
(COSE_Sign1). Contiene la struttura |
Nota
Presentazione della Wallet Attestation
L'Istanza del Wallet DEVE includere la Wallet Attestation se richiesta dalla Relying Party nella richiesta mdoc. L'Istanza del Wallet DOVREBBE includere tutte le divulgazioni selettive disponibili per la Wallet Attestation, DEVE tuttavia includere il campo aal nella risposta (WP_108b). Inoltre, durante la presentazione, l'Istanza del Wallet NON DEVE richiedere il consenso dell'Utente alla divulgazione degli attributi della Wallet Attestation, i quali sono dati tecnici non trasparenti verso l'Utente (WP_107a).
12.2.2.7.3. Session Termination¶
La sessione DEVE chiudersi qualora si verifichi almeno una delle seguenti condizioni (PPR-007 and WP_113–113a):
Dopo un timeout di inattività nel quale non sono scambiati messaggi di Session Establishment o Session Data. Questo timeout di inattività viene implementato dall'Istanza del Wallet e dall'Istanza di Relying Party e DOVREBBE essere non inferiore a 300 secondi;
Quando l'Istanza del Wallet non accetta più richieste;
Quando l'Istanza di Relying Party non invia ulteriori richieste.
Se l'Istanza del Wallet e l'Istanza di Relying Party non inviano o ricevono ulteriori richieste, la terminazione della sessione DEVE essere avviata come segue (PPR-007 and WP_113):
Inviare lo status code per la Session Termination, o
Inviare il comando "End" come delineato in [ISO18013-5 #11.1.3.3].
Quando una sessione viene terminata, l'Istanza del Wallet e l'Istanza di Relying Party DEVONO eseguire almeno le seguenti azioni (WP_114):
Distruzione delle chiavi di sessione e del materiale di chiavi effimere correlato;
Chiusura del canale di comunicazione utilizzato per il Device Retrieval.
Nota
Vedere Attestato Elettronico in formato mdoc-CBOR per il significato degli acronimi di tipo CBOR.