EAASD-JWT VC

Attestation Rulebook for attestations of type Portable Document A1

Category: non-qualified EAA

• Author(s):
• [Philipp Friedl, DRV Bund]
• [Artur Philipp, DRV Bund]
• Laurent ?
• Previous Authors *
• Reviewer(s):
• [Florin Coptil, Robert Bosch GmbH]

• [Artur Philipp, DRV Bund]

• Contact:

• Philipp Friedl - DRV Bund

• Feedback:

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: GitHub issues

1 Introduction

This attestation addresses the following question:

Which social security legislation applies to a citizen working in a cross-border employment situation within the EU/EFTA area (or UK)?

The Portable Document A1 (PD A1) is a certificate that documents the applicable legislation regarding social security for a citizen in a cross-border employment situation. By determining that only one legislation applies, it supports the mobility of working citizens while protecting their rights (by ensuring coverage while avoiding dual contributions).

In the most common "posting" situation, where a person works abroad for a maximum of 24 months, the PD A1 is issued by the competent social security institution from the "sending state" upon request by the employer or the self-employed person. It is then used for verification abroad in the "receiving state".

The Know Your Employee (KYE) scenario (Scenario 5) is part of BU1 and will lead to MVP and MVP+ implementations using both Natural Person Wallets and Legal Person Wallets. The high-level scenario is:

"A company A in a country A would like to send one of their employees to work and provide a service to company B in country B."

This scenario requires the issuance of three main credentials: - Portable Document (PD) A1 - Posted Worker Notification (PWN) - Employee Credential

1.1 Document scope and purpose

The PD A1 Attestation provides a standardized, verifiable digital representation of the Portable Document A1. The main legal basis is: - Regulation (EC) No. 883/2004 on the coordination of social security systems (especially Articles 11–16) - Regulation (EC) No. 987/2009, implementing regulation - National legislation regarding social security in EU/EFTA member states (and the United Kingdom)

Design Decisions

This PD A1 Attestation Rulebook is based on: - The EU-wide legally defined content of the Portable Document A1 as issued by competent social security institutions - Regulation (EC) No. 883/2004 and Regulation (EC) No. 987/2009 as the primary legal framework - EESSI (Electronic Exchange of Social Security Information) code tables, e.g. for employment type and institution identifiers - ISO 3166-1 alpha-2 for country codes (mostly EU/EFTA countries + UK = 32 countries) - ISO 8601 for date formatting - SD-JWT VC format with selective disclosure based on logical SD element groups (not individual field level) - eIDAS 2.0 / EUDI Wallet framework for digital identity and verifiable attestations

Key Design Principles: - The credential schema SHALL match the legally defined content of the portable document; therefore all elements are contained. - Personal information on the "subject" SHALL be kept within the VC to allow use by a representative (e.g., employer acting on behalf of employee). - Selective Disclosure SHALL NOT be possible on single-element level, but based on logical blocks as defined by SD element groups. For example, it is only possible to disclose a whole address block, not just the street without the town. - As specific Relying Parties may, according to GDPR, not have the right to request/receive all data, there SHOULD be accreditation-based presentation policy options according to the modular SD-element-group design. - A binding mode indicator (e.g., PID binding, Wallet Instance binding, no binding) SHALL be included as a technical parameter.

1.2 Document structure

This Rulebook follows the generic WE BUILD attestation rulebook template. Chapter 2 states how it complies with the ARF and the applicable Regulations. Chapters 3 and 4 define the attributes and metadata in an encoding-independent manner. Chapter 5 states the formats in which this attestation is issued. Chapters 6 to 9 cover protocols, issuance, revocation and presentation. Chapter 10 sets out the trust framework, and chapter 11 lists references.

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], to indicate requirements, recommendations and options.

In addition, 'must' (non-capitalised) indicates an external constraint, a requirement not mandated by this document but by an external document. The word 'can' indicates a capability. Other words such as 'will', 'is' and 'are' are statements of fact.

1.4 Terminology

Additional terminology specific to this attestation:

2 Compliance

2.1 Compliance statement

