—

[16] ETSI EN 319 412-1 V1.6.1 (2025-06): ”Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures”.

—

[17] ETSI TS 119 412-6 V1.1.1 (2025-09): ”Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA providers”.

—

[25] IETF Token Status List (TSL), draft-ietf-oauth-status-list-20: ”Token Status List”, 20 april 2026.

—

EAA-4.2.11.1-06: När ett statuselement används för personidentifieringsuppgifter, kvalificerade elektroniska attributsintyg eller elektroniska attributsintyg som tillhandahålls av eller på uppdrag av ett offentligt organ som ansvarar för en autentisk källa ska det endast ange om intyget är återkallat eller inte återkallat och får inte stödja några andra statusvärden, såsom tillfälligt upphävande.

—

EAA-4.2.11.1-06.1: Om ett intyg återkallas ska det vara permanent återkallat.

—

EAA-4.2.13-03: Om elektroniska attributsintyg med kort giltighetstid (en giltighetsperiod på högst 24 timmar) utfärdas krävs ingen återkallelse.

—

PuB-EAA-4.6.2-03: void.

—

Pub-EAA-4.6.2-04: void.

—

PuB-EAA-4.6.3-03: PuB-EAA:s digitala signatur ska innehålla det kvalificerade certifikat som stöder PuB-EAA:s digitala signatur.

—

PuB-EAA-4.6.3-04: Det kvalificerade certifikat som stöder PuB-EAA:s digitala signatur ska uppfylla kraven i klausul 8 i ETSI TS 119 412-6 v1.1.1 och ska innehålla QcType qcStatement enligt definitionen i ETSI EN 319 412-5 v2.5.1, med värdet id-etsi-qct-eidaspsbeaa definierat enligt följande:

id-etsi-qct-eidaspsbeaa OBJECT IDENTIFIER ::= { id-etsi-eidas2-qct-extensions 3 } -- certifikat som avses i artikel 45f.1 b och som stöder det offentliga organets kvalificerade elektroniska signatur eller kvalificerade elektroniska stämpel enligt artikel 3.46 i förordning (EU) nr 910/2014.

—

EAA-5.2.10.1-04: void.

—

EAA-5.2.10.1-05: void.

—

EAA-5.2.10.1-06: Statuselementet kan innehålla status_list-elementet i enlighet med avsnitt 6.2 i IETF draft-ietf-oauth-status-list-20 [25].

—

EAA-5.2.10.1-07: void.

—

EAA-5.2.10.1-08: void.

—

EAA-5.2.10.1-09: void.

—

EAA-5.2.10.1-10: void.

—

EAA-5.2.10.1-11: void.

—

EAA-5.2.10.1-12: void.

—

EAA-6.2.10.1-01: När ett elektroniskt attributsintyg som överensstämmer med ISO/IEC mdoc använder mekanismen med intygsstatuslista enligt EAA-6.2.10.1-02.2 eller mekanismen med intygsåterkallelselista enligt EAA-6.2.10.1-02.3 ska det elektroniska attributsintygets Mobile Security Object (MSO) innehålla statusstrukturen enligt EAA-6.2.10.1-17, som innehåller återkallelseinformation för MSO.

—

EAA-6.2.10.1-01.1: Vid implementering av mekanismen med identifierarlista ska statuselementet innehålla elementet identifier_list enligt EAA-6.2.10.1-11.

—

EAA-6.2.10.1-01.2: Vid implementering av mekanismen med statuslista ska statuselementet innehålla elementet status_list enligt EAA-6.2.10.1-13.

—

ANMÄRKNING:

—

EAA-6.2.10.1-02: Tillhandahållaren av personidentifieringsuppgifter, tillhandahållaren av kvalificerade elektroniska attributsintyg eller tillhandahållaren av elektroniska attributsintyg som tillhandahålls av eller på uppdrag av ett offentligt organ med ansvar för en autentisk källa ska använda en av följande metoder för återkallelse av personidentifieringsuppgifter, kvalificerade elektroniska attributsintyg eller elektroniska attributsintyg som tillhandahålls av eller på uppdrag av ett offentligt organ med ansvar för en autentisk källa:

