8.2.2. Flusso di Prossimità¶
Questa sezione descrive come un'App di Verifica richiede la presentazione di un Attestato Elettronico in formto mdoc-CBOR a un'Istanza del Wallet secondo la Specifica ISO 18013-5.
La fase di presentazione è strutturata in tre ampie sotto-fasi come illustrato nella seguente figura:
Fig. 8.9 Flusso di Presentazione di Alto Livello in prossimità.¶
Le sotto-fasi sono descritte di seguito:
1. Device Engagement: Questa sottofase inizia quando all'Utente viene richiesto di divulgare determinati attributi dall'mdoc(s). L'obiettivo di questa sottofase è stabilire un canale di comunicazione sicuro tra l'Istanza del Wallet e l'App di Verifica, in modo che le richieste e le risposte mdoc possano essere scambiate durante la sottofase di comunicazione. I messaggi scambiati in questa sottofase vengono trasmessi attraverso tecnologie a corto raggio per limitare la possibilità di intercettazione e ascolto non autorizzato.
2. Session Establishment: Durante la fase di Session Establishment, l'App di Verifica configura una connessione sicura. In questa fase, tutti i dati trasmessi su questa connessione sono cifrati utilizzando una chiave di sessione che è nota sia all'Istanza del Wallet che all'App di Verifica. La sessione stabilita PUÒ essere terminata in base alle condizioni dettagliate in [ISO18013-5 #9.1.1.4].
3. Comunicazione e Recupero del Dispositivo: L'App di Verifica cripta la richiesta mdoc con l'appropriata chiave di sessione e la invia all'Istanza del Wallet insieme alla sua chiave pubblica in un messaggio di Session Establishment. L'mdoc utilizza i dati dal messaggio di Session Establishment per derivare la chiave di sessione e decifrare la richiesta mdoc. Durante la sottofase di comunicazione, l'App di Verifica 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 cripta la risposta mdoc utilizzando la chiave di sessione e la trasmette al Relying Party mobile tramite una risposta mdoc contenente i Session Data.
Le App di Verifica e le Istanze Wallet registrate nell'ecosistema IT-Wallet DEVONO soddisfare almeno i seguenti requisiti:
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.
Device Engagement basato su QR Code.
Autenticazione dell'Istanza RP seguendo i meccanismi definiti nell'ISO18013-5 per l'autenticazione del lettore.
Meccanismo di Recupero del Dispositivo basato su Bluetooth Low Energy (BLE) per la sottofase di comunicazione. Il meccanismo di Recupero del Server NON DEVE essere supportato.
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).
Validazione dell'Istanza del Wallet attraverso la Wallet Attestation.
La seguente figura illustra il flusso di prossimità a basso livello conforme ad ISO 18013-5.
Fig. 8.10 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'Applicazione Crittografica Sicura (WSCA) del dispositivo Utente. È un prerequisito per accedere a dati sensibili e presentare attributi.
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.
Passo 5: L'Istanza del Wallet genera una nuova coppia di chiavi crittografiche effimere per la comunicazione sicura. La chiave pubblica (EDeviceKey.Pub) sarà utilizzata per la crittografia della sessione. Questo fa parte del processo di Device Engagement.
Passo 6: L'Istanza del Wallet presenta un QR Code all'App di Verifica. Questo QR code contiene i dati DeviceEngagement, che includono EDeviceKey.Pub e informazioni sulle suite di cifratura supportate.
Di seguito è riportato un esempio non normativo che utilizza DeviceEngagement codificato in CBOR 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)
}
}
Passo 7: Il verificatore utilizza la sua App di Verifica per scansionare il QR code e recuperare i dati DeviceEngagement dall'mdoc.
Passo 8: L'App di Verifica genera la sua coppia di chiavi effimere (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.
Passo 9: L'Istanza del Wallet e l'App di Verifica 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 la cifratura della sessione. In questo passo, l'App di Verifica DEVE calcolare la sua chiave di sessione.
Passo 10: L'App di Verifica DEVE preparare un messaggio SessionEstablishment. Questo messaggio DEVE essere firmato dall'App di Verifica (come specificato in [ISO18013-5 #9.1.4 mdoc reader authentication]) e cifrato utilizzando le chiavi di sessione derivate nel passo precedente. Il messaggio di SessionEstablishment DEVE includere sia EReaderKey.Pub che una richiesta per specifici attributi.
Di seguito è riportato un esempio non normativo che utilizza la notazione diagnostica di un SessionEstablishment codificato in CBOR che contiene la richiesta mdoc di una Wallet Attestation insieme a una Credenziale Digitale 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
]
}
Passo 11: L'App di Verifica DEVE trasmettere il messaggio SessionEstablishment cifrato e firmato all'Istanza del Wallet su una connessione BLE sicura stabilita sulla base delle informazioni contenute nel Device Engagement.
Passo 12: L'Istanza del Wallet DEVE calcolare la chiave di sessione, come descritto nel Passo 9.
Passo 13: Dopo aver ricevuto il messaggio SessionEstablishment, l'Istanza del Wallet DEVE decifrarlo utilizzando la chiave di sessione condivisa e DEVE verificare la firma dell'App di Verifica (come specificato in [ISO18013-5 #9.1.1.4 mdoc reader authentication]) per garantirne l'autenticità.
Passo 14: L'Istanza del Wallet DEVE decifrare la richiesta di attributi e DEVE chiedere all'Utente il consenso per il rilascio degli attributi richiesti. DEVE inoltre visualizzare il contenuto del Certificato di Registrazione dell'App di Verifica per garantire l'autenticità, la trasparenza sui dati richiesti e sul suo scopo registrato.
Passo 15: L'Utente esamina la richiesta e le informazioni di registrazione della Relying Party e poi approva la presentazione degli attributi richiesti.
Passo 16: Dopo aver ricevuto l'approvazione dell'Utente, l'Istanza del Wallet DEVE recuperare le Credenziali Digitali mdoc richieste. Quindi DEVE preparare un messaggio SessionData contenente queste Credenziali Digitali, e DEVE firmare i dati di autenticazione richiesti (come parte del processo di autenticazione mdoc, come specificato in [ISO18013-5 #9.1.3]). DEVE criptarlo utilizzando le chiavi di sessione stabilite prima di trasmetterlo all'App di Verifica sul canale BLE sicuro. 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 #8.3.2.1.2.2].
Di seguito è riportato un esempio non normativo che utilizza la notazione diagnostica di un SessionData codificato in CBOR che contiene la risposta mdoc di una Wallet Attestation e un 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 17: L'App di Verifica che riceve il SessionData DEVE decifrarlo, quindi verificare la firma dell'Istanza del Wallet per garantire sia l'integrità dei dati che la provenienza di essi dal dispositivo previsto (device binding). Essa DEVE anche controllare la validità dell'mdoc, inclusa la firma del suo Fornitore di Attestati Elettronici. In caso di Attestati Elettronici a lunga durata, DOVREBBE anche controllare lo stato di revoca utilizzando TOKEN-STATUS-LIST.
Passo 18: Una volta completato lo scambio di dati, una delle parti può terminare la sessione. Se viene utilizzato BLE, questo può comportare l'invio di uno Stat Code per la terminazione della sessione o il comando End. In questo scenario, il Client GATT (App di Verifica) DEVE disconnettersi dal Server GATT (Istanza del Wallet).
Considerazione Finale: Questo flusso di presentazione descrive lo scambio di dati in 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 ulteriore livello di sicurezza riguardo l'identità dell'Utente attraverso l'ispezione visiva e il confronto degli Attributi Elettronici presentati, contribuendo agli aspetti generali di garanzia dell'autenticazione 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 aggiornato; in questo caso, l'Istanza del Wallet DOVREBBE inviare l'ultima versione della Wallet Attestation. È lasciato alla Relying Party determinare se una presentazione con una Wallet Attestation valido ma scaduto sia valida o meno.
8.2.2.1. Device Engagement¶
La struttura del Device Engagement DEVE essere codificata in CBOR e avere almeno le seguenti componenti:
Componente |
Descrizione |
|---|---|
Version |
(tstr). Versione della struttura di Device Engagement. |
Security |
(array). Contiene due valori obbligatori:
|
BleOptions |
(map). Fornisce opzioni per la connessione BLE, come la modalità Peripheral Server o Central Client, e l'UUID del dispositivo. Solo la Modalità Central Client DEVE essere supportata da questo profilo di implementazione. |
Capabilities |
(map). Dichiara le capacità opzionali supportate dall'mdoc, che sono:
|
OriginInfos |
(array). Descrive l'interfaccia utilizzata per ricevere e consegnare il messaggio di Device Engagement.
|
8.2.2.2. 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. 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. Consente di gestire la compatibilità tra diverse versioni o profili di implementazione. |
docRequests |
(array). Ogni voce è un oggetto DocRequest contenente:
|
readerAuthAll |
(COSE_Sign1, CONDIZIONALE). Utilizzato per autenticare l'App di Verifica una volta per tutte le richieste in DocRequest. La firma è calcolata sui dati ReaderAuthenticationAll, come definito in [ISO18013-5 #9.1.4]. Questo componente DEVE essere presente solo se ReaderAuthAllSupport è impostato su true nel messaggio di DeviceEngagement, in questo caso, i campi individuali readerAuth non vengono utilizzati. |
Nota
Richiesta dell'Attestazione del Wallet
La Relying Party che richiede un'Attestazione del Wallet 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.
8.2.2.3. 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. 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 della Risposta mdoc. Consente di tracciare le modifiche e mantenere la compatibilità tra le versioni dello standard o i profili di implementazione. |
documents |
(array di Documents, OPZIONALE). Collezione di documenti codificati in CBOR restituiti in risposta alla richiesta mdoc. Ogni documento include i componenti issuerSigned e deviceSigned, e segue la struttura definita nella tabella sottostante. |
documentErrors |
(map, OPZIONALE). Una mappa di codici di errore per i documenti non restituiti, come definito in [ISO18013-5 #8.3.2.1.2.3]. 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 i dettagli, vedere la Tabella 8 (ResponseStatus) di [ISO18013-5 #8.3.2.1.2]. |
Ogni elemento in documents DEVE essere conforme alla seguente struttura e DEVE includere i seguenti componenti, a meno che non sia specificato diversamente:
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 di dati firmati dal Fornitore di Attestati Elettronici, e la struttura issuerAuth, che garantisce la loro autenticità e integrità utilizzando il Mobile Security Object (MSO). Vedi Attestato Elettronico in formato mdoc-CBOR. |
deviceSigned |
(bstr). Contiene la struttura DeviceNameSpaces (elementi di dati firmati dall'Istanza del Wallet), e la struttura deviceAuth, che include i dati di autenticazione firmati dall'Istanza del Wallet. Vedi la tabella sottostante per i dettagli. |
errors |
(map, OPZIONALE). Una mappa di codici di errore per ogni elemento di dati non restituito raggruppati per namespace. Ogni chiave rappresenta un namespace specifico, e ogni valore è una mappa di identificativi di elementi di dati ai corrispondenti codici di errore. Vedi [ISO18013-5 #8.3.2.1.2.3] per i dettagli sulla struttura degli errori. |
Una struttura di dati deviceSigned DEVE essere conforme alla seguente struttura e DEVE includere i seguenti componenti:
Componente |
Descrizione |
|---|---|
nameSpaces |
(bstr). Contiene la struttura DeviceNameSpaces. PUÒ essere una struttura vuota. DeviceNameSpaces mappa l'identificativo del namespace a un insieme di elementi di dati firmati dall'Istanza del Wallet. Ogni namespace contiene uno o più elementi DeviceSignedItem, dove ciascun elemento include:
|
deviceAuth |
(COSE_Sign1). Contiene la struttura DeviceAuth, che DEVE includere la deviceSignature per l'autenticazione dell'Istanza del Wallet. La firma è calcolata sui dati DeviceAuthentication, che lega gli elementi restituiti alla sessione e alla richiesta. Vedi [ISO18013-5 #9.1.3] per i dettagli sulla struttura di autenticazione. |
Nota
Presentazione dell'Attestazione del Wallet
L'Istanza del Wallet DEVE includere l'Attestazione del Wallet se richiesta dalla Relying Party nella richiesta mdoc. L'Istanza del Wallet DOVREBBE includere tutte le divulgazioni selettive disponibili per l'Attestazione del Wallet, DEVE tuttavia includere il campo aal nella risposta. Inoltre, durante la presentazione, l'Istanza del Wallet NON DEVE richiedere il consenso dell'Utente alla divulgazione degli attributi dell'Attestazione del Wallet, i quali sono dati tecnici non trasparenti verso l'Utente.
8.2.2.4. Chiusura della Sessione¶
La sessione DEVE chiudersi qualora si verifichi almeno una delle seguenti condizioni:
Dopo un timeout di inattività nel ricevere o inviare messaggi di Session Establishment o di SessionData. Il timeout per l'inattività implementato dall'Istanza del Wallet e dall'App di Verifica DOVREBBE essere non inferiore a 300 secondi;
Quando l'Istanza del Wallet non accetta più richieste;
Quando l'App di Verifica non invia ulteriori richieste.
Se l'Istanza del Wallet e l'App di Verifica non inviano o ricevono ulteriori richieste, la terminazione della sessione DEVE essere avviata come segue:
Inviare il codice di stato per la terminazione della sessione, o
Inviare il comando "End" come delineato in [ISO18013-5 #8.3.3.1.1.5].
Quando una sessione viene terminata, l'Istanza del Wallet e l'App di Verifica DEVONO eseguire almeno le seguenti azioni:
Distruzione delle chiavi di sessione e del relativo materiale di chiave effimero;
Chiusura del canale di comunicazione utilizzato per il recupero dei dati.
Nota
Vedi Attestato Elettronico in formato mdoc-CBOR per il significato degli acronimi dei tipi CBOR.