This Rulebook complies with the applicable requirements of Topic 12, Attestation Rulebooks, in Annex 2 of the Architecture and Reference Framework, version 3.0.0. It uses the terminology of Annex 1 of the ARF.

2.2 Regulatory basis

This attestation is not a qualified electronic attestation of attributes. The data described in Annex V points b, c and e of Regulation (EU) 2024/1183 is addressed as required by EW-DM-12-018 and as recommended by EW-DM-12-020 and EW-DM-12-022. Where a recommendation is not followed, the reason is stated below.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

3.1 Introduction

This chapter describes the PD A1 credential attributes as defined in the v1.0 PD A1 JSON schema. All field names, types, enumerations, and constraints in Sections 2.2–2.9 are derived strictly from that schema. The normative source is the schema file pda1-sd-jwt.json.

Data Model (v1.0):

PDA1 Credential
├── subject [1:1]
│   ├── pin (string), mandatory | SD Group 1
│   ├── gender (enum "0"/"1"/"2"), mandatory | SD Group 2
│   ├── names [1:1], mandatory | SD Group 3
│   │   ├── surnames (string), mandatory | SD Group 3
│   │   ├── forenames (string), mandatory | SD Group 3
│   │   ├── surnameAtBirth (string), optional | SD Group 3
│   │   └── forenamesAtBirth (string), optional | SD Group 3
│   ├── dateOfBirth (date, YYYY-MM-DD), mandatory | SD Group 4
│   ├── nationalities (array ≥ 1, world codes, unique), mandatory | SD Group 5
│   ├── placeOfBirth [1:1], mandatory | SD Group 6
│   │   ├── town (string), mandatory | SD Group 6
│   │   └── countryCode (world code), mandatory | SD Group 6
│   └── address [1:1], mandatory | SD Groups 7–8
│       ├── stateOfResidence[] (addressWorld), optional | SD Group 7
│       └── stateOfStay[] (addressPDA1State), optional | SD Group 8
│       [anyOf: at least one non-empty list required]
├── memberstateAppliedLegislation [1:1], Non-SD (always disclosed)
│   ├── memberstate (PDA1 code), mandatory
│   ├── startDate (date), mandatory
│   ├── endDate (date), mandatory
│   ├── certificateAppliesForDuranceOfStay (boolean), optional
│   ├── determinationIsProvisional (boolean), optional
│   └── transitionRulesApplyAccordingEG (boolean), optional
├── employmentSituations [1:n], SD Groups 9–10
│   └── [each item:]
│       ├── typeOfEmployment (enum "01"/"02"), mandatory | SD Group 9
│       ├── name (string), mandatory | SD Group 9
│       ├── employerID (string), mandatory | SD Group 9
│       ├── typeOfID (enum), mandatory | SD Group 9
│       └── address (addressWorld), mandatory | SD Group 10
├── placesOfWork {<PDA1 countryCode>: [placeOfWork]} [≥ 1 key], SD Groups 11–12
│   └── [each array item:]
│       ├── companyOrVesselName (string), mandatory | SD Group 11
│       ├── flagBaseHomeState (string), optional | SD Group 11
│       ├── companyID (string), optional† | SD Group 11
│       ├── typeOfID (enum), optional† | SD Group 11
│       └── address (addressPDA1State), mandatory | SD Group 12
│       [† companyID and typeOfID are mutually required]
│       [empty array = works in that country with no fixed address]
├── statusConfirmation [1:1], SD Group 13
│   ├── statusConfirmationCode (enum, 12 codes), mandatory | SD Group 13
│   └── exceptionDescription (string), conditional‡ | SD Group 13
│       [‡ only permitted when statusConfirmationCode = "11"]
├── documentID (string) [1:1], SD Group 14
└── competentInstitution [1:1], SD Groups 15–16
    ├── institutionID (string), mandatory | SD Group 15
    ├── institutionName (string), mandatory | SD Group 15
    ├── countryCode (PDA1 code), mandatory | SD Group 15
    ├── address (addressPDA1State), mandatory | SD Group 16
    ├── officeFaxNumber (E.164 string), optional | SD Group 16
    ├── officePhoneNumber (E.164 string), optional | SD Group 16
    └── email (string), optional | SD Group 16