—

EAA-6.2.10.1-02.1: Om de utfärdar elektroniska attributsintyg med kort giltighetstid som har en giltighetsperiod på högst 24 timmar ska återkallelse inte krävas.

—

EAA-6.2.10.1-02.2: Använd en mekanism med intygsstatuslista för att koda återkallelseinformationen som en statuslista.

—

EAA-6.2.10.1-02.2.1: Mekanismen med statuslista återkallar ett MSO baserat på om biten i den av utfärdaren definierade bitpositionen i MSO har värdet sant i statuslistan.

—

EAA-6.2.10.1-02.2.2: Mekanismen med statuslista specificeras i specifikationen för Token Status List (draft-ietf-oauth-status-list-20).

—

EAA-6.2.10.1-02.3: Använd en mekanism med intygsåterkallelselista för att koda återkallelseinformationen som en identifierarlista.

—

EAA-6.2.10.1-02.3.1: Mekanismen med identifierarlista återkallar ett MSO baserat på om den av utfärdaren definierade identifieraren i MSO finns i identifierarlistan.

—

EAA-6.2.10.1-02.3.2: EAA-6.2.10.1-06, EAA-6.2.10.1-08, EAA-6.2.10.1-09, EAA-6.2.10.1-10 och EAA-6.2.10.1-11 specificerar mekanismen med identifierarlista baserat på kraven i specifikationen för Token Status List, inklusive det som är gemensamt för mekanismerna med statuslista och identifierarlista.

—

EAA-6.2.10.1-03: När statuselementet används för personidentifieringsuppgifter, kvalificerade elektroniska attributsintyg eller elektroniska attributsintyg som tillhandahålls av eller på uppdrag av ett offentligt organ med ansvar för en autentisk källa ska uteslutande statusen ”revoked” användas.

—

EAA-6.2.10.1-03.1: För en statuslista innebär detta att endast värdena ”valid” och ”invalid”, enligt specifikationen för Token Status List, ska användas.

—

EAA-6.2.10.1-03.2: För identifierarlistan ska endast återkallade MSO, till skillnad från tillfälligt upphävda MSO, föras upp på identifierarlistan.

—

EAA-6.2.10.1-04: Om ett MSO återkallas ska MSO återkallas permanent.

—

EAA-6.2.10.1-05: Verifiering av återkallelselistan för MSO är frivillig för den förlitande parten och ska i tillämpliga fall uppfylla verifieringskraven i specifikationen för Token Status List och statusstrukturspecifikationen i EAA-6.2.10.1-01.

—

EAA-6.2.10.1-05.1: Om en förlitande part behöver kunna verifiera återkallelsestatusen för personidentifieringsuppgifter eller elektroniska attributsintyg ska den stödja både mekanismen med intygsstatuslista och mekanismen med intygsåterkallelselista enligt EAA-6.2.10.1-02.

—

EAA-6.2.10.1-06: identifier_list och status_list i MSO får innehålla certifikatelementet.

—

EAA-6.2.10.1-06.1: Om certifikatelementet förekommer ska det innehålla ett certifikat som innehåller den publika nyckel som undertecknade eller stämplade det överordnade certifikatet i x5chain-elementet i strukturen för återkallelselistan för MSO.

—

EAA-6.2.10.1-06.1.1: Instansen av förlitande part ska använda det certifikatet som tillitsankare för verifieringen av x5chain-elementet i strukturen för återkallelselistan för MSO.

—

EAA-6.2.10.1-06.2: Om certifikatelementet inte förekommer ska det överordnade certifikatet i x5chain-elementet i strukturen för återkallelselistan för MSO undertecknas eller stämplas med det certifikat som används för att underteckna certifikatet i x5chain-elementet i MSO.

—

EAA-6.2.10.1-06.2.1: Instansen av förlitande part ska använda det certifikatet som tillitsankare för verifieringen av x5chain-elementet i strukturen för återkallelselistan för MSO.

—

EAA-6.2.10.1-07: En återkallelselista för MSO ska implementeras i enlighet med specifikationen för Token Status List som en status list-token i CWT-format.

—

EAA-6.2.10.1-08: För återkallelselistan för MSO för mekanismen med identifierarlista och statuslista gäller följande krav:

—

EAA-6.2.10.1-09: Med avvikelse från kraven i specifikationen för Token Status List gäller följande krav för mekanismen med identifierarlista:

—

EAA-6.2.10.1-10: Strukturen IdentifierList ska vara en CBOR-struktur med följande CDDL:

IdentifierList = {

'identifiers': { * Identifier => IdentifierInfo },

? 'aggregation_uri': Aggregation_uri

* tstr => RFU

}

IdentifierInfo = { tstr/int => RFU }

Identifier = bstr

Aggregation_uri = tstr

—

EAA-6.2.10.1-10.1: Om identifieraren finns i IdentifierList är den MSO som innehåller identifieraren i statuselementet återkallad.

—

EAA-6.2.10.1-10.2: Anspråket Aggregation_uri specificeras i avsnitt 9.2 i specifikationen för Token Status List.

—

EAA-6.2.10.1-10.3: Innehållstypen för identifierarlistan ska vara ”application/identifierlist+cwt” enligt kraven i avsnitt 8.2 i specifikationen för Token Status List.

—

EAA-6.2.10.1-11: Följande krav gäller för elementet identifier_list i MSO (se EAA-6.2.10.1-17).

—

EAA-6.2.10.1-11.1: Elementet identifier_list är en CBOR-struktur med följande CDDL:

IdentifierListInfo = {

'id': Identifier ,

'uri': URI,

? 'certificate': Certificate

* tstr => RFU

}

URI = tstr

Certificate = bstr

—

EAA-6.2,10.1-11,2: REV-11.2: För att förhindra att identifieraren används som korrelation mellan presentationer ska den vara unik per MSO.

—

EAA-6.2,10.1-12: Följande krav gäller för statuslistan:

—

EAA-6.2.10.1-13: Följande krav gäller för elementet status_list i MSO (se EAA-6.2.10.1-17):

—

EAA-6.2.10.1-14: Plånbokstillhandahållaren ska använda den andra (EAA-6.2.10.1-02.2) eller den tredje (EAA-6.2.10.1-02.3) av de metoder som anges i EAA-6.2.10.1-02 för återkallelse av ett plånboksinstansintyg (WIA) och för återkallelse av ett nyckelintyg (KA).

—

EAA-6.2.10.1-15: Plånbokstillhandahållaren ska implementera de mekanismer för återkallelse av intyg som anges i EAA-6.2.10.1-02 i sin plånbokslösning.

—

EAA-6.2.10.1-16: Tillhandahållaren av personidentifieringsuppgifter och tillhandahållaren av elektroniska attributsintyg ska stödja både mekanismen med intygsstatuslista och mekanismen med intygsåterkallelselista som anges i EAA-6.2.10.1-02 för verifiering av återkallelsestatusen för ett plånboksinstansintyg (WIA) och för ett nyckelintyg (KA).

—

EAA-6.2.10.1-17: Statusstrukturen i MSO ska vara en CBOR-struktur med följande CDDL:

Status = {

? 'identifier_list' : IdentifierListInfo,

? 'status_list' : StatusListInfo,

* tstr => RFU

}

—

GEN-REQ-4.1-05: void

—

ANMÄRKNING: void

—

ISS-MDATA-REG_CERT-4.2.3-04: Ett av elementen i arrayparametern issuer_info ska innehålla PID/EAA-tillhandahållarens registreringscertifikat.

—

ISS-MDATA-REG_CERT-4.2.3-07: void

—

ISS-MDATA-REG_CERT-4.2.3-08: void

—