Selective Disclosure: SD is applied at element-group level, individual fields within a group are not independently selectable. memberstateAppliedLegislation is Non-SD and is always fully disclosed to the Relying Party.

Attestation Classification (contextual, not a schema element): This attestation MAY be classified as QEAA, PuB-EAA, or EAA depending on the issuing institution's qualification status under eIDAS 2.0.

3.1.1 Definitions

The following shared types are defined in $defs of the v1.0 schema and referenced throughout Sections 2.3–2.9.

gender

ISO/IEC 5218 gender code (string enum): "0" = Not known / Not specified · "1" = Male · "2" = Female.

addressBase

Base postal address object:

addressPDA1State

Postal address restricted to a PDA1-participating country. Extends addressBase with:

No additional properties permitted (unevaluatedProperties: false).

addressWorld

Postal address for any recognized country in the world. Extends addressBase with:

No additional properties permitted (unevaluatedProperties: false).

phoneNumber

Phone number in E.164 international format (e.g., +4930123456). Pattern: ^\+[1-9]\d{1,14}$.

email

Email address conforming to RFC 5321/5322. Pattern: ^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$.

countryCodePDA1States

ISO 3166-1 alpha-2 code restricted to the 32 PD A1-participating states: the 27 EU member states (AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GR, HR, HU, IE, IT, LT, LU, LV, MT, NL, PL, PT, RO, SE, SI, SK) plus Iceland (IS), Liechtenstein (LI), Norway (NO), Great Britain (GB), and Switzerland (CH).

ISO 3166-1 alpha-2 code covering 195 world states: the 193 United Nations member states plus the two UN observer states Holy See (VA) and State of Palestine (PS).

date

typeOfID

Type of identifier used for an employer, self-employed entity, or company at a place of work:

statusConfirmationCode

Details of a single employer or self-employment activity. All five fields are required. No additional properties permitted (additionalProperties: false).

placeOfWork

When a specific place of work is declared:

When no fixed place of work exists:

3.1.2 Subject

Personal details of the PD A1 certificate holder. All seven top-level keys (pin, gender, names, dateOfBirth, nationalities, placeOfBirth, address) are required. No additional properties permitted (additionalProperties: false).

The address object MUST satisfy anyOf: either stateOfResidence is present with minItems: 1, or stateOfStay is present with minItems: 1 (both MAY be present simultaneously). Only stateOfResidence and stateOfStay are permitted in address (additionalProperties: false). The names and placeOfBirth sub-objects also enforce additionalProperties: false.

3.1.3 Member State Legislation

The member state whose social security legislation applies to the holder. This section is annotated $comment: "Always disclosed", it is Non-SD and is fully disclosed to the Relying Party in every presentation. No additional properties permitted (additionalProperties: false).

3.1.4 Employer / Self-Employment Details

employmentSituations is an array of employmentSituation objects (see §2.2). At least one item is required (minItems: 1). Each item's fields are listed below with their SD group annotations.

3.1.5 Places of Work

placesOfWork is a JSON object (not an array) whose property names are countryCodePDA1States values. At least one property must be present (minProperties: 1). Each property value is an array of placeOfWork objects (see §2.2). An empty array indicates the holder works in that country with no fixed address.

† companyID and typeOfID are co-dependent: if either is present, the other MUST also be present.

3.1.6 Status Confirmation

documentID is a top-level string, the unique identifier of the issued PD A1 certificate.

3.1.7 Competent Institution

The social security institution that issued this certificate. The four fields institutionID, institutionName, countryCode, and address are required. No additional properties permitted (additionalProperties: false).

3.2 Mandatory attributes

3.3 Optional attributes

3.4 Conditional attributes

4 Metadata

Note: The attributes listed below are not part of the v1.0 PD A1 attestation data schema. They are defined at the encoding or framework layer (SD-JWT VC, eIDAS 2.0) and are subject to change as the encoding specification evolves.