ISS-MDATA-REG_CERT-4.2.3-09: void

—

ISS-MDATA-REG_CERT-4.2.3-10: void

—

ISS-MDATA-REG_CERT-4.2.3-11: void

—

ISS-MDATA-REG_CERT-4.2.3-12: void

—

ISS-MDATA-REG_CERT-4.2.3-13: void

—

I detta dokument specificeras två profiler av protokoll som gör det möjligt för förlitande parter (nedan kallade RP) att begära EAAP eller personidentifieringsuppgifter (PID) till EUDI-plånboken, och för EUDI-plånboken att skicka de begärda EAAP/PID till RP. Varje profil stöder två överföringsmekanismer, nämligen API-förmedlad och icke API-förmedlad enligt nedan:

—

[15] ISO 639: 'Language code'.

—

[16] ISO/IEC 18013-7:2025 Personal identification – ISO – compliant driving licence – Part 7: Mobile driving licence (mDL) add-on functions.”

—

EAAP-SD-JWT VC-04: ogiltig.

—

EAAP-ISO/IEC-mdoc-01: ogiltig.

—

Note2: ogiltig.

—

EAAP-ISO/IEC-mdoc-02: ogiltig.

—

EAAP-API-GEN-01: EUDI-plånboken ska stödja ett förmedlande API som stöder både de protokoll som definieras i punkt 5.2 i [11] och i bilaga C till [16].

—

ANMÄRKNING: Om den enhet på vilken den europeiska e-identitetsplånboken är installerad inte stöder båda protokollen, kan detta krav inte uppfyllas och leder till bristande överensstämmelse på grund av att underliggande operativsystem och webbläsare inte har de nödvändiga interoperabilitetsegenskaperna.

—

EAAP-API-GEN-02: EUDI-plånboken ska stödja ett förmedlande API åtminstone för PID och EAA-typer som är registrerade i katalogen över scheman enligt definitionen i genomförandeförordning (EU) 2025/1569, och åtminstone för alla format som definieras i bilaga II till genomförandeförordning (EU) 2024/2979.

—

ANMÄRKNING 1: Om det underliggande operativsystemet, webbläsaren, förmedlande API eller något annat tekniskt skikt utanför EUDI-plånbokens kontroll inskränker, filtrerar, förväljer eller på annat sätt begränsar formaten för autentiseringsuppgifter och PID- och EAA-typerna som är registrerade i katalogen över scheman kan detta krav inte uppfyllas. Om en sådan inskränkning hindrar EUDI-plånboken från att stödja en registrerad typ av autentiseringsuppgifter eller ett registrerat format beror den resulterande felaktigheten på att dessa underliggande operativsystem, webbläsare, förmedlande API eller andra relevanta tekniska skikt inte tillhandahåller de nödvändiga interoperabilitetsfunktionerna.

—

WRP-VALIDATION-01: EUDI-plånboken ska validera det förlitandepartregistreringscertifikat som tagits emot i begäran innan den presenterar ett begärt PID eller ett elektroniskt attributsintyg för plånboksanvändaren för godkännande.

—

WRP-VALIDATION-02: Om valideringen av förlitandepartregistreringscertifikatet misslyckas, inbegripet om certifikatet har upphört att gälla, återkallats, inte utfärdats av en giltig betrodd tillhandahållare av förlitandepartregistreringscertifikat, har ett ogiltigt format eller inte kan verifieras kryptografiskt, ska EUDI-plånboken varna plånboksanvändaren om att den förlitande parten inte kunde valideras och inte presentera begäran som framgångsrikt validerad. Plånboksanvändaren ska uttryckligen godkänna den förlitande partens begäran. Tystnad eller förkryssade rutor ska inte räcka för uttryckligt godkännande.

—

WRP-VALIDATION-03: Plånbokstillhandahållaren ska, på grundval av sin riskanalys och säkerhetspolicy, avgöra om och under vilka förhållanden specifika misslyckade valideringskontroller får kringgås av plånboksanvändaren.

—

WRP-OVERASKING-01: EUDI-plånboken ska jämföra de intyg och attribut som den förlitande parten begär med de registrerade intygen och attributen i förlitandepartregistreringscertifikatet.

—

WRP-OVERASKING-02: Om den förlitande parten begär PID eller elektroniska intyg för attribut eller anspråk som inte omfattas av förlitandepartregistreringscertifikatet ska EUDI-plånboken tydligt varna plånboksanvändaren innan något utlämnande görs. Varningen ska ange att den förlitande parten begär mer information än vad den har registrerat. Plånboksanvändaren ska uttryckligen godkänna den förlitande partens begäran. Tystnad eller förkryssade rutor ska inte räcka för uttryckligt godkännande.

—

WRP-OVERASKING-03: Plånbokstillhandahållaren ska, på grundval av sin riskanalys, säkerhetspolitik och tillämpliga rätt, fastställa om plånboksanvändaren får fortsätta trots en sådan varning, om endast den undergrupp av begärda uppgifter som omfattas av registreringsbeviset får lämnas ut eller om begäran ska avslås.

—

Avsnitt 5 och dess underavsnitt definierar en profil för ett protokoll som gör det möjligt för en RP att begära EAAP eller PID till EUDI-plånboken, och för EUDI-plånboken att skicka begärda EAAP/PID till RP med hjälp av antingen en icke API-förmedlad överföringsmekanism som bygger på ISO/IEC 18013-5 [] eller en API-förmedlad överföringsmekanism som bygger på bilaga C till ISO/IEC 18013-7 [16] för överföring av de datastrukturer som definieras i ISO/IEC 18013-5 [] i lämpligt inkapslad form.

—

Resten av avsnitt 5 är organiserat enligt följande:

—

ISO/IEC 18013-SUPPORT-01: Plånboksenheter, PID-tillhandahållare, intygstillhandahållare, plånbokstillhandahållare och förlitande parter får inte stödja serverhämtning enligt ISO/IEC 18013-5 [10] för begäran och presentation av PID eller intygsattribut.

—

ISO/IEC 18013-SUPPORT-02: EUDI-plånboken ska uppfylla de krav som definieras i avsnitten 5.3 och 5.4 i detta dokument.

—

ISO/IEC 18013-SUPPORT-04: En förlitande part ska implementera den profil som definieras i avsnitt 5.4 i detta dokument.

—

ISO/IEC 18013-5-REQ-04: Enhetsbegäranden som skickas till EUDI-plånböcker ska innehålla nyckelvärdesparet ”requestInfo” som anges i avsnitt 8.3.2.1.2.1 i [10]. Värdet av detta par ska vara av typen RequestInfo.

—

ISO/IEC 18013-5-REQ-05: Typen RequestInfo ska vara enligt CDDL-definitionen nedan.

RequestInfo = {

'euWrprc': bstr ; innehåller ett registreringscertifikat (se kraven nedan)

}

—

ISO/IEC 18013-5-REQ-06: Det nämnda requestInfo-elementet ska innehålla ett element med etiketten ”euWrprc”

—

ISO/IEC 18013-5-REQ-07: Värdet av ”euWrprc” ska vara ett CBOR-kodat registreringscertifikat.

—

ISO/IEC 18013-5-REQ-08: ogiltig.

—

ANMÄRKNING 3: ogiltig.

—

ISO/IEC 18013-5-REQ-09: void.

—

ISO/IEC 18013-5-REQ-10: ogiltig.

—

ISO/IEC 18013-5-REQ-11: void.

—

I detta avsnitt definieras krav för meddelandetypen DeviceResponse, som är gemensamma för de två typerna av överföringsmekanismer (API-förmedlad och icke API-förmedlad).

—

ANMÄRKNING 1: När en icke API-förmedlad mekanism som bygger på ISO/IEC 18013-5 [10] används är ett EAAP-svar exakt en instans av DeviceResponse enligt profilen i detta avsnitt. När en API-förmedlad mekanism som bygger på bilaga C till ISO/IEC 18013-7 [16] används inkapslas instansen av DeviceRequest enligt specifikationerna i bilaga C i [16].