The separation is intentional: an application-data schema describes semantic content, field names, types, and constraints, which remains stable across encoding formats. Issuance and transport metadata, by contrast, is format- and infrastructure-specific (SD-JWT VC claim names, eIDAS 2.0 lifecycle attributes). Mixing them would couple a stable data definition to volatile infrastructure choices, and would prevent the schema from being reused across different encoding formats. Metadata attributes are therefore defined at the framework or protocol layer and referenced here for completeness only.

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Legal category. This Rulebook retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1], whose value for this category is eaa:eu:non-qualified. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires attestation_legal_category, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

4.4 Code lists

4.5 Integrity rules

The following rules are derived strictly from constraints in the v1.0 PD A1 attestation data schema. Rules concerning metadata (§2.10) are marked as framework-layer.

Top-level required properties: All seven properties, subject, memberstateAppliedLegislation, employmentSituations, placesOfWork, statusConfirmation, documentID, competentInstitution, MUST be present. No additional top-level properties are permitted (additionalProperties: false).

Date format: All date values MUST conform to the format YYYY-MM-DD and match the pattern ^\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|02-(?:0[1-9]|1\d|2[0-9]))$.

Country-code set, world (countryCodeWorld, 195 codes): MUST be used for subject.nationalities[], subject.placeOfBirth.countryCode, subject.address.stateOfResidence[].countryCode, and employmentSituations[].address.countryCode.

Country-code set, PDA1 (countryCodePDA1States, 32 codes): MUST be used for memberstateAppliedLegislation.memberstate, subject.address.stateOfStay[].countryCode, all property names (keys) of placesOfWork, placesOfWork.<CC>[].address.countryCode, competentInstitution.countryCode, and competentInstitution.address.countryCode.

Nationalities: subject.nationalities MUST contain at least one entry (minItems: 1) and MUST NOT contain duplicate codes (uniqueItems: true).

Subject address: subject.address MUST satisfy anyOf, either stateOfResidence is present with at least one item (minItems: 1), or stateOfStay is present with at least one item (minItems: 1); both MAY be present simultaneously. No properties other than stateOfResidence and stateOfStay are permitted in subject.address (additionalProperties: false).

Employment situations: employmentSituations MUST contain at least one item (minItems: 1). Each item MUST include all five required fields: typeOfEmployment, name, employerID, typeOfID, address. No additional properties are permitted per item (additionalProperties: false).

Places of work: placesOfWork MUST contain at least one country key (minProperties: 1). All property names MUST be valid countryCodePDA1States values. An empty array value is valid and means the holder works in that country with no fixed address. Each placeOfWork item MUST include address and companyOrVesselName. No additional properties are permitted per item (additionalProperties: false).

Company ID co-dependency: Within each placeOfWork, companyID and typeOfID are co-dependent (dependentRequired): if companyID is present then typeOfID MUST be present, and vice versa.

Status exception: statusConfirmation.statusConfirmationCode is required. statusConfirmation.exceptionDescription MUST NOT be present when statusConfirmationCode is any value other than "11". It is optional even when the code is "11".

No extra properties: The following objects enforce additionalProperties: false or unevaluatedProperties: false, no properties beyond those defined in the schema may appear in: subject, subject.names, subject.placeOfBirth, subject.address, memberstateAppliedLegislation, each employmentSituation, addressPDA1State, addressWorld, each placeOfWork, statusConfirmation, competentInstitution.

Metadata integrity rules (framework-layer, not v1.0 schema): issuance_date and expiry_date MUST be valid ISO 8601 DateTimes; expiry_date MUST be later than issuance_date; attestation_legal_category MUST be one of "QEAA", "PuB-EAA", or "EAA"; vct MUST be eu.we-build.pda1.1.

5 Formats

This chapter defines how the PD A1 attestation is serialized into a concrete verifiable-attestation format. It is important to keep two distinct layers apart:

• Application data (semantic content). The meaning of each attribute, its data type, and its allowed values or codelists are defined in Chapter 2 and are encoding-independent. Chapter 2 is the single source of truth for the data model.
• Attestation encoding & envelope (metadata). This chapter. It defines only how the Chapter 2 application data is serialized into a concrete verifiable-attestation format (SD-JWT VC), together with the envelope / metadata claims that wrap the application data (issuer, validity, credential type, holder binding, revocation status). These claims live at the SD-JWT VC / eIDAS 2.0 layer (see §2.10).

This chapter does not repeat field meanings, data types, or value codelists, see Chapter 2 for the data model.

5.1 SD-JWT VC-based encoding

The PD A1 attestation uses the SD-JWT VC format to allow for selective disclosure of citizen and employment attributes based on SD element groups.

Selective Disclosure: Disclosure is applied at the SD element group level, not at the individual field level. A Relying Party SHALL request disclosure of complete logical blocks (e.g., a full address block, a full employment block); it is not possible to disclose partial blocks (e.g., only the town from an address without the other address fields). The SD element group membership of every application-data attribute is given by the "SD Group" column in Chapter 2 (§2.3–§2.9); those groupings are not restated here. In particular, memberstateAppliedLegislation (§2.4) is Non-SD and is always fully disclosed.

The . notation is used to indicate the nesting of attributes.

Verifiable Credential Type (vct): vct: eu.we-build.pda1.1

5.1.1 Envelope / Metadata Claims

The claims below form the SD-JWT VC envelope that wraps the Chapter 2 application data. They are defined at the SD-JWT VC / eIDAS 2.0 layer and are not part of the Chapter 2 application data (see §2.10). This table lists only envelope claims, application-data attributes, their data types, and their codelists are defined in Chapter 2 and are not repeated here.

Notes:

• These claims are defined at the SD-JWT VC / eIDAS 2.0 layer, not in the Chapter 2 application data, and describe the attestation container rather than its subject.
• Envelope claims are always present in the envelope and are not selectively disclosable (marked Non-SD), with the exception of trust_anchor_url, which is optional (MAY).
• iss, iat, exp, jti, and cnf are registered JWT claims and follow RFC 7519 naming conventions.
• The application-data attributes wrapped by this envelope, and their SD element group membership, are defined in Chapter 2 (§2.3–§2.9).

5.1.2 Status Claim

PD A1 attestations are based on SD-JWT-based Verifiable Digital Credentials (SD-JWT VC). If a PD A1 attestation issued as an SD-JWT VC is meant to be valid for longer than 24 hours, the status claim as shown in SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) and specified in Token Status List (TSL) MUST be used according to this rulebook. This claim enables Relying Parties to determine whether a credential has been revoked via a status list mechanism as specified in Token Status List (TSL).

While the Token Status List (TSL) specification only suggests that the status object of an SD-JWT VC (if present) SHOULD be checked, this rulebook prescribes (and therefore overrules) that the status object of an SD-JWT VC PD A1 attestation (if present) MUST always be checked by the verifying party.

The status object of a PD A1 attestation SD-JWT VC MUST contain the following members according to Token Status List (TSL):

"status": {
    "status_list": {
      "idx": 0,
      "uri": "https://example.com/statuslists/1"
    }
  }

• status: OPTIONAL. The claim that references one or more mechanisms a relying party can use to look up status information about this credential. It's a container, and the specification allows different status mechanisms to sit inside it side by side.
• status_list: REQUIRED. The member identifying that the Token Status List mechanism is in use. It bundles together the two pieces of information needed to locate this credential's entry within a published status list. While the Token Status List (TSL) specification permits other status mechanisms to be used within the status claim, this rulebook prescribes that only the status_list mechanism MUST be used for PD A1 attestations if a status object is within the SD-JWT VC PD A1 attestation.
• idx: REQUIRED. The credential's assigned position in the status list. A relying party reads the bit(s) at this position to determine the credential's current status. It must be a non-negative integer.
• uri: REQUIRED. The address from which the Status List Token is retrieved. It must be a valid URI, and a relying party confirms it matches the sub claim of the fetched token before trusting the result.

For further details see section 6.2. in Token Status List (TSL).

The Token Status List (TSL) defines basic status types like VALID, INVALID and SUSPENDED. This rulebook limits the statuses allowed to be used for PD A1 SD-JWT VC attestations to only VALID and INVALID. Any status other than VALID or INVALID for a referenced VC is to be considered "not defined" and therefore MUST be treated as if the credential's status is INVALID.