—

ISO/IEC 18013-5-RESP-02: Tillhandahållaren av personidentifieringsuppgifter och elektroniska attributsintyg får inte inkludera några dataelement i KeyAuthorizations-mappningen i Mobile Security Object för de personidentifieringsuppgifter och elektroniska attributsintyg som tillhandahållaren utfärdar, med undantag för dataelement som tillhandahålls av den förlitande parten i transaktionsuppgifterna i den mdoc-begäran som ska undertecknas eller stämplas av plånboksenheten med den privata nyckeln för personidentifieringsuppgifterna eller de elektroniska attributsintygen.

—

ANMÄRKNING 2: Som en följd av detta kan plånboksenheter inte presentera några enhetsundertecknade dataelement för förlitande parter, med undantag för undertecknande av data som den förlitande parten har tillhandahållit, till exempel i användningsfall för säker användarautentisering.

—

ANMÄRKNING 3: ISO/IEC 18013-5:2021 specificerar inte hur förlitande parter kan inkludera transaktionsuppgifter i en mdoc-begäran. Inkludering av transaktionsuppgifter i en mdoc-begäran ska ske genom tillägg av tekniska specifikationer.

—

ISO/IEC 18013-5-RESP-03: Tillhandahållare av personidentifieringsuppgifter får inte tillåta att den privata nyckeln för personidentifieringsuppgifterna undertecknar dataelement som tillhandahålls av den förlitande parten i transaktionsuppgifterna i mdoc-begäran.

5.4.1

ISO/IEC 18013-7-related requirements

—

ISO/IEC 18013-7-API-01: Profilen som stöder API-förmedlade presentationer ska uppfylla kraven i bilaga C till ISO/IEC 18013-7 [16] enligt ytterligare profilering i avsnitten 5.3 och 5.4 i detta dokument.

—

ISO/IEC 18013-7-API-02: Alla obligatoriska krav som definieras i bilaga C till [16] ska tillämpas enligt ytterligare profilering i avsnitten 5.3 och 5.4 i detta dokument.

—

ISO/IEC 18013-7-API-03: Alla valfria krav som definieras i bilaga C till [16] ska förbli valfria om inte annat anges i detta dokument.

—

I detta avsnitt specificeras ytterligare krav för API-förmedlad överföringsmekanism.

—

ISO/IEC 18013-ADD-API-01: EUDI-plånboken ska som standard lämna ut förekomsten av alla lagrade typer av elektroniska attributsintyg till den förmedlande API som fungerar i enlighet med bilaga C till [16], men den får inte lämna ut attributen och deras värden i dessa elektroniska attributsintyg.

—

Det finns överväganden relaterade till operativsystem och webbläsare som faller utanför implementerarnas kontroll, vilka kan beaktas enligt vad som anges i anmärkningarna 2–4 nedan:

—

ISO/IEC 18013-ADD-API-02: Om en EUDI-plånbok, på användarens begäran, raderar ett PID eller ett elektroniskt attributsintyg som tidigare lämnades ut till det förmedlande API som fungerar i enlighet med bilaga C till [16] ska EUDI-plånboken lämna uppgift till det förmedlande API om att den inte längre lagrar detta PID eller detta elektroniskt attributsintyg.

—

ISO/IEC 18013-ADD-API-03: Om användaren avinstallerar sin EUDI-plånbok ska EUDI-plånboken lämna uppgift till det förmedlande API, som fungerar i enlighet med bilaga C till [16], om att den inte längre lagrar några tidigare utlämnade PID eller elektroniska attributsintyg.

—

ISO/IEC 18013-ADD-API-04: EUDI-plånboken ska tillhandahålla en global användarinställning för att inaktivera utlämnande av lagrade elektroniska attributsintyg via ett förmedlande API som fungerar enligt vad som anges i ISO/IEC 18013-ADD-API-01. När denna inställning är inaktiverad får EUDI-plånboken inte annonsera eller besvara API-förmedlade begäranden om presentation eller utfärdande.