5.1.3 Example Payload

A valid PD A1 JSON example is provided in pda1-sd-jwt-sample.json.

5.2 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5 (also called mdoc) is out of scope for this Rulebook, as specific aspects of offline proximity presentation are not a current requirement for the PD A1 attestation.

5.3 W3C Verifiable Credentials Data Model-based encoding

This Rulebook does not define a W3C Verifiable Credentials Data Model encoding for this attestation type.

6 Protocols

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI] and presented using OpenID for Verifiable Presentations [OpenID4VP], both as profiled by [HAIP].

7 Issuance

7.1 Binding

7.2 Issuance Policy

The PD A1 Attestation is a certificate that documents the applicable legislation regarding social security in a cross-border employment situation. It is mainly intended for verifying that a "posted worker" abroad is covered by the social security system of his "sending state"(home country) while temporarily working in a "receiving state". Based on an application by the "sending" employer, the PD A1 Attestation is issued by a competent social security institution of the "sending state".

Typical usage scenarios include:

• presentation by the posted worker to an official authority in the receiving state
• presentation by the posted worker towards an employer/contractor abroad
• presentation by the "posting" employer towards an employer/contractor abroad
• presentation by the "posting" employer (or an employer/contractor abroad) towards an official authority (abroad)
• offline or low-connectivity verification where the verifier can at least validate the credential signature, issuer, validity period, and disclosed PD A1 data without necessarily relying on an available real-time backend

Verification contexts include labour inspections, social security inspections, employee-to-employer/contractor, employer-to-employer interactions and administrative procedures. A Relying Party receiving the attestation SHALL verify: - the issuer signature; - the SD-JWT VC type (vct); - the issuer authorisation to issue PD A1 Attestation; - the credential validity period; - the credential status, where a status mechanism is present; - holder binding, where used; - the integrity rules defined in Section 3.1.7;

In EUDI Wallet related usage scenarios, the Relying Party SHOULD request and verify PID or another accepted identity credential - or compare the PD A1 subject data with other identification means - to verify that it matches the affected person. In such cases, the Relying Party SHOULD compare the relevant identity attributes with the PD A1 Attestation. The Relying Party SHALL apply data minimisation and SHALL request only the attributes required for their specific purposes.

Unlike many identity-related attestations, a PD A1 Attestation MAY legitimately be presented by different actors or wallets, i.e. EUDI or EBW, depending on the business process.

As the PD A1 Attestation is not only relevant for usage by the citizen but also by the applying employer and also in specific "transfer" scenarios, any holder binding MUST be handled in a flexible way, based on the intended usage and a decision taken during issuance: - The attestation MAY have no specific binding at all; - The Attestation MAY be device-bound through holder binding where supported by the EUDI Wallet and the applicable SD-JWT VC profile; - The attestation MAY be cryptographically bound to a PID or another accepted identity attestation where the usage requires stronger identity matching. Where this binding is used, the metadata attribute cryptographically_bound_to SHOULD contain: urn:eudi:pid:1

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

This chapter will be completed in a future version of this Rulebook.

9 Presentation

9.1 Presentation Policy

To verify and validate a received presentation of an attestation of this type, the following steps SHALL be performed:

1. verify the signature over the attestation using a trust anchor obtained as described in chapter 10;
2. verify that the attestation is within its validity period;
3. check revocation status as described in chapter 8, unless the attestation is short-lived, or its remaining lifetime is below the revocation time threshold;
4. verify device binding where section 7.1 records the attestation as device-bound;
5. request only those attributes that are necessary for the stated purpose of the transaction, and, where the trust model for this attestation requires Relying Party registration, only those attributes it is registered and authorised to request.

Obligations specific to this attestation type, carried over from the previous version of this Rulebook:

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is in scope only where chapter 5 records an mdoc encoding.

9.3 Transactional data

This Rulebook defines no transactional data.

10 Trust Framework

This chapter will be completed in a future version of this Rulebook.

Trust anchor location

The attribute or metadata carrying the trust anchor location contains at least the URL at which a machine-readable version can be found or looked up.

11 References

This chapter will be completed in a future version of this Rulebook.