—

ISO/IEC 18013-ADD-API-05: EUDI-plånböckerna ska i flöden mellan enheter, med hjälp av det förmedlande API, kontrollera att den interagerande enheten befinner sig i fysisk närhet till EUDI-plånboken med hjälp av en säker, direkt och användarförmedlad lokal kommunikationskanal, t.ex. trådlös kommunikationsteknik för korta avstånd, för att kunna utföra den fysiska närhetskontrollen.

—

ANMÄRKNING: CTAP 2.3 gör det möjligt att använda BLE för att utföra den fysiska närhetskontrollen, och när protokollet har implementerats av båda enheterna blir det även möjligt att överföra data mellan enheterna via teknik för överföring över korta avstånd. Underliggande operativsystem, webbläsare, förmedlande API eller något annat tekniskt skikt utanför EUDI-plånbokens kontroll ska prioritera att både den fysiska närhetskontrollen och dataöverföringen mellan de två enheterna sker via en lokal kommunikationskanal som möjliggörs av CTAP 2.3 framför användning av tjänster för CTAP Hybrid-tunnel.

—

OIDFVP-HAIP-SUPPORT-02: EUDI-plånboken ska uppfylla kraven i avsnitt 6.5 i denna bilaga.

—

OIDFVP-HAIP-SUPPORT-03: EUDI-plånboken får inte stödja den omdirigeringsbaserade mekanism som anges i avsnitt 6.4 för presentationsflöden mellan enheter.

—

ANMÄRKNING 3: Användning av denna mekanism kan ge upphov till sårbarheter som kan utnyttjas genom attacker, till exempel sessionsfixeringsangrepp. Ansvaret för att motverka sådana attacker ligger hos förlitande parter. Implementering av denna mekanism får inte medföra bristande efterlevnad.

—

OIDFVP-HAIP-SUPPORT-05: En förlitande part ska uppfylla kraven som anges i avsnitt 6.5 i denna bilaga.

—

ANMÄRKNING 5: ogiltig.

—

OIDFVP-HAIP-GEN-01: Alla obligatoriska krav som anges i avsnitten 5, 5.3, 7 och 8 i HAIP [11] ska vara tillämpliga.

—

ANMÄRKNING 1: ”HAIP [11] avsnitt 5” avser endast de krav som anges direkt under rubriken för avsnitt 5. Detta omfattar inte avsnitten 5.1, 5.2 och 5.3.

—

OIDFVP-HAIP-GEN-03: Om denna bilaga ändrar ett krav i OpenID4VC-HAIP [11] ska det ändrade krav som anges i denna bilaga ha företräde.

—

ANMÄRKNING 2: Detta möjliggör till exempel att ett valfritt krav i OpenID4VC-HAIP [11] görs obligatoriskt eller att obligatoriska krav utökas.

—

OIDFVP-HAIP-GEN-04: När formatet för det begärda intyget överensstämmer med [10] ska förlitande parter och EUDI-plånböcker uppfylla kraven i profilen ”ISO mdocs” i [11] avsnitt 6.

—

ANMÄRKNING 3: Obs: Profilen ”ISO mdocs” i HAIP innebär att förlitande parter och EUDI-plånböcker måste uppfylla de tillämpliga kraven i [7] bilaga B.2.

—

OIDFVP-HAIP-GEN-05: När formatet för det begärda intyget överensstämmer med [2] ska förlitande parter och EUDI-plånböcker uppfylla kraven i profilen ”IETF SD-JWT VCs” i [11] avsnitt 6.

—

ANMÄRKNING 4: Obs: Profilen ”IETF SD-JWT VCs” innebär att förlitande parter och EUDI-plånböcker måste uppfylla kraven i [7] bilaga B.3 samt kraven i [11] avsnitt 6.1.

—

OIDFVP-HAIP-COMMON-REQ-01: void.

—

OIDFVP-HAIP-COMMON-REQ-RO-02: void

—

OIDFVP-HAIP-COMMON-REQ-RO-03: void

—

OIDFVP-HAIP-COMMON-REQ-RO-04: void

—

OIDFVP-HAIP-COMMON-REQ-RO-05: void

—

OIDFVP-HAIP-COMMON-REQ-RO-06: void.

—

OIDFVP-HAIP-COMMON-REQ-RO-07: void

—

OIDFVP-HAIP-COMMON-REQ-RO-08: void

—

OIDFVP-HAIP-COMMON-REQ-RO-09: void

—

OIDFVP-HAIP-COMMON-REQ-RO-10: void

—

OIDFVP-HAIP-COMMON-REQ-RO-11: void

—

OIDFVP-HAIP-COMMON-REQ-RO-12: void

—

Anmärkning 2: void

—

OIDFVP-HAIP-COMMON-REQ-RO-13: Ett av elementen i parametern verifier_info ska inkludera registreringscertifikatet.

—

OIDFVP-HAIP-COMMON-REQ-RO-23: Det slutcertifikat som anges i OpenID4VP avsnitt 5.9.3 för användning med x509_hash Client Identifier Prefix ska vara ett RP-åtkomstcertifikat såsom anges i ETSI TS 119 475 [14].

—

OIDFVP-HAIP-COMMON-RESP-01: ogiltig.

—

OIDFVP-HAIP-REDIRECTS-04: ogiltig.

—

ANMÄRKNING: ogiltig.

—

OIDFVP-HAIP-ADD-API-01: EUDI-plånboken ska som standard lämna ut information om förekomsten av alla lagrade typer av elektroniska attributsintyg till det förmedlande API som fungerar i enlighet med avsnitt 5.2 i [11], men den ska inte lämna ut attributen och deras värden i dessa elektroniska attributsintyg.

—

OIDFVP-HAIP-ADD-API-04: Om EUDI-plånboken stöder ett förmedlande API som fungerar enligt vad som anges i OIDFVP-HAIP-ADD-API-01 ska den tillhandahålla en global användarinställning för att inaktivera utlämnandet av lagrade EAAs via det förmedlande API:et. När denna inställning är satt till inaktiverat utlämnande ska EUDI-plånboken därefter göra det möjligt för användaren att välja enskilda intyg som ska lämnas ut till det förmedlande API.

—

OIDFVP-HAIP-ADD-API-05: EUDI-plånböckerna ska i flöden mellan enheter, med hjälp av det förmedlande API, kontrollera att den interagerande enheten befinner sig i fysisk närhet till EUDI-plånboken med hjälp av en säker, direkt och användarförmedlad lokal kommunikationskanal, t.ex. trådlös kommunikationsteknik för korta avstånd, för att kunna utföra den fysiska närhetskontrollen.

—

ANMÄRKNING 5: CTAP 2.3 gör det möjligt att använda BLE för att utföra den fysiska närhetskontrollen, och när protokollet har implementerats av båda enheterna blir det även möjligt att överföra data mellan enheterna via teknik för överföring över korta avstånd. Underliggande operativsystem, webbläsare, förmedlande API eller något annat tekniskt skikt utanför EUDI-plånbokens kontroll ska prioritera att både den fysiska närhetskontrollen och dataöverföringen mellan de två enheterna sker via en lokal kommunikationskanal som möjliggörs av CTAP 2.3 framför användning av tjänster för CTAP Hybrid-tunnel.

—

OIDFVP-HAIP-ISO/IEC_18013_5_REQ-02: Alla krav som anges i detta dokument och som är tillämpliga på strukturerna Device Request och Device Response enligt ISO/IEC 18013-5 gäller även när EUDI-plånboken tar emot en begäran om ISO/IEC mdoc-presentation via en API-överförd mekanism som anges i avsnitt C.1 i [16].