diff --git a/1.3.0/404.html b/1.3.0/404.html new file mode 100644 index 0000000..d79ecb9 --- /dev/null +++ b/1.3.0/404.html @@ -0,0 +1,350 @@ + + + + + + + + + + + + + + + + + + + EUDI Wallet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+
+ +
+ + + + + + + + +
+ + + + + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ +

404 - Not found

+ +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/1.3.0/annexes/annex-01-initialisation-and-activation.pdf b/1.3.0/annexes/annex-01-initialisation-and-activation.pdf new file mode 100644 index 0000000..cbb870c Binary files /dev/null and b/1.3.0/annexes/annex-01-initialisation-and-activation.pdf differ diff --git a/1.3.0/annexes/annex-02-online-identification-and-authentication.pdf b/1.3.0/annexes/annex-02-online-identification-and-authentication.pdf new file mode 100644 index 0000000..a803f86 Binary files /dev/null and b/1.3.0/annexes/annex-02-online-identification-and-authentication.pdf differ diff --git a/1.3.0/annexes/annex-03-issuing-mdl.pdf b/1.3.0/annexes/annex-03-issuing-mdl.pdf new file mode 100644 index 0000000..dd5202b Binary files /dev/null and b/1.3.0/annexes/annex-03-issuing-mdl.pdf differ diff --git a/1.3.0/annexes/annex-04-presenting-mdl-proximity-supervised.pdf b/1.3.0/annexes/annex-04-presenting-mdl-proximity-supervised.pdf new file mode 100644 index 0000000..97796a8 Binary files /dev/null and b/1.3.0/annexes/annex-04-presenting-mdl-proximity-supervised.pdf differ diff --git a/1.3.0/annexes/annex-05-presenting-mdl-proximity-unsupervised.pdf b/1.3.0/annexes/annex-05-presenting-mdl-proximity-unsupervised.pdf new file mode 100644 index 0000000..a21a6da Binary files /dev/null and b/1.3.0/annexes/annex-05-presenting-mdl-proximity-unsupervised.pdf differ diff --git a/1.3.0/annexes/annex-06-pid-rulebook.pdf b/1.3.0/annexes/annex-06-pid-rulebook.pdf new file mode 100644 index 0000000..2a6ec7a Binary files /dev/null and b/1.3.0/annexes/annex-06-pid-rulebook.pdf differ diff --git a/1.3.0/annexes/annex-06-pid-rulebook/index.html b/1.3.0/annexes/annex-06-pid-rulebook/index.html new file mode 100644 index 0000000..fe8070c --- /dev/null +++ b/1.3.0/annexes/annex-06-pid-rulebook/index.html @@ -0,0 +1,1871 @@ + + + + + + + + + + + + + + + + + + + PID Rule Book - EUDI Wallet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + + + + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + +

PID Rule Book

+

for the EUDI Wallet ecosystem

+

November 2023 +v1.0.0

+

This is a working document that holds no legal value and does not +reflect any common agreement or position of the co-legislators. It +presents a state-of-play of ongoing work of the eIDAS Expert Group. This +document is being continuously updated and should not be considered +final.

+

1 Introduction

+

1.1 Scope

+

This document is the Person Identification Data (PID) Rule Book. It +contains requirements specific to the PID use case within the EUDI +Wallet. These requirements hold in addition to the requirements in the +Architecture Reference Framework (ARF), see [ARF]. Requirements in the +ARF hold for all use cases in the EUDI Wallet.

+

This PID Rule Book contains the following topics:

+
    +
  • Chapter 2 specifies the PID attribute schema. This describes the + structure, the type, the entity identifiers, and the logical + organization of the mandatory and optional attributes of the PID. It + also describes how Member States can specify any possible national + attributes. Two encodings for these attributes are specified, one + compliant with [ISO18013-5], the other compliant with [SD-JWT].
    • +
  • Chapter 3 specifies the Wallet Instance attestation schema, which + describes the same information for the Wallet Instance attestation + signed by the Wallet Provider for each Wallet Instance. This + information will be moved to another document in the future.
    • +
  • Chapter 4 specifies details about the trust infrastructure necessary + for PID attestations, for both ISO/IEC 18013-5-compliant and + SD-JWT-compliant encodings. This information may be moved to another + document in the future.
    • +
+

Further topics will be added if and when they are identified.

+

1.2 Key words

+

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

+

In addition, 'must' (non-capitalized) is used to indicate an external +constraint, i.e., a requirement that is not mandated by this document, +but, for instance, by an external document such as [ARF]. The word +'can' indicates a capability, whereas other words, such as 'will', and +'is' or 'are' are intended as statements of fact.

+

1.3 Terminology

+

This document uses the terminology specified in [ARF].

+

2 PID attribute schema

+

2.1 Overview

+

This chapter describes the structure, type, data element identifiers and +logical organisation of the mandatory and optional attributes of the PID +attestation within the EUDI Wallet, as well as the PID metadata:

+
    +
  • +

    Section 2.2 specifies the document type and namespace(s) for a PID + attestation:

    +
      +
    • +

      Section 2.2.1 specifies the PID document type, as well as the + EU-wide PID namespace within which the PID data elements defined + in this document are specified.

      +
      • +
    • +

      Section 2.2.2 describes how Member States can specify national + attributes by defining a domestic PID namespace.

      +
      • +
    +
    • +
  • +

    Section 2.3 specifies the set of data elements covering the PID + attributes specified in [ARF].

    +
    • +
  • +

    Section 2.4 similarly specifies the set of data elements covering + the PID metadata.

    +
    • +
  • +

    Section 2.5 specifies two different encodings for these data + elements. The first encoding uses Concise Binary Object + Representation (CBOR) and complies with ISO/IEC 18013-5:2021 + [ISO18013-5]. The second encoding uses JSON and complies with + [SD-JWT] and [OpenID4VP].

    +
    • +
+

2.2 Document type and namespace

+

2.2.1 EU-wide document type and namespace for PID attestation

+

The concepts of document type and namespace, and the way in which they +are used, are specified in ISO/IEC 18013-5. These concepts are used in +the same way in OpenID for Verifiable Presentations [OpenID4VP].

+

PID Providers SHALL use the document type "eu.europa.ec.eudi.pid.1" for +PID attestations. This value follows the recommendation in ISO/IEC +18013-5 to use the general format [Reverse Domain].[Domain Specific +Extension]. Since the European Commission controls the domain +ec.europa.eu, this document type value will not collide with any +document type potentially defined by other organisations. The version +number "1" in this document type MAY be used to distinguish between the +first version of the ISO-compliant PID attribute (defined in this +document) and any future version.

+

Similarly, PID Providers SHALL use the value "eu.europa.ec.eudi.pid.1" +for the namespace of the first version of the PID attributes and PID +metadata specified in sections 2.3 and 2.41. This namespace clearly +indicates that any data elements defined within it are Person +Identification Data specified in the context of the EUDI Wallet. Again, +the version number "1" allows for future extension(s) or change(s) of +the PID data elements defined the next section.

+

PID Providers SHALL use this document type and namespace for the ISO/IEC +18013-5 compliant data element encoding specified in section 2.5.2 and +for the SD-JWT-compliant encoding in section 2.5.3.

+

2.2.2 Domestic PID namespaces for national attributes

+

ISO/IEC 18013-5 specifies a mechanism called domestic namespaces, +allowing PID Providers to issue such national attributes to an EUDI +Wallet. To do so, a PID Provider SHALL define a domestic PID namespace. +Within that namespace, the PID Provider is free to define any attribute +it needs, for example, a national social security number or taxpayer +identification number (TIN).

+

If a PID Provider chooses to define a domestic namespace, it SHALL +append the applicable ISO 3166-1 alpha-2 country code or the ISO 3166-2 +region code, separated by a period, to the EU-wide PID namespace, +excluding the version number. The PID Provider MAY include a version +number in the domestic namespace.

+

EXAMPLE: The first domestic PID namespace for Germany could be +"eu.europa.ec.eudi.pid.de.1".

+

PID Providers SHALL use the same domestic namespace for both ISO/IEC +18013-5-compliant PIDs and SD-JWT-compliant PIDs, see section 2.5.

+

A PID Provider that defines a domestic namespace SHALL publish the +namespace, including all data element identifiers, their definition, +presence and encoding format, on a website that is publicly available. A +central registry for such domestic namespace definitions MAY be +established in the future.

+

2.3 PID attributes

+

2.3.1 Introduction

+

Data elements corresponding to the PID attributes specified in [ARF] +are defined in Table 1 in section 2.3.2. Data elements corresponding to +the PID metadata specified in [ARF] are defined in Table 2 in section +2.4.1.

+

Note that the metadata data elements defined in section 2.4.1 are +handled by PID Providers, PID Users and Relying Parties in exactly the +same way as the data elements corresponding to the PID attributes in +Table 1. There is no technical difference between these data elements. +The only reason to distinguish between PID attributes and PID metadata +is because the ARF makes this distinction.

+

Table 1 and Table 2 contain the following information:

+
    +
  • +

    The first column of both tables lists all PID attributes and PID + metadata (respectively) specified in section 5.1.1.1 of [ARF].

    +
    • +
  • +

    For each of these attributes and metadata, the second column + specifies the identifiers of one or more corresponding data + elements. In case more than one data element is specified for a + single PID attribute or metadata, the reasons for this are explained + in the subsection referenced in the first column. The data element + identifiers in the second column SHALL be used in requests and + responses according to [ISO18013-5] or [OpenID4VP], as + applicable. There SHALL be at most one data element with the same + data element identifier in each PID attribute.

    +
    • +
+
+

NOTE: Data element values MAY be multi-value. If so, this is clearly +indicated.

+
+
    +
  • +

    The third column describes the meaning of the data element.

    +
    • +
  • +

    The fourth column specifies whether the presence of the element in a + PID attribute is mandatory (M), or optional (O).

    +
    • +
+
+

NOTE: If Table 1 or Table 2 indicates a data element as mandatory, +this solely means that the PID Provider SHALL ensure that this element +is present in the PID. It does not imply that a Relying Party is +required to request such a data element when interacting with the +Wallet Instance. Neither does it imply that the PID User cannot refuse +to release a mandatory data element if requested.

+
+
    +
  • +

    The fifth column indicates how the data elements SHALL be encoded, + using the CDDL representation types defined in [RFC 8610]. Section + 2.5. specifies how these representation types SHALL be serialized + into CBOR and JSON data structures, respectively. Note the + following:

    +
      +
    • +

      tstr, uint, bstr, bool and tdate are CDDL representation types + defined in [RFC 8610].

      +
      • +
    • +

      All data elements having encoding format tstr SHALL have a + maximum length of 150 characters.

      +
      • +
    • +

      This document specifies full-date as full-date = #6.1004(tstr), + where tag 1004 is specified in [RFC 8943].

      +
      • +
    • +

      In accordance with [RFC 8949], section 3.4.1, a tdate data + element shall contain a date-time string as specified in [RFC + 3339]. In accordance with [RFC 8943], a full-date data + element shall contain a full-date string as specified in [RFC + 3339].

      +
      • +
    • +

      The following requirements SHALL apply to the representation of + dates in data elements, unless otherwise indicated:

      +
        +
      • +

        Fractions of seconds SHALL NOT be used;

        +
        • +
      • +

        A local offset from UTC SHALL NOT be used; the time-offset + defined in [RFC 3339] SHALL be to "Z".

        +
        • +
      +
      • +
    +
    • +
+

2.3.2 Overview

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PID attribute in [ARF]Corresponding data element identifier(s)DefinitionPresenceEncoding format
Current Family Name
family_nameCurrent last name(s) or surname(s) of the PID User.Mtstr
Current First Names
given_nameCurrent first name(s), including middle name(s), of the PID User.Mtstr
Date of Birth
(See section 2.3.3)
birth_dateDay, month, and year on which the PID User was born.Mfull-date
age_over_18Attesting whether the PID User is currently an adult (true) or a minor (false).Obool
age_over_NNAdditional current age attestations, NN <> 18.Obool
age_in_yearsThe current age of the PID User in years.Ouint
age_birth_yearThe year when the PID User was born.Ouint
Family Name at Birth
family_name_birthLast name(s) or surname(s) of the PID User at the time of birth.Otstr
First Names at Birth
given_name_birthFirst name(s), including middle name(s), of the PID User at the time of birth.Otstr
Current Family Name
family_nameCurrent last name(s) or surname(s) of the PID User.Mtstr
Place of Birth
(See section 2.3.4)
birth_placeThe country, state, and city where the PID User was born.Otstr
birth_countryThe country where the PID User was born, as an Alpha-2 country code as specified in ISO 3166-1.Otstr
birth_stateThe state, province, district, or local area where the PID User was born.Otstr
birth_cityThe municipality, city, town, or village where the PID User was born.Otstr
Current Address
(See section 2.3.5)
resident_addressThe full address of the place where the PID User currently resides and/or can be contacted (street name, house number, city etc.).Otstr
resident_countryThe country where the PID User currently resides, as an Alpha-2 country code as specified in ISO 3166-1.Otstr
resident_stateThe state, province, district, or local area where the PID User currently resides.Otstr
resident_cityThe municipality, city, town, or village where the PID User currently resides.Otstr
resident_postal_codePostal code of the place where the PID User currently resides.Otstr
resident_streetThe name of the street where the PID User currently resides.Otstr
resident_house_numberThe house number where the PID User currently resides, including any affix or suffix.Otstr
Gender
genderPID User’s gender, using a value as defined in ISO/IEC 5218.Ouint
Nationality / Citizenship
(See section 2.3.6)
nationalityAlpha-2 country code as specified in ISO 3166-1, representing the nationality of the PID User.ONationality, see section 2.3.6
+

Table 1 PID attributes and corresponding data elements

+ +

[ARF] specifies 'Date of Birth' as a mandatory data element in a PID +attribute. This document defines the following data elements related to +this PID attribute:

+
    +
  • birth_date (mandatory)
    • +
  • age_birth_year (optional)
    • +
  • age_in_years (optional)
    • +
  • age_over_18 (optional)
    • +
  • age_over_NN, NN \<> 18 (optional)
    • +
+

Having multiple data elements instead of a single one allows having +different levels of granularity for requests and responses, and thus +allows issuers and Relying Parties to practice data minimization. For +example, in some use cases, a Relying Party only needs to establish that +the PID User is not a minor. In that case, requesting age_over_18 +suffices. Releasing more specific information, such as the PID User's +age in years or birth year, would then constitute an unnecessary +infringement of the User's privacy.

+

This document specifies age_over_18 and other age_over_NN data +elements as optional data elements. PID Providers are free to add more +age_over_NN data elements.

+

The requirements in clause 7.2.5 of ISO/IEC 18013-5 SHALL be applicable +for the age_over_18 and age_over_NN data element in the PID set. +This document affirms that issuing more (rather than fewer) +age_over_NN data elements in a PID is beneficial for the PID User's +privacy. Note that the usage of the age_over_NN data element is more +complicated than it may look at first sight. The examples in ISO/IEC +18013-5 Annex D.2.2 will help to understand how the age_over_NN data +element is to be used and interpreted.

+ +

[ARF] specifies 'Place of Birth' as an optional data element in a PID +attribute. This document defines the following data elements related to +this PID attribute:

+
    +
  • birth_place (optional)
    • +
  • birth_country (optional)
    • +
  • birth_state (optional)
    • +
  • birth_city (optional)
    • +
+

Having multiple data elements instead of a single one allows having +different levels of granularity for requests and responses, and thus +allows issuers and Relying Parties to practice data minimization.

+ +

[ARF] specifies 'Current Address' as an optional data element in the +PID set. This document defines a number of current address-related data +elements:

+
    +
  • resident_address (optional)
    • +
  • resident_country (optional)
    • +
  • resident_state (optional)
    • +
  • resident_city (optional)
    • +
  • resident_postal_code (optional)
    • +
  • resident_street (optional)
    • +
  • resident_house_number (optional)
    • +
+

Having multiple data elements instead of a single one allows different +levels of granularity for requests and responses, and thus allows +issuers and Relying Parties to practice data minimisation. For example, +in some contexts a RP must verify only that the PID User is a resident +of a certain country. Releasing more specific address information such +as state, city or postal code would then constitute an unnecessary +infringement of the User's privacy.

+

Note that in most cases requesting a PID User's resident street and +house number will not make sense without simultaneously requesting at +least the resident city, as there will be many duplicate street names +and house numbers in a given country. These data elements have been +added primarily to assist in, for example, automated form filling.

+

2.3.6 Nationality / Citizenship

+

The ARF specifies 'Nationality / Citizenship' as a possible additional +optional data element in the PID set and notes that this is potentially +a multi-valued attribute, because a citizen can have more than one +nationality.

+

This document defines a data element nationality taking as its value a +single Alpha-2 country code. This implies that any additional +nationality of the PID User must be added by the respective Member State +as a domestic data element, see section 2.2.2. This possibility is also +recognized in [ARF].

+

2.4 PID metadata

+

2.4.1 Overview

+

Section 5.1.1 of [ARF] says: "Metadata associated with the PID may +additionally detail the date of issuance and/or expiration, the issuing +authority and/or Member State, information necessary to perform holder +binding and/or proof of possession, the information or location of the +services that can be used to enquire about the validity status of and +potentially more information."

+

The first column of Table 2 contains all the PID metadata identified in +the quote above. The meaning of the remaining columns is explained in +section 2.3.1.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PID metadata in [ARF]ISO-compliant data element identifierDefinitionPresenceEncoding format
Date of issuance
issuance_dateDate (and possibly time) when the PID was issued.Mtdate or full-date
Date of expiration
expiry_dateDate (and possibly time) when the PID will expire.Mtdate or full-date
Issuing authority
issuing_authorityName of the administrative authority that has issued this PID instance, or the ISO 3166 Alpha-2 country code of the respective Member State if there is no separate authority authorized to issue PIDs.Mtstr
document_numberA number for the PID, assigned by the PID Provider.Otstr
administrative_numberA number assigned by the PID Provider for audit control or other purposes.Otstr
Member State
issuing_countryAlpha-2 country code, as defined in ISO 3166-1, of the PID Provider’s country or territory.Mtstr
issuing_jurisdictionCountry subdivision code of the jurisdiction that issued the PID, as defined in ISO 3166-2:2020, Clause 8. The first part of the code SHALL be the same as the value for issuing_country.Otstr
Validity status location informationTo be decided
+

Table 2 PID metadata and corresponding data elements

+

2.4.2 Validity status information

+
+

NOTE: PID revocation will be further detailed in a future version of +ARF. Probably validity status information will not be included in the +PID metadata, but rather in the cryptographic proof structures, i.e., +the MSO for ISO-compliant PIDSs and the SD-JWT for SD-JWT-compliant +PIDs.

+
+

2.5 PID data element encodings

+

2.5.1 Introduction

+

Requirement 6 in section 5.1.2 of the ARF specifies that PID attestation +must be issued in accordance with both the data model specified in +ISO/IEC 18013-5:2021 [ISO18013-5] and the W3C Verifiable Credentials +Data Model 1.1. Requirements 7 and 8 make clear that for the latter +encoding, Selective Disclosure JSON Web Tokens (SD-JWT), as specified in +[SD-JWT], must be used, and that consequently, data elements must be +encoded in JSON. For the former, data elements must be encoded in CBOR.

+

This section therefore specifies two separate encodings for the PID data +model, an ISO/IEC 18013-5-compliant encoding in CBOR, and a +SD-JWT-compliant encoding in JSON.

+

2.5.2 ISO/IEC 18013-5-compliant encoding

+
2.5.2.1 Encoding rules
+

If data elements specified in in Table 1 or Table 2 are encoded with +CBOR, they SHALL be encoded as specified in [RFC 8949].

+

The CDDL representation types used in Table 1 and Table 2 are specified +in section 2.3.1. Rules to encode CDDL representation types with CBOR +are specified [RFC 8610] and [RFC 8949].

+
2.5.2.2 Further stipulations
+

The value of all data elements (both PID attributes and PID metadata) +SHALL be valid at the value of the timestamp in the validFrom element in +the MSO from ISO/IEC 18013-5 clause 9.1.2.46.

+
+

NOTE: The value of the age_over_18, age_over_NN and age_in_years +data elements, if present, changes whenever the PID User has a +birthday. The value of many other data elements will also change over +time. It is up to the PID Provider to ensure that the above +requirement is complied with. This document does not require that an +issuer issues a new PID as soon as it becomes aware of a change in the +PID User's data.

+
+

The issue_date data element (Table 2) SHALL NOT be later than the +validFrom element in the MSO, as defined in clause 9.1.2.4 of ISO/IEC +18013-5.

+

If the Relying Party retrieved the issuing_country data element (Table +2), it SHALL verify that the value of that element matches the +countryName element in the Subject field within the Document Signer +certificate; see ISO/IEC 18013-5 Annex B.

+

If the Relying Party retrieved the issuing_jurisdiction data element +(Table 2), it SHALL verify that the value of that element matches the +stateOrProvinceName element, if it is present in the Subject field +within the Document Signer certificate; see ISO/IEC 18013-5 Annex B.

+

Data elements in Table 1 and Table 2 SHALL be released only as Issuer +Signed Items, as specified in [ISO/IEC 18013-5]. This means that these +data elements SHALL be signed by the PID Provider, not by the Wallet +Instance.

+

At the discretion of the PID Provider, domestic data elements (see +section 2.2.2) MAY be signed either by the PID Provider or by the Wallet +Instance.

+

2.5.3 SD-JWT-compliant encoding

+
2.5.3.1 Encoding rules
+

If data elements are encoded with JSON, they SHALL be encoded as +specified in [RFC 8259].

+

The CDDL representation types used in Table 1 and Table 2 are specified +in section 2.3.1. Rules to encode CDDL representation types with JSON +are specified in [RFC 8949] section 6.1 Given the CDDL representation +types used in the current version of this document, the following rules +are relevant:

+
    +
  • A CDDL uint (i.e., an unsigned integer) becomes a JSON number.
    • +
  • A CDDL bstr (i.e., a byte string) is encoded in base64url without + padding and becomes a JSON string.
    • +
  • A CDDL tstr (i.e., a UTF-8 text string) becomes a JSON string7.
    • +
  • A CDDL bool (i.e., a Boolean) becomes a JSON false or a JSON true, + as applicable.
    • +
  • A CDDL tdate or full-date (which is a tagged item or 'tag') becomes + a JSON string representing the content of the tag; the tag number is + ignored.
    • +
+

Although not used in the current version of this document, the following +CDDL representation types are frequently used in general, and hence +rules to encode them with JSON may become relevant in future versions:

+
    +
  • A CDDL array (i.e., a structure enclosed in square brackets [ ]) + becomes a JSON array.
    • +
  • A CDDL nint (i.e., a negative integer) becomes a JSON number.
    • +
  • A CDDL map (i.e., a structure enclosed in curly brackets { }) + becomes a JSON object. Since this is possible directly only if all + keys are UTF-8 strings, any CDDL maps defined in future versions of + this document SHALL only use keys that are UTF-8 strings.
    • +
+

If other CDDL representation types will be used in future versions of +this document, the corresponding rules for encoding them with JSON will +be added here.

+
2.5.3.2 Further stipulations
+

Data elements in Table 1 and Table 2 SHALL be released only in a VP +Token, as specified in [OpenID4VP]. This means that these data +elements SHALL be signed by the PID Provider, not by the Wallet +Instance.

+

At the discretion of the PID Provider, domestic data elements (see +section 2.2.2) MAY be released in either a VP Token or an ID Token.

+

3 Wallet Instance attestation attribute schema

+
+

NOTE: the information in this chapter does not pertain to the PID +directly. It will be included in a separate Wallet Attestation +Rulebook, to be detailed in a future version of ARF.

+
+

3.1 Introduction

+

The Trust Model [TrustModel] introduces the concept of a Wallet +Instance Attestation issued by the Wallet Provider for each Wallet +Instance.

+

3.2 Document type and namespace

+

Like any other attestation, a Wallet Instance Attestation needs a +document type and a namespace. The document type +"eu.europa.ec.eudi.wallet-instance.1" SHALL be used for this purpose, +and the namespace "eu.europa.ec.eudi.wallet-instance.1" SHALL be used to +identify data elements in this Wallet Instance Attestation.

+

3.3 Data model

+

Please note that there currently is no specification of a Wallet +Instance Attestation and the attributes in it, either within the context +of the EUDI Wallet or in an international standard or specification. +Once this is available, a corresponding data model will be added in this +section, comparable to the one for the PID in chapter 2.

+

4 Trust infrastructure details

+

4.1 Introduction

+

To trust a signature over a PID attestation, the RP needs a mechanism to +validate that the public key it uses to verify that signature is +trusted. Both ISO/IEC 18013-5 and OpenID4VP provide such mechanisms. +However, in both cases, additional details need to be specified to fully +specify these mechanisms for PID attestations within the EUDI Wallet +ecosystem.

+

4.2 ISO/IEC 18013-5-compliant PID attestations

+ +

ISO/IEC 18013-5 specifies an X.509-based PKI for the purpose of trusting +public keys. This PKI has multiple roots; there is an independent +(self-signed) root certificate for every issuer. Annex B of the standard +specifies the formats of the X.509 certificates for all participants in +the ecosystem.

+

These certificate formats are mDL-specific, but only because they use +the following Object Identifier (OID): id-mdl OBJECT IDENTIFIER ::= { +iso(1) standard(0) 18013 5 }8, as well as a number of child OIDs +('arcs') of this OID, see Annex B.1.1 of ISO/IEC 18013-5. All other +aspects of these certificate profiles can be used for any type of mobile +document complying with the security mechanisms defined in ISO/IEC +18013-5, including a PID attestation within the EUDI Wallet ecosystem.

+

To make the certificate profiles applicable for PIDs in ISO/IEC +18013-5-compliant EUDI Wallets, this document specifies the following +OIDs (in ASN.1 notation):

+
    +
  • id-eudi OBJECT IDENTIFIER ::= {european-commission 2}
    • +
+

- -- arc for EUDI Wallets

+
    +
  • id-eudi-iso OBJECT IDENTIFIER ::= {id-eudi 0}
    • +
+

- - arc for ISO/IEC 18013-5-compliant EUDI Wallets9

+
    +
  • +

    id-eudi-iso-pid OBJECT IDENTIFIER ::= {id-eudi-iso 0} -- arc for PID + attributes within ISO-compliant EUDI Wallets

    +
    • +
  • +

    id-eudi-iso-pid-kp OBJECT IDENTIFIER ::= {id- eudi-iso-pid 1}

    +
    • +
+

- - arc for extended key purposes within certificates used for PID +attributes within ISO-compliant EUDI Wallets

+
    +
  • id-eudi-iso-pid-kp-DS OBJECT IDENTIFIER ::= {id-eudi-iso-pid-kp 2}
    • +
+

- - arc for document signer certificates, used by PID Providers

+
    +
  • id-eudi-iso-pid-kp-ReaderAuth OBJECT IDENTIFIER ::= + {id-eudi-iso-pid-kp 6}
    • +
+

- - arc for mdoc reader authentication certificates, used by Relying +Parties requesting PIDs10

+
    +
  • id-eudi-iso-pid-kp-IACALink OBJECT IDENTIFIER ::= + {id-eudi-iso-pid-kp 4}
    • +
+

- - arc for IACA Link certificates, used by PID Providers

+
    +
  • id-eudi-iso-pid-kp-IACA OBJECT IDENTIFIER ::= {id-eudi-iso-pid-kp 7}
    • +
+

-- - arc for IACA Root certificates, used by PID Providers

+

These OIDs SHALL be used in certificates used for PID attributes within +the ISO-compliant EUDI Wallet ecosystem, in exactly the same way as the +corresponding OIDs specified in ISO/IEC 18103-5 are used within the +mobile driving license ecosystem.

+

Notes:

+
    +
  • +

    The numbers for the various extended key purposes are taken from + ISO/IEC 18013-5.

    +
    • +
  • +

    These new OIDs will have to be officially registered.

    +
    • +
  • +

    The OID european-commission is already registered: + european-commission ::= {iso(1) identified-organization(3) + european-commission(130)}. The respective Registration Authority for + this OID will have to be consulted to get approval for the proposed + addition of an arc for the EUDI Wallet.

    +
    • +
+

4.2.2 Trusted Issuer List

+

Section 4.2.2. of [TrustModel] describes the concept of a trusted list +of Issuers. This document specifies that for PID attestations, such a +trusted list SHALL be used. Relying Parties SHALL only trust PID issuers +that are included in a trusted list of PID Providers. Additionally, +there SHALL be only a single trusted list of PID Providers, which SHALL +be generated and maintained by a yet-to-be-determined party. This list +SHALL also contain the (root) certificate(s) of each PID Provider.

+

Regarding the format of this trusted list, the format specified ETSI TS +119 612 v2.1.1 SHALL be used.

+

4.3 SD-JWT-compliant PID attestations

+
+

NOTE: Details on the trust infrastructure for SD-JWT and +OpenID4VP-compliant PIDs will be detailed in a future version of ARF.

+
+

5 References

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[ARF]The Common Union Toolbox for a Coordinated Approach Towards a European Digital Identity Framework – The European Digital Identity Wallet Architecture and Reference Framework, November 2023, Version 1.2.0
[ISO18013-5]ISO/IEC 18013-5, Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application, First edition, 2021-09
[SD-JWT]Selective Disclosure for JWTs (SD-JWT)
draft-ietf-oauth-selective-disclosure-jwt-04, 11 April 2023 [1]
Retrievable from https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
[OpenID4VP]OpenID for Verifiable Presentations – draft 18, 21 April 2023 [2]
Retrievable from https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
[2015/1505]COMMISSION IMPLEMENTING DECISION (EU) 2015/1505
of 8 September 2015 laying down technical specifications and formats relating to trusted lists pursuant to Article 22(5) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market
[RFC 2119]RFC 2119 - Key words for use in RFCs to Indicate Requirement LevelsS. Bradner, March 1997
[RFC 3339]RFC 3339 - Date and Time on the Internet: Timestamps, G. Klyne et al., July 2002
[RFC 8259]RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format, T. Bray, Ed., December 2017
[RFC 8610]RFC 8610 - Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures, H. Birkholz et al., June 2019
[RFC 8943]RFC 8943 -Concise Binary Object Representation (CBOR) Tags for Date, M. Jones et al., November 2020
[RFC 8949]RFC 8949 - Concise Binary Object Representation (CBOR), C. Bormann et al., December 2020
[TrustModel]Trust Model for the EUDI Wallet Ecosystem – generic for all use cases, version 0.8.1, 2023-05-25
+
+
+
    +
  1. +

    Note that the document type and namespace have the same value. +This is allowed according to ISO/IEC 18013-5. ↩

    +
    2. +
  2. +

    Please note that the current specification does not yet foresee a +solution for the situation when the date of birth of the User is +incomplete or unknown. Work is ongoing to find a solution to this +scenario, in alignment with current implementation of eIDAS nodes. ↩

    +
    3. +
  3. +

    See footnote 2. ↩

    +
    4. +
  4. +

    Please note that the current specification does not yet foresee a +solution for the situation when the date of birth of the User is +incomplete or unknown. Work is ongoing to find a solution to this +scenario, in alignment with current implementation of eIDAS nodes. ↩

    +
    5. +
  5. +

    See footnote 2. ↩

    +
    6. +
  6. +

    As explained in [TrustModel], server retrieval, as specified in +ISO/IEC 18013-5, SHALL NOT be used for EUDI Wallets. ↩

    +
    7. +
  7. +

    Note that JSON requires escaping certain characters ( ): quotation +mark (U+0022), reverse solidus (U+005C), and the \"C0 control +characters\" (U+0000 through U+001F). All other characters are +copied unchanged into the JSON UTF-8 string. ↩

    +
    8. +
  8. +

    Note that this notation is incorrect. The http://oid-info.com/ +website officially registers this OID as {iso(1) standard(0) +driving-licence(18013) part-5(5)}. This does not impact the value of +the OID. ↩

    +
    9. +
  9. +

    The presence of this arc allows SD-JWT-compliant implementations +of the EUDI Wallet to have their own arc 'next' to this one, if +necessary. ↩

    +
    10. +
  10. +

    Note that the use of this PID-specific OID implies that an mdoc +reader authentication certificate containing this OID cannot be used +to perform Relying Party authentication for any other type of +attestation within the EUDI Wallet. This is by design, as it seems +good for security to separate reader authentication per attestation +type. However, decisions regarding Relying Party authentication will +be detailed in a future version of ARF. ↩

    +
    11. +
  11. +

    The exact version to be referenced is to be determined. [ARF] +references v0.2 of 30 December 2022. v0.4 is the latest version +available at the time of writing of this document. The level of +interoperability between these versions is not known. As [SD-JWT] +is still under development, presumably later versions will become +available over time. ↩

    +
    12. +
  12. +

    The exact version to be referenced is to be determined. [ARF] +references v0.14 of 30 December 2022. Draft 18 is the latest version +available at the time of writing of this document. The level of +interoperability between these versions is not known. As +[OpenID4VP] is still under development, presumably later versions +will become available over time. ↩

    +
    13. +
  13. +

    The exact version to be referenced is to be determined. [ARF] +references v0.2 of 30 December 2022. v0.4 is the latest version +available at the time of writing of this document. The level of +interoperability between these versions is not known. As [SD-JWT] +is still under development, presumably later versions will become +available over time. ↩

    +
    14. +
  14. +

    The exact version to be referenced is to be determined. [ARF] +references v0.14 of 30 December 2022. Draft 18 is the latest version +available at the time of writing of this document. The level of +interoperability between these versions is not known. As +[OpenID4VP] is still under development, presumably later versions +will become available over time. ↩

    +
    15. +
+
+ + + + + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/1.3.0/annexes/annex-07-mdl-rulebook.pdf b/1.3.0/annexes/annex-07-mdl-rulebook.pdf new file mode 100644 index 0000000..b811794 Binary files /dev/null and b/1.3.0/annexes/annex-07-mdl-rulebook.pdf differ diff --git a/1.3.0/annexes/annex-07-mdl-rulebook/index.html b/1.3.0/annexes/annex-07-mdl-rulebook/index.html new file mode 100644 index 0000000..60fe4da --- /dev/null +++ b/1.3.0/annexes/annex-07-mdl-rulebook/index.html @@ -0,0 +1,605 @@ + + + + + + + + + + + + + + + + + + + mDL Rule Book - EUDI Wallet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + + + + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + +

mDL Rule Book

+

for the EUDI Wallet ecosystem

+

November 2023 +v1.0.0

+

This is a working document that holds no legal value and does not +reflect any common agreement or position of the co-legislators. It +presents a state-of-play of ongoing work of the eIDAS Expert Group. This +document is being continuously updated and should not be considered +final.

+

Introduction

+

This document is the mobile driving license (mDL) Rule Book. It contains +requirements specific to the mDL use case within the EUDI Wallet. These +requirements hold in addition to the requirements in the Architecture +Reference Framework (ARF), see [ARF]. Requirements in the ARF hold for +all use cases in the EUDI Wallel.

+

This mDL Rule Book contains the following topics:

+
    +
  • +

    Chapter 0 specifies the mDL attribute schema. This describes the + structure, the type, the entity identifiers, and the logical + organisation of the mandatory and optional attributes of the mDL. It + also describes how Member States can specify any possible national + attributes.

    +
    • +
  • +

    Chapter 3 specifies details about the trust infrastructure necessary + for mDL attestations. This information may be moved to another + document in the future.

    +
    • +
+

Further topics will be added if and when they are identified.

+

1 mDL attribute schema {#mdl-attribute-schema .list-paragraph}

+

1.1 Introduction

+

This document describes the structure, type, data element identifiers, +and logical organisation of the mandatory and optional attributes of the +mobile driving license (mDL) attestation within the EUDI Wallet. It also +describes how Member States can specify any possible national +attributes.

+

Requirement 7 in section 5.2.1 of the ARF specifies that (Q)EAAs must be +issued in accordance with one of the data models specified in ISO/IEC +18013-5:2021 or in the W3C Verifiable Credentials Data Model 1.1. +Requirements 8 and 10 make clear that for the latter encoding, Selective +Disclosure JSON Web Tokens (SD-JWT) must be used, and that consequently, +data elements must be encoded in JSON. For the former, data elements +must be encoded in CBOR.

+

However, mobile driving licenses are legally specified in the proposed +EC Regulation 2023_127 (4^th^ Driving License Regulation). This +Regulation specifies that mDLs shall comply with the ISO/IEC 18013-5 +standard. It does not mention any other standards, in particular not +[SD JWT]. Consequently, mDLs issued to a EUDI Wallet instance shall +not be implemented as [SD JWT]-compliant document. This document +therefore specified only an ISO/IEC 18013-5 compliant encoding.

+

1.2 ISO/IEC 18013-5 compliant encoding

+

A data model for ISO/IEC 18013-5-encoded mDLs is fully specified in +ISO/IEC 18013-5. No changes need to be made to this data model for an +mDL attestation within the EUDI Wallet.

+

2 Trust infrastructure details

+

2.1 Introduction

+

To trust a signature over an mDL attestation, the RP needs a mechanism +to validate that the public key it uses to verify that signature is +trusted. ISO/IEC 18013-5 provides such mechanisms. However, additional +details need to be specified to fully specify these mechanisms for mDL +attestations within the EUDI Wallet ecosystem.

+

2.1.1 Trusted Issuer List

+

Section 5.3.2.2. of [ARF] describes the concept of a trusted list of +Issuers. This document specifies that for mDL attestations, such a +trusted list SHALL be used. Relying Parties SHALL only trust mDL issuers +that are included in a trusted list of mDL issuers. Additionally, there +SHALL be only a single trusted list of mDL issuers, which SHALL be +generated and maintained by a yet-to-be-determined party. This list +SHALL also contain the (root) certificate(s) of each mDL issuer. +Regarding the format of this trusted list, the format specified in Annex +C of ISO/IEC 18013-5 SHALL be used.

+

3 References

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[ARF]The Common Union Toolbox for a Coordinated Approach Towards a European Digital Identity Framework - The European Digital Identity Wallet Architecture and Reference Framework, January 2023, Version 1.0.0
[ISO]ISO/IEC 18013-5, Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application, First edition, 2021-09
[2015/1505]COMMISSION IMPLEMENTING DECISION (EU) 2015/1505
of 8 September 2015
laying down technical specifications and formats relating to trusted lists pursuant to Article 22(5) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market
[SD-JWT]Selective Disclosure for JWTs (SD-JWT)
draft-ietf-oauth-selective-disclosure-jwt-04, 11 April 2023 [1]
+
+
+
    +
  1. +

    The exact version to be referenced is to be determined. [ARF] +references v0.2. v0.4 is the latest version available at the time of +writing of this document. The level of interoperability between +these versions is not known. As [SD-JWT] is still under +development, presumably later versions will become available over +time. ↩

    +
    2. +
  2. +

    The exact version to be referenced is to be determined. [ARF] +references v0.2. v0.4 is the latest version available at the time of +writing of this document. The level of interoperability between +these versions is not known. As [SD-JWT] is still under +development, presumably later versions will become available over +time. ↩

    +
    3. +
+
+ + + + + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/1.3.0/annexes/annex-08-design-guide/index.html b/1.3.0/annexes/annex-08-design-guide/index.html new file mode 100644 index 0000000..c896835 --- /dev/null +++ b/1.3.0/annexes/annex-08-design-guide/index.html @@ -0,0 +1,1408 @@ + + + + + + + + + + + + + + + + + + + EUDI Wallet Design Guide - EUDI Wallet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + + + + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + +

EUDI Wallet Design Guide

+

for the EUDI Wallet ecosystem

+

November 2023 +v1.0.0

+

This is a working document that holds no legal value and does not +reflect any common agreement or position of the co-legislators. It +presents a state-of-play of ongoing work of the eIDAS Expert Group. This +document is being continuously updated and should not be considered +final.

+

1 List of Figures

+

Figure 1: Document Management example 6

+

Figure 2: Interactive Elements example 6

+

Figure 3: Document Presentation example 7

+

Figure 4: Labels example 8

+

Figure 5: Icons example 8

+

Figure 6: Undo & Redo example 9

+

Figure 7: Confirmation Dialogs example 10

+

Figure 8: Flexible Inputs example 10

+

Figure 9: iOS 3d touch example 11

+

Figure 10: Bookmarks example 12

+

Figure 11: Quick Proofs example 13

+

Figure 12: Error Messages examples 14

+

Figure 13: Layout 15

+

Figure 14: Target Sizes 16

+

2 Introduction

+

2.1 Purpose of the design guide

+

This design guide outlines the principles, guidelines, and best +practices for creating consistent and effective design solutions for the +EUDI wallet. The purpose of a design guide is to ensure that all design +work produced by a team or across different teams is consistent, +coherent, adheres to certain standards and aligns with the overall goals +and values of the project.

+

As many sections will be subject to national implementation this +document includes guidelines to assist in creating a user interface that +is useful, usable, and enjoyable to use. It also provides specific +instructions and tips for creating accessible and inclusive designs.

+

2.2 Boundaries of the design guide

+

It shall be highlighted that this design guide does not aim to provide +detailed design elements to be adopted by national EUDI Wallet +implementations. Overall, the objective of the EUDI Wallet Design Guide +is to:

+
    +
  • +

    Identify key design principles and provide guidelines against these + design principles;

    +
    • +
  • +

    Identify specific areas of the EUDI Wallet for which design + principles are considered important and expand on those in future + iterations of the EUDI Wallet Design Guide.

    +
    • +
+

The design guidelines listed in this document shall not be considered as +mandatory towards the implementations of the EUDI Wallet, but rather +stand as recommendations to ensure a common user experience across the +different national implementations.

+

2.3 Importance of design consistency

+

UI (User Interface) consistency is important because it provides a +better user experience and helps users navigate a mobile application +more easily. When elements such as icons, colours, and fonts are +consistent throughout an application, users can quickly learn how to use +it and understand the application's intention.

+

Familiarity:

+

Consistent UI elements give users a sense of familiarity and they can +feel more comfortable using the application. If the user interface +changes too often, it can cause confusion and frustration.

+

Efficiency:

+

Consistency in the user interface can make navigation easier and more +efficient. Users will know where to find the features they need, and +they reduce cognitive load.

+

Accessibility:

+

Consistent UI elements make it easier for users with disabilities to +navigate the application. Users with visual impairments, for example, +can more easily use screen readers when consistent UI elements are used.

+

Overall, UI consistency is an essential aspect of good user interface +design. It makes the application more user-friendly, efficient, and +accessible.

+

2.4 Overview of design criteria

+

Twelve design criteria have been selected which we go over in details in +'Section 2'. The first 10 are the usability heuristics from the Nielsen +Norman +group1. +They are called \"heuristics\" because they are broad rules of thumb and +not specific usability guidelines. These are used to evaluate a User +Interface, so it is good to have them as guiding principles during the +design phase as well. These 10 principles are:

+
    +
  • +

    Visibility of system status

    +
    • +
  • +

    Match between system and the real world

    +
    • +
  • +

    User control and freedom

    +
    • +
  • +

    Consistency and standards

    +
    • +
  • +

    Error prevention

    +
    • +
  • +

    Recognition rather than recall

    +
    • +
  • +

    Flexibility and efficiency of use

    +
    • +
  • +

    Aesthetic and minimalist design

    +
    • +
  • +

    Help users recognize, diagnose, and recover from errors

    +
    • +
  • +

    Help and documentation

    +
    • +
+

An additional 2 were added to address these important areas:

+
    +
  • +

    Accessibility

    +
    • +
  • +

    Writing

    +
    • +
+

3 Design criteria

+
+

Disclaimer: The design guidelines listed in this document shall not be +considered as mandatory towards the implementations of the EUDI Wallet, +but rather stand as recommendations to ensure a common user experience +across the different national implementations. Any design elements +included in the following chapter are indicative and are only used to +better illustrate the corresponding design criteria.

+
+

3.1 Visibility of system status

+
+

The design should always keep users informed about what is going on +through appropriate feedback within a reasonable amount of time

+
+

3.1.1 Indicative examples

+

Document management

+

When adding or removing a document the application should let the user +know whether the process was completed successfully of not.

+

Graphical user interface, application Description automatically +generated +Figure 1: Document Management example

+

Interactive elements

+

Interactive elements such as buttons must have a pressed and focused +state.

+

Text Description automatically generated with low +confidence +Figure 2: Interactive Elements example

+

3.2 Match between system and the real world

+
+

The design should speak the users\' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.

+
+

3.2.1 Indicative examples

+

Document representation

+

Documents should be (where possible) represented in the UI by what is +familiar to the user instead of generic / ambiguous icons.

+

A picture containing graphical user interface Description +automatically +generated +Figure 3: Document Presentation example

+

Labels

+

Stay away from technical terms and jargon. Use labels that people use in +their everyday life.

+

Screens screenshot of a cell phone Description automatically generated +with low +confidence +Figure 4: Labels example

+

Icons

+

People spend most of their time in other apps/websites. Use icons that +are familiar and clear to them instead on ambiguous ones.

+

A screenshot of a phone Description automatically generated with low +confidence +Figure 5: Icons example

+

3.3 User control and freedom

+
+
+

Users often perform actions by mistake. They need a clearly marked +\"emergency exit\" to leave the unwanted action without having to go +through an extended process.

+
+

3.3.1 Indicative examples

+

Undo & Redo

+

The third principle talks about giving the freedom to the user to +navigate and perform actions - for instance, the freedom to undo or redo +any accidental moves

+

A screenshot of a phone Description automatically generated with low +confidence +Figure 6: Undo & Redo example

+

3.4 Consistency and standards

+
+

Users should not have to wonder whether different words, situations, or +actions mean the same thing. Follow platform and industry conventions.

+
+

App should follow interface standards and platform conventions. +Conventions have been established that users are familiar with. This +knowledge should be capitalised upon to make the app have a higher level +of intuitiveness.

+

E.g. Position of menu, Navigation bar, Search location

+

3.5 Error prevention

+
+

Good error messages are important, but the best designs carefully +prevent problems from occurring in the first place. Either eliminate +error-prone conditions or check for them and present users with a +confirmation option before they commit to the action.

+
+

3.5.1 Indicative examples

+

Confirmation dialogs

+

For accidental actions such as miss-clicks

+

A screenshot of a phone Description automatically generated with +medium confidence +Figure 7: Confirmation Dialogs example

+

Flexible inputs

+

Flexible inputs allow people to answer questions the way they want +instead of the way a database requires them to. But these input fields +come with a promise to users: \"whatever format you choose, we\'ll take +it.\" For example, a phone number can be entered in various ways by +different people. The field can either format it accordingly on each own +or provide a hint of the expected format instead of producing in-line +errors or result in guesswork.

+

A screenshot of a phone number Description automatically +generated +Figure 8: Flexible Inputs example

+

3.6 Recognition rather than recall

+
+

Minimize the user\'s memory load by making elements, actions, and +options visible. The user should not have to remember information from +one part of the interface to another. Information required to use the +design (e.g. field labels or menu items) should be visible or easily +retrievable when needed.

+
+

3.7 Flexibility and efficiency of use

+
+

Offer shortcuts---quick ways to get one or more tasks done with your +apps. They should speed up the interaction with an app for the expert +user

+
+

3.7.1 Indicative examples

+

It's possible to improve the efficiency of interaction with an app for +experienced users with ways that will allow them to complete frequent +actions faster.

+

iOS 3d touch

+

Shortcuts for quick proofs through iOS 3d touch

+

+Figure 9: iOS 3d touch example

+

Bookmarked or Recently used documents on homepage

+

Users can customise their home screens with the documents most relevant +for them

+

A screenshot of a phone Description automatically generated with +medium +confidence +Figure 10: Bookmarks example

+

Quick proofs within the app

+

Quick proofs can give quick access to specific information serving both +convenience and privacy

+

Screens screenshot of a phone Description automatically generated with +medium +confidence +Figure 11: Quick Proofs example

+

3.8 Aesthetic and minimalist design

+
+

Interfaces should not contain information which is irrelevant or rarely +needed. Every extra unit of information in an interface competes with +the relevant units of information and diminishes their relative +visibility. Use whitespace in harmony with your content.

+
+

3.9 Help users recognize, diagnose, and recover from errors

+
+

Error messages should be expressed in plain language (no error codes), +precisely indicate the problem, and constructively suggest a solution.

+
+

3.9.1 Indicative examples

+

A screenshot of a computer error Description automatically generated +with low +confidence +Figure 12: Error Messages examples

+

3.10 Help and documentation

+
+

It\'s best if the system doesn\'t need any additional explanation. +However, it may be necessary to provide documentation to help users +understand how to complete their tasks.

+
+

3.10.1 Indicative examples

+

This can come in the form of App-onboarding, tutorials, F.A.Q.s or a +Help section.

+

3.11 Accessibility

+

An estimated 100 million people in the EU have some form of disability, +and so represent an important segment of its population and a large user +group.

+

With Europe's aging population this number is only going to rise. +Keeping this in mind, it is important to distinguish accessibility from +disabilities. Accessibility in this case, refers to making a website +accessible to users who due to their temporary or permanent condition, +their age, or their situation may face issues with accessing website +content. For example, individuals with reduced manual dexterity due to +injury or neurological conditions (permanent), or with an injured arm +(temporary), or a new parent holding a baby (situational) all experience +difficulties that may impede movement, coordination, or sensation or +what is most commonly referred to as motor disability. Therefore, it +concerns a much wider audience that one may initially think. The +definition of disability differs as the term disability refers to +'long-term physical, mental, intellectual or sensory impairments which +in interaction with various barriers may hinder a person's full and +effective participation in society on an equal basis with others. By +delivering the user experience in a way that is accessible to people +with the aforementioned needs, we are providing equal access to +information for all citizens regardless of their situation or condition.

+

3.11.1 Layout

+

Aim to have at least the main controls for the app at the bottom half of +the screen when they are easily reachable with the thumb when operating +the phone with one hand. The top half should be used for displaying +information, documents, QR codes etc.

+ + + + + + + + + + + + + +
A screen shot of a cell phone Description automatically generated with medium confidenceA screenshot of a blue screen Description automatically generated with low confidence
+

Figure 13: Layout

+

3.11.2 Target sizes

+

A target size is the area that can be activated in order to interact +with an element. Individuals with dexterity challenges may find it more +challenging to utilize a website if the target size is smaller. In this +section, we\'ll examine methods2 for generating target sizes that are +user-friendly, uniform, and properly spaced. A person\'s ability to +interact with smaller controls may be impacted by a disability or a +combination of disabilities that affect their motor movements and +dexterity, as well as by the act of using a website while on the move, +such as while walking or commuting.

+

Chart, waterfall chart Description automatically +generated

+

Figure 14: Target Sizes

+

3.11.3 Colour contrast guidelines

+

Text to background colour contrast should meet a 4.5:1 ratio.

+

How to check: enter the hex codes for the foreground and background +colours using

+

https://whocanuse.com/

+

3.11.4 Font size guidelines

+

The UI should be designed to support up to x2 the text size without +breaking.

+

3.11.5 Animations

+

Avoid adding flashing, blinking, and rotating animations on the +background. Excessive screen movement with no mechanism to control can +make it difficult for users to gather information.

+

Animations and transitions should be:

+
    +
  • +

    Informative (Motion design informs users by highlighting + relationships between elements, action availability, and action + outcomes.)

    +
    • +
  • +

    Focused (Motion focuses attention on what\'s important, without + creating unnecessary distraction.)

    +
    • +
  • +

    Expressive (Motion celebrates moments in user journeys, adds + character to common interactions, and can express a brand's style.)

    +
    • +
+

3.11.6 Screen readers

+

Make sure you provide the relative support for screen readers. Consider +how the reader is going to read the screen and place items accordingly +for convenience. In case of having to read through a lot of content to +get to the main controls, consider providing a skip button.

+

3.12 Writing

+

Text should be understandable by anyone, anywhere, regardless of their +culture or language. UI text can make interfaces more usable and build +trust. Text should be clear, accurate, and concise.

+

3.12.1 Write in the present tense.

+

Use the present tense to describe product behaviour. Avoid using the +future tense as this usually requires later updates.

+

Use the present tense to describe product behaviour. Avoid using the +future tense to describe the way a product always acts. When you need to +write in the past or future tenses, use simple verb forms. This may not +be applicable to all languages; the overall goal is to be as concise as +possible without compromising clarity.

+
+

Document added

+
+

Write in the present tense.

+
+

Document has been added

+
+

Don't write in different variations of the present tense, such as the +present perfect tense.

+

3.12.2 Begin with the objective.

+

When a phrase describes a goal and the action needed to achieve it, +start the sentence with the goal.

+
+

To add a document, click +

+
+

Start a statement with the objective ("to add a document") and end it +with the user action ("click +").

+
+

Click + to add a document

+
+

Don\'t state the action the user takes ("Click +") before the +objective ("to add a document").

+

3.12.3 Avoid combining first and second person.

+

To avoid confusing the user, avoid using \"me\" or \"my,\" and \"you\" +or \"your,\" in the same phrase.

+
+

Change your preferences in My Account

+
+

Don\'t refer to the user in both the second person and the first person +within the same phrase.

+
+

Change your preferences in Account

+
+

4 EUDI Wallet -- Design Considerations

+

This section lists specific areas/features on which design +considerations are deemed important to ensure a common user experience +across the national implementations of the EUDI Wallets. It shall be +noted that this list highlights specific areas which are prioritised as +important but does not aim to be an exhaustive list.

+

4.1 User authentication

+
    +
  • +

    Covering common user authentication aspects, e.g. PIN, biometrics + etc.

    +
    • +
  • +

    Exploring the balance between the corresponding security aspects + comparing to the user friction points throughout the entire user + flow (e.g. required only at the point of sharing data? Or at login + as well?)

    +
    • +
  • +

    Guidelines around 'user consent' in data sharing scenarios (e.g. + requesting user consent, enforcing trust)

    +
    • +
+

4.2 Browsing credentials/documents

+
    +
  • Guidelines in relation to displaying a list of + credentials/attestations in the EUDI Wallet
    • +
+

4.3 QR code presentation

+
    +
  • Guidelines in relation to presenting the QR code for the + corresponding proximity use cases
    • +
+

4.4 Confirmation/Summary/Authentication results

+
    +
  • +

    Guidelines in relation to the authentication results presentation, + i.e. successful/unsuccessful identification and authentication

    +
    • +
  • +

    Guidelines in relation to data transfer results for proximity + sharing use cases, i.e. successful/unsuccessful data transfer)

    +
    • +
  • +

    Covering guidelines related to the confirmation/summary results + presented to the user

    +
    • +
+

4.5 Error Messages

+
    +
  • +

    Handling/Display of error messages in different scenarios

    +
      +
    • +

      Erroneous user credentials

      +
      • +
    • +

      User is not authenticated.

      +
      • +
    • +

      Document is considered invalid.

      +
      • +
    • +

      Relying party is not considered trusted.

      +
      • +
    +
    • +
  • +

    Principles/guidelines on how these shall be presented/structured + etc.

    +
    • +
+

4.6 Privacy/Security by Design

+
    +
  • Covering applicability of privacy/security aspects in the data + sharing process (e.g. visual representation of 'password' field)
    • +
+

4.7 Trust Mark

+
    +
  • +

    Establish trust through the use of the EUDI Wallet Trust Mark

    +
    • +
  • +

    Applicability and placement in the corresponding sharing processes

    +
    • +
+

4.8 Notification guidelines

+
    +
  • Guidelines in relation to displaying user notifications (where + applicable) in the EUDI Wallet
    • +
+

5 Conclusion

+

In conclusion, this EUDI Wallet Design Guide document represents the +first iteration of what intends to be a \'living\' document, which will +be further elaborated for the specificities of the EUDI Wallet +functionalities, as listed in section 3 of the document. As such, it is +recognized that there may be areas for further elaboration and analysis +on which feedback and improvement suggestions from stakeholders is +anticipated.

+

Taking into consideration that the EUDI Wallet Design Guide shall be +applicable for the national implementations of the EUDI Wallet, the +boundaries of this document are set to common principles that shall be +applicable to all national implementations. These shall be considered as +recommendations to ensure a similar user experience across the different +national implementations. By taking a collaborative approach and +continuously improving upon this document, the aim is to create a EUDI +Wallet Design Guide that assists in the national implementations, while +at the same time meets the user expectations. We encourage stakeholders +to review this EUDI Wallet Design Guide document thoroughly and kindly +provide feedback that will assist if further shaping this design guide.

+
+
+
    +
  1. +

    NNGroup https://www.nngroup.com/articles/ten-usability-heuristics/ ↩

    +
    2. +
  2. +

    Methods examined: By Apple +https://developer.apple.com/design/human-interface-guidelines/layout +and Google +https://m3.material.io/foundations/layout/understanding-layout/overview +& +https://m3.material.io/foundations/accessible-design/accessibility-basics ↩

    +
    3. +
+
+ + + + + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/1.3.0/annexes/annex-08-eudi-wallet-design-guide.pdf b/1.3.0/annexes/annex-08-eudi-wallet-design-guide.pdf new file mode 100644 index 0000000..6ed30b2 Binary files /dev/null and b/1.3.0/annexes/annex-08-eudi-wallet-design-guide.pdf differ diff --git a/1.3.0/annexes/annex-09-design-guide-data-sharing-scenarios/index.html b/1.3.0/annexes/annex-09-design-guide-data-sharing-scenarios/index.html new file mode 100644 index 0000000..c02e63d --- /dev/null +++ b/1.3.0/annexes/annex-09-design-guide-data-sharing-scenarios/index.html @@ -0,0 +1,1045 @@ + + + + + + + + + + + + + + + + + + + EUDI Wallet Design Guide - Data Sharing Scenarios - EUDI Wallet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + + + + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + +

EUDI Wallet Design Guide - Data Sharing Scenarios

+

Version: 1.10

+

1 Situations for identification/authorization

+

In alignment with section '6.4' of the Architecture Reference Framework +(ARF), there are four main types of flows that the EUDI Wallet must +support. These main flows are as follows:

+
    +
  • +

    Remote same-device flow

    +
    • +
  • +

    Remote cross-device flow

    +
    • +
  • +

    Proximity supervised flow

    +
    • +
  • +

    Proximity unsupervised flow

    +
    • +
+

It shall be noted that remote supervised cases are also considered as +possible in some use cases, but the document focuses mainly on the types +of flows detailed in the ARF, as listed in the above list.

+

The 'EUDI Wallet Design Guide' aims to expand on the defined 'Service +Blueprints' (published in 'ARF v1.1.0' where the focus is on the 'remote +same-device' and 'proximity' flows. However, design interactions +applicable for the 'remote cross-device' flow will also be analysed at a +high-level.

+

A screenshot of a phone Description automatically generated with medium confidence

+

In relation to the remote flows, it shall be noted that the data exchange occurs over the Internet, but the key differentiator is related to the devices being utilized in the flows. In the 'remote same-device' flow, the EUDI Wallet User is on a mobile device, requesting access to a Relying Party's service (i.e. app or browser) and authorizes by using the EUDI Wallet app, which is also installed on the same device.

+

In contrast, in the 'remote cross-device' flow, the EUDI Wallet user +consumes information from a Relying Party service on another device than +the EUDI Wallet device, e.g. user visits the relying party's service on +their web browser on a PC and uses the EUDI Wallet app to scan a QR Code +on a login page in order to get access to a service provided by the +Relying Party.

+

A screenshot of a computer Description automatically generated with +low +confidence

+

In relation to the 'proximity' flows, both flows are related to +scenarios where the EUDI Wallet User is physically close to a Relying +Party, the user does not necessarily have internet connectivity and the +data presentation occurs using proximity protocols (NFC, Bluetooth, +QR-Code, etc.). The key differentiator in the two proximity flows, is +that in the supervised flow, the EUDI Wallet presents data (e.g. a +mobile driving license) to, or under the supervision of, a human acting +as a Relying Party (who may operate a device of their own). In the +unsupervised flow, the EUDI Wallet presents verifiable attributes to a +machine without human supervision.

+

A screenshot of a qr code Description automatically generated with +medium +confidence

+

2 Identifications

+

2.1 Identification Points

+

The following points are depicted as identification points within the +described user flows:

+
    +
  • +

    identification on application launch

    +
    • +
  • +

    identification when authorizing disclosure of data in proximity + flows (possibility to be disabled via corresponding settings) + (authorization process)

    +
    • +
  • +

    identification when presenting via deep link (authorization process)

    +
    • +
  • +

    identification after being idle

    +
    • +
+

2.2 Identification Methods

+

A set of 'authentication means' applicable for the EUDI Wallet are being +analysed in this Design Guide. These are:

+
    +
  • +

    PIN

    +
    • +
  • +

    Pattern

    +
    • +
  • +

    Biometrics

    +
    • +
  • +

    Password

    +
    • +
  • +

    OTP

    +
    • +
+

Screens screenshots of a login screen Description automatically +generated with medium +confidence

+

It shall be clarified that different levels of security shall be +required per use case, e.g. sharing a user's 'Person Identification +Data' is associated with 'High Level of Assurance', while showing a +'quick proof' that user is over 18 years of age may be associated with +simpler means of authentication.

+

Thus, it is expected that a combination of 'authentication means' are +available for the user to select and be used as per the needs of the +applicable use case. However, it shall be clarified that the available +authentication means are defined by the 'EUDI Wallet Provider' and the +'Device Manufacturer' and in principle shall adhere to the native way of +the operating system, e.g. password and biometrics.

+

It shall be noted that this section reflects a preliminary analysis +which is based on desk research and not on usability testing/field +research and it shall further be expanded and validated with detailed +research/user testing.

+

The analysed authentication means are being scored-in a scale of 0 to +10-against a set of design-related criteria, aiming to quantify the pros +and cons of each mean.

+

The criteria used for the rating are:

+
    +
  • +

    Convenience: The level of intuitiveness of each authentication + method

    +
    • +
  • +

    Experience: Overall user experience from a user perspective (i.e. + smooth experience)

    +
    • +
  • +

    Speed: Speed of use for the user's authentication process

    +
    • +
  • +

    Error Prevention: Assisting users to minimize potential errors in + the authentication process

    +
    • +
  • +

    Accessibility: Adherence to accessibility standards/specificities

    +
    • +
+

[[CHART]]{.chart}

+

Ratings have been based on a desk study and not actual first-hand +testing

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MethodProsCons
PIN• Short and easy authentication method • Slower unlocking compared to other authentication methods 
• Flexibility in PIN requirements• Requires users to memorize numbers 
• Recovery can be hard if you forget the PIN 
• Often predictable 
Pattern• Simple and intuitive to use• Many people choose simple, predictable patterns 
• Input method is visible to those around you 
• Belongs to a third party 
Password• More secure than a PIN • Easy to guess 
• Flexibility in password requirements• Slower unlocking 
• Password recovery can be as hard as a PIN recovery
Biometrics (fingerprint)• Fast and convenient authentication method • Fingerprints can be replicated. 
• Fingerprint distortion can cause failures. 
• Belongs to a third party 
Biometrics• Fast unlocking method • Light effects and facial changes can cause failures 
(face scan)• It doesn’t require memorizing codes and passwords.• Screen orientation and distance from the camera can impact readability 
+

3 Receiving & Configuring data request (by the user)

+

The EUDI Wallet should provide a secure and user-friendly environment by +empowering users with granular control over presenting their data, +ensuring transparency and clarity, and enabling user control and +consent.

+
    +
  • +

    Selective Disclosure: The EUDI Wallet should empower users to + have granular control over the information they present. The EUDI + Wallet should provide clear options for selective disclosure, + allowing users to choose between mandatory and optional information + to be presented, intending to emphasize on the data points which are + required to be shared by the user. It is recommended that optional + data shall be grouped in collapsed sections and be unselected by + default. On the other hand, it should be clearly depicted that + mandatory data cannot be unselected. The app should show users a + concise summary of the requested data, clearly indicating which + fields are mandatory and which are optional, as per each Member + State (MS) / Relying Party (RP) policy decision. This empowers users + to make informed decisions about what information they want to + disclose, ensuring their privacy preferences are respected, with the + risk of not completing a data request in a later step (more details + in section 5 Error Cases).

    +
    • +
  • +

    Transparency and Clarity: Transparency is key in ensuring that + users are always aware of what information is being presented. The + EUDI Wallet should include clear and concise explanations about the + purpose of each data request, the relying party\'s identity, and how + the data will be used, highlighting data storage and 'intent to + store' aspects to the user. Utilising plain language and avoiding + technical jargon can enhance understanding and minimise user + confusion.

    +
    • +
  • +

    User Control and Consent: To promote a sense of trust and + control, the EUDI Wallet should prioritise user consent throughout + the data-sharing process. The app should provide intuitive controls + to enable users to configure their preferences easily. Clear + notifications should be presented when changes are made, ensuring + users are always aware of their data-sharing settings and can adjust + them as needed.

    +
    • +
  • +

    Pre-authorisation: Pre-authorisation is a feature allowing the + user to give automatic consent for releasing certain attributes, + prior to any interaction. 'Pre-authorisation' as a concept may be + implemented in the form of one or multiple 'profiles'. For example, + if the user selects an 'age verification' profile, the EUDI Wallet + will always release the corresponding attribute (e.g. age_over_NN) + when requested by a Relying Party. However, if the user chooses to + set a 'law enforcement' profile, the EUDI Wallet will release all + attributes with a Relying Party, without giving the User the option + of withholding consent during the transaction.

    +
    • +
+

It shall be highlighted that the 'pre-authorisation' concept may +optionally be implemented, under the following conditions:

+
    +
  • +

    The pre-authorisation mechanism shall give the user the possibility + to select which attribute(s) the EUDI Wallet Instance must release + with which specific Relying Parties without asking for user consent + during the interaction. User consent shall never apply + indiscriminately to all Relying Parties or to all attributes.

    +
    • +
  • +

    A Relying Party for which pre-consent is given shall have been + authenticated by the EUDI Wallet at least once. This is a + consequence of the previous point as it is not possible to select a + Relying Party if that Relying Party is not unambiguously known to + the Wallet Instance. It shall be noted that this requirement holds + for both proximity use cases and remote use cases.

    +
    • +
  • +

    Giving pre-authorisation shall be a 'friction-full' process, meaning + that it shall not be too easy and requires a considered user + decision. Possibly, giving pre-authorisation should require an + additional user authentication step.

    +
    • +
  • +

    The EUDI Wallet shall be able to present to the user a clear + overview of all pre-authorisation given, with the ability to easily + change or withdraw one or more of these pre-authorisations. 

    +
    • +
  • +

    It shall be noted that pre-authorisations shall have a validity + limit or the user should be regularly prompted to review any set up + pre-authorisations.

    +
    • +
  • +

    If pre-authorisation applies for one or more requested attributes, + the EUDI Wallet shall release these attributes without first + notifying the user. However, immediately afterwards the EUDI Wallet + shall notify the User that one or more attributes were released on + the basis of pre-consent. That notification shall include an option + to withdraw the applicable user consent, but also highlight 'intent + to store' aspects to the user.

    +
    • +
  • +

    It shall be noted in the case where request also includes additional + optional data request, it would be proposed pre-authorisation would + prevail the potential request of optional data, since the concept of + pre-authorisation would be introduced to simplify the user flow. + However, further exploration and user research would be required for + such flows.

    +
    • +
  • +

    Solution providers shall duly consider the associated + security/privacy risks associated with the pre-authorisation feature + in conjunction with the specific conditions listed above.

    +
    • +
  • +

    Relying Party Trustworthiness: Trust in relying parties is + crucial for users to feel confident sharing their personal + information. The EUDI Wallet should incorporate clear information + and visual indicators or badges e.g. Trust Mark could be utilised to + indicate whether the Relying Party is considered trusted, based on + the underpinning trust framework established. Providing users with + this data helps them make informed decisions about which parties + they trust and are comfortable sharing their data with. Further + information must be provided upon clicking on the badge regarding + what it means to be a trusted party and how you become one.

    +
    • +
+

The EUDI Wallet aims to promote user confidence and foster a sense of +control and privacy, thereby enhancing the overall adoption and utility +of the app.

+

+

4 Authorization

+

4.1 Remote (Online) Authorization and Authentication

+

To enable authorization for data sharing during online processes, the +following methods can be employed:

+

4.1.1 Same Device

+
    +
  • Deep Link (Notification): When sharing data on the same device as + the wallet app, users can simply click on a deep link provided by + the third-party service, such as \"Log in via EUDI Wallet.\" This + action will instantly launch the EUDI Wallet app and present the + authorization screen.
    • +
+

4.1.2 Cross Device

+
    +
  • QR Code: When sharing data from a different device, users can scan a + QR code generated by the third-party service using their EUDI + Wallet. This will seamlessly open the app and display the + authorization screen.
    • +
+

4.2 Proximity-Based Authorization

+

To enable authorization for data sharing during offline processes, the +following methods can be employed:

+

4.2.1 Cross Device (Attended)

+
    +
  • +

    QR/Bluetooth: When presenting data to a Relying Party (attended + service), users can display a QR code on their EUDI Wallet to be + scanned by the Relying Party's reader device and transmit the + information via Bluetooth using their EUDI Wallet.

    +
    • +
  • +

    NFC/Bluetooth: Alternatively, users can use Near Field Communication + (NFC) to engage with the Relying Party's device and Bluetooth to + transmit the data to the Relying Party service through their EUDI + Wallet.

    +
    • +
+

4.2.2 Cross Device (Unattended)

+
    +
  • +

    QR/Bluetooth: When presenting data to a Relying Party (unattended + service), users can display a QR code and present the information + via Bluetooth through their EUDI Wallet.

    +
    • +
  • +

    NFC/Bluetooth: Similarly, users can utilize NFC and Bluetooth to + transmit the data to the Relying Party service through their EUDI + Wallet.

    +
    • +
+

During the authorization processes, a comprehensive screen will be +presented to the citizen which shall clearly display both mandatory and +optional data requested by the third-party service (as presented in +'section 3'). The citizens will have the freedom to choose which +optional information they wish to share, providing them with complete +control over their personal data. Additionally, a clear indication of +the data transfer outcome shall be presented to the users in all +scenarios described above, e.g. descriptive message regarding successful +data transfer.

+

5 Error cases

+

Handling/Display of error messages in different scenarios +(Principles/guidelines/consequences on how these shall be +presented/structured etc.)

+

5.1 Erroneous user credentials

+

When the user attempts to log in to the app, expects to receive feedback +indicating the success or failure of their login attempt.

+

A screenshot of a login screen Description automatically generated with medium confidence

+

The user gets an error message indicating that his credentials were wrong:\

+

5.2 Multiple failed attempts to login or present information

+

When the user is facing multiple failed attempts (e.g., 3) when trying +to log in, they get an error message as feedback from the app.

+

The error message typically indicates that the entered credentials are +incorrect or that there has been a problem with the identification +process. It can also guide the user in resolving the issue by reviewing +the credentials or checking for typos, etc., and prompts the user to try +again in 2 minutes or try to recover their password, hence the recovery +functionality may be presented as a fallback option for the user in case +his/her log-in attempts are not successful.

+

By limiting the number of login attempts, the app reduces the risk of +malicious factors attempting to gain unauthorized access by repeatedly +guessing passwords or usernames.

+

A screenshot of a login screen Description automatically generated with medium confidence

+

The user gets an error message indicating that they must try again later.

+

5.3 The document is considered invalid (expired/revoked)

+

When the user presents an invalid document through the app, (e.g., a +driver\'s license to a police officer) the app displays an error message +on the user's screen, indicating that the document could not be verified +because it is expired or revoked.

+

+

+

The user gets a message indicating the status of the document.

+

However, the user should be warned if a document they have saved within +the app is expired or revoked. The warning could be presented as a +notification or prompt within the app, indicating that a saved document +is approaching or has already passed its expiration date. The message +could include information on how to renew or update the document, +directing the user to the appropriate authorities, or providing relevant +instructions.

+

+

The user gets a message indicating that the document expires shortly.

+

By providing proactive reminders about expired documents, the app can +contribute to a smoother user experience, help users remain compliant +with regulations, and foster trust and confidence in the app\'s +functionality and user support.

+

5.4 The Relying party is not considered trusted. Is not verified or could not be verified (Maybe address safety)

+

When the user attempts to share information through the app with a third +party -a physical person or a digital service- and it turns out that the +third party is not valid or is a fraud, they must get an alert warning +message.

+

+

The user gets a message indicating that they must not share information with that party. The options are to report it, to close the app, or to search for information about security.

+

5.5 The user fails to present requested document

+

When a user scans their QR code using a QR code scanning device, they +receive a prompt to provide additional documents, such as an ID. If the +required document is not present in the user\'s app, an error message is +displayed, notifying the user that the document is not stored in their +app.

+

+

The error message then suggests adding the document from the available documents list.

+ + + + + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/1.3.0/annexes/annex-09-eudi-wallet-design-guide-data-sharing-scenarios.pdf b/1.3.0/annexes/annex-09-eudi-wallet-design-guide-data-sharing-scenarios.pdf new file mode 100644 index 0000000..d82202f Binary files /dev/null and b/1.3.0/annexes/annex-09-eudi-wallet-design-guide-data-sharing-scenarios.pdf differ diff --git a/1.3.0/annexes/assets/annex-08/media/image1.png b/1.3.0/annexes/assets/annex-08/media/image1.png new file mode 100644 index 0000000..8f1715a Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image1.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image10.png b/1.3.0/annexes/assets/annex-08/media/image10.png new file mode 100644 index 0000000..4513312 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image10.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image11.png b/1.3.0/annexes/assets/annex-08/media/image11.png new file mode 100644 index 0000000..fd06892 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image11.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image12.png b/1.3.0/annexes/assets/annex-08/media/image12.png new file mode 100644 index 0000000..0d7f89d Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image12.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image13.png b/1.3.0/annexes/assets/annex-08/media/image13.png new file mode 100644 index 0000000..a4b70ae Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image13.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image14.png b/1.3.0/annexes/assets/annex-08/media/image14.png new file mode 100644 index 0000000..32ccfbe Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image14.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image15.png b/1.3.0/annexes/assets/annex-08/media/image15.png new file mode 100644 index 0000000..edc4c6a Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image15.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image16.png b/1.3.0/annexes/assets/annex-08/media/image16.png new file mode 100644 index 0000000..a0b7f90 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image16.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image17.png b/1.3.0/annexes/assets/annex-08/media/image17.png new file mode 100644 index 0000000..9a6ac17 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image17.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image18.png b/1.3.0/annexes/assets/annex-08/media/image18.png new file mode 100644 index 0000000..da27fe4 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image18.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image2.png b/1.3.0/annexes/assets/annex-08/media/image2.png new file mode 100644 index 0000000..496370c Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image2.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image3.png b/1.3.0/annexes/assets/annex-08/media/image3.png new file mode 100644 index 0000000..6b840d7 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image3.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image4.png b/1.3.0/annexes/assets/annex-08/media/image4.png new file mode 100644 index 0000000..ae16afd Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image4.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image5.png b/1.3.0/annexes/assets/annex-08/media/image5.png new file mode 100644 index 0000000..b71e1e5 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image5.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image6.png b/1.3.0/annexes/assets/annex-08/media/image6.png new file mode 100644 index 0000000..f927ae8 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image6.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image7.png b/1.3.0/annexes/assets/annex-08/media/image7.png new file mode 100644 index 0000000..e2763f9 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image7.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image8.png b/1.3.0/annexes/assets/annex-08/media/image8.png new file mode 100644 index 0000000..2a0f448 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image8.png differ diff --git a/1.3.0/annexes/assets/annex-08/media/image9.png b/1.3.0/annexes/assets/annex-08/media/image9.png new file mode 100644 index 0000000..27b4086 Binary files /dev/null and b/1.3.0/annexes/assets/annex-08/media/image9.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image1.png b/1.3.0/annexes/assets/annex-09/media/image1.png new file mode 100644 index 0000000..2661402 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image1.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image10.png b/1.3.0/annexes/assets/annex-09/media/image10.png new file mode 100644 index 0000000..f5ef8d5 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image10.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image11.png b/1.3.0/annexes/assets/annex-09/media/image11.png new file mode 100644 index 0000000..941f652 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image11.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image12.png b/1.3.0/annexes/assets/annex-09/media/image12.png new file mode 100644 index 0000000..635b79f Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image12.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image2.png b/1.3.0/annexes/assets/annex-09/media/image2.png new file mode 100644 index 0000000..405e7d6 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image2.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image3.png b/1.3.0/annexes/assets/annex-09/media/image3.png new file mode 100644 index 0000000..bd8ce74 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image3.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image4.png b/1.3.0/annexes/assets/annex-09/media/image4.png new file mode 100644 index 0000000..8e401d0 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image4.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image5.png b/1.3.0/annexes/assets/annex-09/media/image5.png new file mode 100644 index 0000000..fab24d7 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image5.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image6.png b/1.3.0/annexes/assets/annex-09/media/image6.png new file mode 100644 index 0000000..0c97cf4 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image6.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image7.png b/1.3.0/annexes/assets/annex-09/media/image7.png new file mode 100644 index 0000000..e92fb33 Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image7.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image8.png b/1.3.0/annexes/assets/annex-09/media/image8.png new file mode 100644 index 0000000..6ee0c0e Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image8.png differ diff --git a/1.3.0/annexes/assets/annex-09/media/image9.png b/1.3.0/annexes/assets/annex-09/media/image9.png new file mode 100644 index 0000000..362825a Binary files /dev/null and b/1.3.0/annexes/assets/annex-09/media/image9.png differ diff --git a/1.3.0/arf/index.html b/1.3.0/arf/index.html new file mode 100644 index 0000000..a7c782c --- /dev/null +++ b/1.3.0/arf/index.html @@ -0,0 +1,5965 @@ + + + + + + + + + + + + + + + + + + + + + Architecture and reference framework - EUDI Wallet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + + + + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + +

Architecture and Reference Framework

+

February 2024
+Version 1.3.0

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionDate1Changes
1.0.026 January 2023Initial version
1.1.020 April 2023Addition of services blueprints for use cases on:
  • Identification & authentication to access online services
  • Mobile driving licence
1.2.022 June 2023
  • New Chapter 5 describing the EUDI Wallet ecosystem trust model
  • Annex 06 describing the first iteration of PID Rule Book
  • Annex 07 describing the first iteration of the mDL Rule Book
1.3.015 December 2023
  • Updated Chapter 5 EUDI data model
  • Updated Chapter 6 Trust model
  • Updated Chapter 7 Specifications for Wallet Solutions
  • Added Annex 8 EUDI Wallet Design Guide
  • Added Annex 9 Design guide data sharing scenarios
+

1 Introduction

+

1.1 Context

+

On 3 June 2021, the European Commission adopted a Recommendation2 +calling on Member States to work towards the development of a Toolbox +including a technical Architecture and Reference Framework (hereinafter +the ARF), a set of common standards and technical specifications and a +set of common guidelines and best practices.

+

The Recommendation specifies that these outcomes will serve as a basis +for the implementation of the proposal for a European Digital Identity +Framework3, without the process of developing the Toolbox interfering +with, or prejudging the legislative process.

+

The Recommendation foresees that the Toolbox is developed by Member +States' experts in the eIDAS Expert Group4 in close coordination with +the Commission and, where relevant for the functioning of the European +Digital Identity (EUDI) Wallet infrastructure, other concerned public +and private sector parties.

+

Following the indicative timeline set out in the Recommendation, a +process and working procedures were agreed on 30 September 2021 and +discussed in a non-paper on a high-level description of the EUDI Wallet +ecosystem, proposed by the Commission.

+

On this basis, an outline was defined providing a more detailed +description of the EUDI Wallet concept, its functionalities and security +aspects and on several core, use cases between October and December +2021. That work resulted in the Outline of the ARF, adopted by the eIDAS +Expert Group in February 2022. The Outline was published on Futurium5 +for public feedback. When the feedback period closed on 15 April 2022, +36 stakeholders had provided their feedback on the Outline.

+

The eIDAS Expert Group has since further developed the concepts and +specifications for the European Digital Identity Framework based on the +Commission's legislative proposal6, and will continue to do so until +the legislative negotiations have been concluded and implementing acts +have been adopted.

+

The eIDAS Expert Group adopted the present document on 26 January 2023.

+

1.2 Purpose of This Document

+

The purpose of the document is to provide all the specifications needed +to develop an interoperable EUDI Wallet Solution based on common +standards and practices. The document presents a state-of-play of +ongoing work of the eIDAS Expert Group and does not imply any formal +agreement regarding its content or the legislative proposal. This +document will be complemented and updated over time through the process +of establishing the toolbox, as described in Chapter 9. Once completed +the document will describe a comprehensive Architecture and Reference +Framework covering all the specifications needed to implement a +European Digital Identity Wallet Solution.

+

While Chapters 2-5 and 8-10 are descriptive, Chapters 6 and 7 specify +requirements for PID Providers, (Q)EAA Providers, EUDI Wallet Solution +Providers, Relying Parties and other parties in the EUDI Wallet +ecosystem. The capitalised imperatives in the document are used in +accordance with RFC 2119.

+

This document itself holds no legal value and SHALL not prejudge the +forthcoming legislative process and the final mandatory legal +requirements for European Digital Identity Wallets. This document +will be aligned to the outcome of the legislative negotiations of the +proposal for a European Digital Identity Framework. Only the finally +adopted European Digital Identity Framework Regulation, and the +implementing and delegated acts adopted under that legal basis, +will be mandatory.

+

1.3 Use of This Document

+

This document is mainly meant to be used by the European Commission +developing a reference implementation of an EUDI Wallet and the +consortia piloting the use of the reference implementation in the +context of Pilots. Experience of implementing this specification +may lead to improvements of this document, in accordance with +Chapter 9.

+

1.3.1 The Reference Implementation of an EUDI Wallet

+

The Commission will provide a reference implementation of an EUDI Wallet +in a mobile form factor. The source code for the EUDI Wallet reference +implementation will be provided as open source for re-use by +implementers across Europe. The first implementers will be the projects +selected to carry out Large Scale Pilots (LSPs), following a call for +proposals. The LSP projects will be engaged in the further development +of the reference implementation of an EUDI Wallet. The Commission will +also initially supply central services as needed for the functioning of +the EUDI Wallet reference implementation.

+

The Commission intends to use the ARF to develop the EUDI Wallet +reference implementation.

+

1.3.2 Guidance for the Large-Scale Pilots (LSP)

+

To support the development of a reference implementation of an EUDI +Wallet and to pilot its usage across different priority use cases, the +Commission launched a call for proposals on 22nd February 2022 under the +Digital Europe Programme to pilot large-scale use cases for the EUDI +Wallet.

+

The objective of the Large Scale Pilots (LSP) call is to co-fund the +piloting of the EUDI Wallet based on a reference implementation of an +EUDI Wallet, taking into account project specificities, existing +national notified eID and wallet developments and implementation +situations, around the different cross-border use cases involving both +public and private stakeholders.

+

The ARF will be used by the LSPs to inform and guide pilot system design +and architecture development together with the release of the reference +implementation.

+

The LSPs are expected to provide feedback on the ARF as they develop and +interact with Relying Party services, Qualified or non-qualified +Electronic Attestations of Attributes (Q)EAA Providers, Person +Identification Data (PID) Providers and Users in meaningful transactions +under the proposed use cases.

+

2 Definitions

+

In addition to Article 3 of the proposed amendment to the legal text, +the following definitions are provided to either highlight those most +relevant to the Architecture and Reference Framework or to introduce +additional terms not defined in the legal text (denoted with a *).

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TermDescription
AttestationA signed set of attributes, in either the mdoc format specified in [ISO18013-5] or the SD-JWT format specified in [SD-JWT]. This may be a PID, QEAA or EAA.
AttributeA feature, characteristic or quality of a natural or legal +person or of an entity, in electronic form. - eIDAS Regulation +amendment proposal
Authentic SourceA repository or system, held under the responsibility of a +public sector body or private entity, that contains attributes about a +natural or legal person and is considered to be the primary source of +that information or recognised as authentic in national law. – eIDAS +Regulation amendment proposal
Electronic Attestation of Attributes (EAAs)An attestation in electronic form that allows the +authentication of attributes - eIDAS Regulation amendment +proposal
National Accreditation Bodies (NAB)*A body that performs accreditation with authority +derived from a Member State under Regulation (EC) No 765/2008. +
Person Identification Data (PID)A set of data enabling the identity of a natural or legal +person, or a natural person representing a legal person to be +established - eIDAS Regulation.
Person Identification Data Provider*A Member State or other legal entity providing Person +Identification Data to Users.
Public Key Infrastructure (PKI)*Systems, software, and communication protocols that are used by EUDI Wallet ecosystem components to distribute, manage, and control public keys. A PKI publishes public keys and establishes trust within an environment by validating and verifying the public keys mapping to an entity.
Qualified Electronic Attestations of Attributes (QEAA)

An Electronic Attestation of Attributes, which is issued +by a Qualified Trust Service Provider and meets the requirements laid +down in Annex V. - eIDAS Regulation amendment +proposal

Qualified Electronic Attestations of Attributes (QEAA) provider*

(Qualified) Trust Service Provider issuing (Q)EAA. Note: there may be multiple (Q)EAA Providers.

Qualified Electronic Signature Creation Device (QSCD)Software or hardware used to create an electronic +signature that meets the requirements laid down in Annex II of the eIDAS +Regulation amendment proposal. -eIDAS Regulation and eIDAS +Regulation amendment proposal
Qualified Trust Service Provider (QTSP)A Trust Service Provider who provides one or more Qualified +Trust Services and is granted the qualified status by the supervisory +body. - eIDAS Regulation
Relying Party*

A natural or legal person that relies upon an electronic +identification or a Trust Service. – eIDAS +Regulation

+

In the case of the EUDI Wallet, the Relying Party relies on +electronic identification or the Trust Service originating from an EUDI +Wallet.

Selective Disclosure*The capability of the EUDI Wallet that enables the User to +present a subset of attributes provided by the PID and/or +(Q)EAAs.
Trust*Trust is the characteristic that one party, is willing to +rely upon a third-party entity to execute a set of actions and/or to +make a set of assertions about a set of subjects and/or +scopes[^7].
Trust Framework*A legally enforceable set of operational and technical rules +and agreements that govern a multi-party system designed for conducting +specific types of transactions among a community of participants and +bound by a common set of requirements.
Trust model*Collection of rules that ensure the legitimacy of the +components and the entities involved in the EUDI Wallet +ecosystem.
Trust Service Provider (TSP)A natural or a legal person who provides one or more Trust +Services, either as a qualified or as a non-qualified Trust Service +Provider. - eIDAS Regulation
Trust Service

An electronic service normally provided against payment +which consists of:

+

(a) the creation, verification, and validation of electronic +signatures, electronic seals or electronic time stamps, electronic +registered delivery services, electronic attestation of attributes and +certificates related to those services;

+

(b) the creation, verification and validation of certificates +for website authentication;

+

(c) the preservation of electronic signatures, seals or +certificates related to those services;

+

(d) the electronic archiving of electronic +documents;

+

(e) the management of remote electronic signature and seal +creation devices;

+

(f) the recording of electronic data into an electronic +ledger. - eIDAS Regulation amendment proposal

Trusted List*Repository of information about authoritative entities in a +particular legal or contractual context which provides information about +their current and historical status.
User*A natural or legal person using an EUDI +Wallet.
EUDI Wallet Instance*Instance of an EUDI Wallet Solution belonging to and which +is controlled by a User.
Relying Party Instance*A software module with the capability to interact with a Wallet Instance and to perform Relying Party authentication, that is controlled by a Relying Party.
EUDI Wallet Provider*A public or private organisation, responsible for the operation of an eIDAS-compliant EUDI Wallet Solution that can be instantiated on a User's device, e.g., through installation and initialization.
EUDI Wallet Solution*An EUDI Wallet Solution is the entire product and service provided by an EUDI Wallet Provider, and offered to all Users of that Solution.
Wallet Secure Cryptographic Application (WSCA)*A Wallet Secure Cryptographic Application (WSCA) is software provisioned within the Wallet Secure Cryptographic Device (WSCD). It is tasked with executing all security-sensitive operations such as generating, safeguarding, and handling cryptographic keys and assets. Additionally, it facilitates communication with the Wallet Instance.
Wallet Secure Cryptographic Device (WSCD)*Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. Examples include Secure Elements (SE), Trusted Execution Environments (TEEs), and (remote or local) Hardware Security Module (HSM).
+ +

Table 1: Definitions

+

* Additional to definitions in Article 3 of the eIDAS Regulation or +its amendment proposal.

+

3 Use cases for the EUDI Wallet

+

The development of EUDI Wallet specifications is steered by use cases +that facilitate understanding of user experience while capturing the +value proposition and business requirements of the EUDI Wallet. To +accomplish this, the eIDAS Expert Group begins by creating service +blueprints for each EUDI Wallet use case. These blueprints are visual +representations of the various components and processes involved in +providing a service to users and serve as a tool for pinpointing +potential areas for enhancement, optimising user experience, and +streamlining service delivery. These blueprints then act as the basis +for establishing use case rulebooks and common specifications for all +use cases.

+

The service blueprints of the use case can be found in the annexes as +attached documents. It is important to note that the service blueprint +documents offer a viable solution for each use case, but alternatives +and optional steps do exist. For instance, displaying stored data which +the user has already approved to release might be optional. Furthermore, +user journeys may differ depending on the chosen implementation approach, +such as asynchronous attribute storage or synchronous retrieval. This +could affect aspects like providing approval to retrieve and release data.

+

The eIDAS Expert Group has described service blueprints for the following use cases: +* Identification and authentication to access online services, see section 3.13.1, +* Mobile Driving Licence, see section 3.2, +* A number of other use cases that will be detailed in subsequent versions of this document, see section 3.3.

+

3.1 Identification and authentication to access online services

+

The primary purpose of the EUDI Wallet is to offer secure identification +and authentication of users at a high Level of Assurance (LoA) for both +public and private online services. This essential functionality ensures +that Relying Parties can confidently verify that they are interacting +with the correct User.

+

In this use case, the User is utilising the EUDI Wallet Instance to +confirm their identity. They access online services that demand +authentication and currently employ multiple methods for identity +verification while accessing these services. The User is also concerned +about sharing person identification data (PID) during online +interactions. Their objectives include identifying themselves with +services requiring user identification and maintaining control over +personal data sharing.

+

This use case encompasses the entire EUDI Wallet life cycle from the +User's viewpoint, from obtaining a valid Wallet Instance to identifying and +authenticating the User within an online service. The focus of the +current description is a workable remote same-device flow (refer to +section 7.4), where a natural person User employs a single mobile device +for both securing the session and accessing the service's information.

+

PID issuance requirements, PID attribute schema and Trust Infrastructure +details are further detailed in Chapter 6 and Annex A.6.

+

3.2 Mobile Driving Licence

+

A significant use case for the EUDI Wallet involves allowing Users to +acquire, store, and display a mobile Driving Licence (mDL) as an +attestation to prove their driving privileges. In this use case, the +User employs an EUDI Wallet to present a mDL to a Relying Party +(e.g., the Traffic Police)8.

+

The use case description concentrates on proximity supervised and +unsupervised flows, which involve scenarios where the User is physically +near a Relying Party, and the mDL attribute exchange and disclosure +occurs using proximity technologies (e.g. NFC, Bluetooth). The two +proximity flows have one significant difference: in the supervised flow, +the EUDI Wallet presents mDL attributes to a human Relying Party or +under their supervision (who may also use a device); whereas in the +unsupervised flow, the EUDI Wallet presents mDL attributes to a machine +without human oversight.

+

(Q)EAA issuance requirements, mDL attribute schema and Trust +Infrastructure details are further detailed in Chapter 6 and Annex A.7.

+

3.3 Other use cases

+

In subsequent versions of this document, the following use cases will be +detailed as service blueprints:

+

Health

+

Easy access to health data is crucial in both national and cross-border +contexts. An EUDI Wallet Instance MAY enable access to patient summary, +ePrescriptions, etc.

+

Educational credentials and professional qualifications

+

Providing documents for qualification recognition procedures can be +costly and time-consuming for end Users, Relying Parties such as companies +and employers, and (Q)EAA providers such as education and training +providers or other academic institutions. For example, digital diploma +attestations could be presented cross-border in a verifiable, trusted, +and consumable format to another education or training institution or a +prospective employer. An EUDI Wallet Instance may be a repository for +educational digital credentials as Electronic Attestations of Attributes +and a means for exchanging them by a learner.

+

Digital Finance

+

The EUDI Wallet Solutions SHALL facilitate complying with strong customer +authentication requirements. In line with the Commission's Retail +Payments Strategy9, the use case would be developed in close +coordination with Member States' advisory groups on retail payments +and the finance industry.

+

Digital Travel Credential

+

EUDI Wallet can store Digital Travel Credentials enabling Users to +benefit from more seamless travel.

+

This work may in future be extended to additional use cases.

+

4 European Digital Identity Wallet Ecosystem

+

This Chapter describes the EUDI Wallet ecosystem as it is foreseen in +the Commission's legislative proposal.

+

4.1 Roles in the Ecosystem

+

The roles of the EUDI Wallet ecosystem are described in Figure 1 and +detailed in the following sections.

+

Figure 1: Overview of the EUDI Wallet roles

+ + +

Figure 1: Overview of the EUDI Wallet roles

+
    +
  1. +

    Users of EUDI Wallets

    +
    2. +
  2. +

    EUDI Wallet Providers

    +
    3. +
  3. +

    Person Identification Data Providers

    +
    4. +
  4. +

    Trusted Lists providers

    +
    5. +
  5. +

    Qualified Electronic Attestation of Attributes (QEAA) Providers

    +
    6. +
  6. +

    Non-qualified Electronic Attestation of Attributes (EAA) Providers

    +
    7. +
  7. +

    Qualified and non-qualified certificate for electronic + signature/seal Providers

    +
    8. +
  8. +

    Authentic Sources

    +
    9. +
  9. +

    Relying Parties

    +
    10. +
  10. +

    Conformity Assessment Bodies (CAB)

    +
    11. +
  11. +

    Supervisory bodies

    +
    12. +
  12. +

    Device manufacturers and related subsystems providers

    +
    13. +
  13. +

    (Q)EAA Schema Providers

    +
    14. +
  14. +

    National Accreditation Bodies

    +
    15. +
+

4.1.1 Users of EUDI Wallets

+

Users of EUDI Wallets use the EUDI Wallet instance to receive, store and +present PID, QEAA or EAA about themselves, including to prove their +identity. Users can create Qualified Electronic Signatures and Seals +(QES) using an EUDI Wallet instance.

+

Who can be a User of an EUDI Wallet depends on national law. The use of +an EUDI Wallet by citizens is not mandatory under the legislative +proposal. However, each Member State SHALL provide at least one European +Digital Identity Wallet within 24 months after the entry into force of +the implementing acts referred to in the Regulation.

+

4.1.2 EUDI Wallet Providers

+

EUDI Wallet Providers are Member States or organisations either mandated +or recognized by Member States making the EUDI Wallet available for end +Users. The terms and conditions of the mandate or recognition are for +each Member State to determine.

+

The EUDI Wallet Providers make available to a User, through an instance +of their EUDI Wallet Solution, a combination of several products and +Trust Services foreseen in the legal proposal, which give the User full +control over the use of their Person Identification Data (PID) and +Qualified or non-qualified Electronic Attestations of Attributes (QEAA or +EAA), and any other personal data within their EUDI Wallet. From a +technical viewpoint, this may also imply guaranteeing a User sole +control over sensitive cryptographic material (e.g., private keys) +related to their PID and/or (Q)EAA, including in use cases for electronic +identification and creating a signature or seal.

+

EUDI Wallet Providers are responsible for ensuring compliance with the +requirements for EUDI Wallets.

+

4.1.3 Person Identification Data (PID) Providers

+

PID Providers are trusted entities responsible to:

+
    +
  • verify the identity of the EUDI Wallet User in compliance with LoA + High requirements,
    • +
  • issue PID to the EUDI Wallet in a harmonised common format and
    • +
  • make available information10 for Relying Parties to verify the + validity of the PID.
    • +
+

The terms and conditions of these services are for each Member State to +determine.

+

PID Providers MAY e.g., be the same organisations that today issue +official identity documents, electronic identity means, EUDI Wallet +Providers etc. EUDI Wallet Providers MAY be the same organisations as PID +Providers. In case an organisation acts as both a PID Provider and a +Wallet Provider, it SHALL comply with all requirements for both PID +Providers and Wallet Providers.

+

4.1.4 Trusted List Providers

+

The specific status of a role in the EUDI Wallet ecosystem SHALL be +verified in a trustworthy manner. Such roles are:

+
    +
  • EUDI Wallet Providers
    • +
  • Person Identification Data Providers
    • +
  • Qualified Electronic Attestation of Attributes (QEAA) providers
    • +
  • Qualified certificate for electronic signature/seal (QC) providers
    • +
  • Relying Parties
    • +
  • Non-qualified Electronic Attestation of Attributes (EAA) providers
    • +
  • Non-qualified certificate for electronic signature/seal providers
    • +
  • Providers of other Trust Services
    • +
  • Catalogues of attributes and schemes for the attestations of attribute + providers
    • +
+

Other roles may be necessary and thus need to be defined and explicitly +mentioned depending on the specific role and their criticality for +example the different roles and actors involved with remote signing +processes.

+

When used, Trusted List11 need to provide a registration service for +the relevant entities, maintain a registry and enable third party access +to the registry information. The terms and conditions of entities to +become registered are for each registrar to determine unless specified +in e.g., sectoral rules.

+

4.1.5 Qualified Electronic Attestation of Attributes Providers

+

Qualified EAA are provided by QTSPs. The general Trust Framework for +QTSPs apply also to QEAA, but specific rules for this Trust Service need +to be defined as well. QEAA Providers maintain an interface for +requesting and providing QEAAs, including a mutual authentication +interface with EUDI Wallets and potentially an interface towards +Authentic Sources to verify attributes. QEAA Providers provide +information or the location of the services that can be used to enquire +about the validity status of the QEAAs, without having an ability to +receive any information about the use of the attestations. The terms and +conditions of these services are for each QTSP to determine, beyond what +is specified in the eIDAS Regulation.

+

4.1.6 Non-Qualified Electronic Attestation of Attributes Providers

+

Non-qualified EAA can be provided by any Trust Service Provider. While +they are supervised under eIDAS, it can be assumed that other legal or +contractual frameworks than eIDAS mostly govern the rules for provision, +use and recognition of EAA. Such other frameworks may cover policy areas +such as driving licences, educational credentials, digital payments, +although they may also rely on qualified Electronic Attestation of +Attributes Providers. For EAA to be used, TSPs offer Users a way to +request and obtain EAA, meaning they need to technically comply with EUDI +Wallet interface specifications. Depending on the domain rules, EAA +providers may provide validity information about EAA, without having an +ability to receive any information about the use of the EAA. The terms +and conditions of issuing EAAs and related services are subject to +sectoral rules.

+

4.1.7 Qualified and Non-Qualified Certificates for Electronic Signature/Seal Providers

+

Article 6a(3) of COM(2021)281 final requires the EUDI Wallet to enable +the User to create qualified electronic signatures or seals. This goal +can be reached by several ways:

+
    +
  • +

    The EUDI Wallet is certified as a qualified signature/seal creation + device (QSCD), or

    +
    • +
  • +

    It implements secure authentication and signature/seal invocation + capabilities as a part of a local QSCD or a remote QSCD managed by a + QTSP.

    +
    • +
+

EUDI Wallet interfaces with QSCDs will be further expanded in future +versions of this document.

+

4.1.8 Providers of other Trust Services

+

EUDI Wallet interaction with providers of other qualified or +non-qualified Trust Services such as timestamps may be further described +in future versions of the ARF.

+

4.1.9 Authentic Sources

+

Authentic Sources are the public or private repositories or systems +recognised or required by law containing attributes about a natural or +legal persons. The Authentic Sources in scope of Annex VI of the +legislative proposal are sources for, for instance, attributes on +address, age, gender, civil status, family composition, nationality, +education and training qualifications titles and licences, professional +qualifications titles and licences, public permits and licences, +financial and company data. Authentic Sources in scope of Annex VI are +required to provide interfaces to (Q)EAA Providers to verify the +authenticity of the above attributes, either directly or via designated +intermediaries recognised at national level. Authentic Sources MAY also +issue (Q)EAAs themselves if they meet the requirements of the eIDAS +Regulation.

+

It is up to the Member States to define terms and conditions for the +provisioning of these attestations, but according to the minimum +technical specifications, standards, and procedures applicable to the +verification procedures for qualified electronic attestations of +attributes.

+

4.1.10 Relying Parties

+

Relying Parties are natural or legal persons that rely upon an +electronic identification or a Trust Service. In the context of EUDI +Wallets, they request the necessary attributes contained within the PID +dataset, QEAA and EAA from EUDI Wallet Users to rely on the EUDI Wallet, +subject to the acceptance by the owner of the Wallet (User) and within +the limits of applicable legislation and rules. The reason for reliance +on the EUDI Wallet may be a legal requirement, a contractual agreement, +or their own decision. To rely on the EUDI Wallet, Relying Parties need +to inform the Member State where they are established and their +intention for doing so. Relying Parties need to maintain an interface +with the EUDI Wallet to request attestations with mutual authentication. +Relying Parties are responsible for authenticating PID and (Q)EAA.

+

4.1.11 Conformity Assessment Bodies (CAB)

+

The EUDI Wallets SHALL be certified by accredited public or private +bodies designated by Member States12. QTSPs SHALL be audited regularly +by Conformity Assessment Bodies (CABs). CABs are accredited by a national +accreditation body according to Regulation 765/2008 as responsible for +carrying out assessments on which Member States will have to rely before +issuing a EUDI Wallet or providing the qualified status to a Trust +Service Provider. The standards and schemes used by CABs to fulfil their +tasks to certify EUDI Wallets are specified further in the Toolbox +process.

+

4.1.12 Supervisory Bodies

+

The supervisory bodies are notified to the Commission by the Member +States, which supervise QTSPs and act, if necessary, in relation to +non-qualified Trust Service Providers.

+ +

EUDI Wallets will have several interfaces with the devices they are +based on, which may be for the following purposes:

+
    +
  • Local storage.
    • +
  • Online Internet access.
    • +
  • Sensors such as smartphone cameras, IR sensors, microphones, etc.
    • +
  • Proximity communication channels such as Bluetooth Low Energy (BLE), + Wi-Fi Aware, Near Field Communication (NFC).
    • +
  • User interfaces such as screen, flashlights, speakers etc.
    • +
  • Smart cards and secure elements for generating, storing and using + private keys and other sensitive cryptographic material.
    • +
+

For secure cryptographic material storage, specific devices or services +may be interfaced with. Other related entities may be service providers +such as cloud service providers, app store providers etc.

+

The legal proposal sets constraints (e.g., compliance with LoA High) for +which kinds of devices and services may be used for the purpose of +issuing the EUDI Wallet. Likewise, the availability as well as terms and +conditions of device interface providers and related service providers +will set further constraints for EUDI Wallet Providers.

+

4.1.14 Qualified and Non-Qualified Electronic Attestation of Attributes Schema Providers

+

(Q)EAA Schema Providers publish schemas and vocabularies describing +(Q)EAA structure and semantics. It may enable other entities such as +Relying Parties to discover and validate (Q)EAA. The Commission sets out +the minimum technical specifications, standards, and procedures for this +purpose. Common schemas, including by sector- specific organisations are +critical for wide-spread adoption of (Q)EAAs.

+

4.1.15 National Accreditation Bodies

+

National Accreditation Bodies (NAB) under Regulation (EC) No +765/200813 are the bodies in Member States that perform +accreditation with authority derived from the Member State. NABs +accredit CABs as competent, independent, and supervised professional +certification bodies in charge of certifying products/services/processes +against normative document(s) establishing the requirements (e.g., +legislations, specifications, protection profiles). NABs monitor the +CABs to which they have issued an accreditation certificate.

+

4.2 Lifecycle of an EUDI Wallet

+

The legal text defines the EUDI Wallet on a high level of abstraction, as +well as for the EUDI Wallet Providers that carry the legal obligation to +make sure that the Users can get a valid and fully functional EUDI +Wallet. The lifecycle of an EUDI Wallet will have some interactions with +the Trusted List Providers that specify the status of a role in the EUDI +Wallet ecosystem in a trustworthy manner. Developing an Architecture and +Reference Framework that SHALL provide guidance to the development of +such EUDI Wallet requires a more detailed level of abstraction to be +efficient and to yield a sufficiently expressive architecture description +to be prescriptive.

+

This Chapter starts from a minimal object model and defines the +lifecycle of the core concepts: EUDI Wallet Solution, PID, (Q)EAA, and +EUDI Wallet Instance. These are chosen as a starting point because the +joint development of the ARF showed that the lifecycles of these +concepts are closely intertwined, which led to unclear description and +consequently misunderstandings.

+

The object model will be extended as required in future versions of the +ARF.

+

4.2.1 Simplified EUDI Wallet Object Model

+

Figure 2 below distinguishes the concepts of EUDI Wallet Solution and +EUDI Wallet Instance. An EUDI Wallet Solution is the entire product +and/or service provided by a EUDI Wallet Provider. A EUDI Wallet +Instance is a personal instance of a EUDI Wallet Solution that belongs +to and is controlled by a User.

+

Figure 2: Simplified EUDI Wallet Object Model

+ + +

Figure 2: Simplified EUDI Wallet Object Model

+

This definition is not prescriptive of form factor, hence depending on +the implementation a EUDI Wallet Instance may consist of a single mobile +app, or a set of local and remote components available to a specific +User.

+

4.2.2 PID and (Q)EAA Lifecycles

+

The lifecycles of PID and (Q)EAA are essentially identical, however, for +the scope of this description we refer subsequently only to PID. The +text of this section applied to PID applies mutatis mutandis to (Q)EAA.

+

PID in the context of the EUDI Wallet begins its lifecycle when being +issued to a EUDI Wallet Instance. Please note that this means that the +management of attributes in the Authentic Source (adhering to national +structures and attribute definitions) is outside of the scope of the +ARF.

+

Note that for certain use cases, the PID may be pre-provisioned, meaning +it is not yet valid when issued, but reaches its validity later. If PID +is issued on or after the validity start date, it is immediately +considered the state directly changes to valid. This means, however, +that PID could be "pre-issued".

+

Figure 3: State-chart of PID

+ + +

Figure 3: State-chart of PID

+

There are two possible transitions from a valid PID: it automatically +expires, by passage to the 'validity end date' or it is actively revoked +by its Provider. Expiration and revocation are essentially independent +transitions. Once PID is expired or revoked, it cannot transition back to +valid. If a change needs to be made to the PID (i.e., because of a User +name change), the PID Provider SHALL always issue a new PID.

+

4.2.3 EUDI Wallet Solution Lifecycle

+

An EUDI Wallet Solution has a state of its own, as defined by Article +10a of the Regulation. The state of the Solution affects the state of +all EUDI Wallet Instances of that EUDI Wallet Solution. The +Candidate state is the first state of a EUDI Wallet Solution. This +means it is fully implemented and the EUDI Wallet Provider requests the +solution to be certified as EUDI Wallet.

+

If all the legal and technical criteria have been met, including the +certification of the Wallet Solution by CAB(s), then a Member State may +decide to start providing Instances of the Solution to Users. The state +of the Solution becomes "valid". According to Article 6d, Member +State informs the Commission of each change in the certification status +of their EUDI Wallet Solutions. This means the EUDI Wallet Solution can +be officially launched, and Instances of the Solution can be provided to +Users.

+

Figure 4: State-chart of Wallet Solution

+ + +

Figure 4: State-chart of Wallet Solution

+

Under the legal conditions in Article 10a, paragraph 1, the issuing +Member State can temporarily suspend an EUDI Wallet Solution. This would +for example be the result of a critical security issue on that EUDI +Wallet Solution. This leads to the suspended state. Under Article +10a, paragraph 2, the issuing Member State can unsuspend the Wallet +Solution and continue issuance, bringing the Solution back to the +valid state. Under paragraph 3, the EUDI Wallet Solution can be +completely withdrawn.

+

4.2.4 EUDI Wallet Instance Lifecycle

+

An EUDI Wallet Instance lifecycle begins when the User installs the +mobile app component of the EUDI Wallet solution provided by The EUDI +Wallet Provider. Once an EUDI Wallet Instance is installed and +activated by the User and the EUDI Wallet Provider, it is in an +operational state. In this state, the User manages the EUDI Wallet +Instance, which may involve:

+
    +
  • The EUDI Wallet Provider updating the EUDI Wallet Instance,
    • +
  • The EUDI Wallet Provider revoking the EUDI Wallet Instance, possibly at + the User's request. Revocation of the Wallet Instance MAY be + accomplished by revoking the Wallet Instance attestation (refer to + section 6.3.4.2),
    • +
  • The User uninstalling the EUDI Wallet Instance.
    • +
+

In the operational state of the EUDI Wallet Instance:

+
    +
  • The User can request an attestation, such as a PID or a (Q)EAA. The + EUDI Wallet Instance may also fulfil non-EUDI specific functions, like + storing loyalty cards, or any other type of certification that doesn't + explicitly necessitate a link to a valid PID.
    • +
  • Once an attestation is issued to the EUDI Wallet Instance, the User + has the capability to release the attributes from this attestation to + a Relying Party, based on their discretion.
    • +
  • The PID/(Q)EAA Provider continues to be responsible for the management + of the attestation, which may include re-issuing it. The PID/(Q)EAA + Provider can also revoke the attestation, possibly at the User's + request. The specific management options will be detailed in + subsequent documents.
    • +
+

Once an EUDI Wallet Instance holds a valid PID set, it is +considered valid. If the PID expires or is revoked, the EUDI Wallet is +not automatically unusable, its state is merely downgraded back to +operational. This may affect the validity of a (Q)EAA or a certificate +for QES.

+

Figure 5: State-chart of Wallet Instance

+ +

Figure 5: State-chart of Wallet Instance

+

Please note that this is independent from the possibility of a PID or +(Q)EAA Provider to revoke their attestations.

+

5 EUDI data model

+

The European Digital Identity Ecosystem data model manages the following +types of attestations: +* Person Identification Data (PID): An attestation in electronic form + that allows the authentication of attributes proofing the identity of a + natural or legal person, or a natural person representing a legal + person, or of an object. +* Electronic Attestation of Attributes (EAA): An attestation in + electronic form that allows the authentication of attributes describing + features, characteristics or qualities of a natural or legal person or + of an entity, or a natural person representing a legal person, or of an + object. +* Qualified Electronic Attestation of Attributes (QEAA): an + electronic attestation of attributes (EAA), which is issued by a + qualified trust service provide, and adhering to Annex V of the + regulation.

+

5.1 Person Identification Data

+

This section details the PID set as presented by the EUDI Wallet. Further +specifications regarding PID are detailed in the PID Rule Book, found in +Annex A.6.

+

A PID Provider May issue a PID set to the EUDI Wallet and enable the use +of the EUDI Wallet as an electronic identification means when accessing +online and offline services.

+

The mechanisms through which the PID is generated and provided to the +EUDI Wallet are up to the Member States and are only constrained by legal +requirements such as the requirements of LoA High, GDPR or any other +national or union law.

+

In the following the data format as presented to the Relying Party will +be described, without any assumptions on how the EUDI Wallet retrieved or +generated this data beforehand.

+

5.1.1 PID format and associated requirements

+
5.1.1.1 Principles for the PID set
+

This Chapter proposes the definition of the PID set and discusses further +specification, data minimization and identifiers. The dataset proposed +herein is constructed based on the following principles:

+
    +
  • No two persons SHALL have the same PID set of values for mandatory + attributes.
    • +
  • The PID set SHALL at least contain the minimum set of attributes + aligned with eIDAS CIR 2015/150114 as mandatory.
    • +
  • The mandatory data set is by nature limited to the (narrow) + intersection of what all Member States can provide for all natural and + legal persons and what is needed for electronic identification + purposes. The mandatory data set will be complemented by optional + attributes available only in some Member States to ensure it is usable + for electronic identification purposes.
    • +
+
5.1.1.2 PID Attributes for Natural Persons
+

The below table provides an overview of mandatory and optional PID +attributes for natural persons.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Mandatory PID AttributesOptional PID Attributes
family_namefamily_name_birth
given_namegiven_name_birth
birth_datebirth_place
resident_address
gender
age_over_18
age_over_NN
age_in_years
age_birth_year
birth_country
birth_state
birth_city
resident_address
resident_country
resident_state
resident_city
resident_postal_code
resident_street
resident_house_number
nationality
+

Table 2 - Mandatory and optional PID attributes for natural persons

+

Possible additional optional attributes have been added to facilitate a +wider range of authentication options both online and offline as well as +addressing learning from the current eIDAS implementations. Metadata +associated with a PID set is further detailed in Annex A.6.

+

5.1.2 Issuing requirements for PID

+

The following table defines the requirements applicable to PID regarding +what information is included in the attestation, such as for purposes of +validity checks, authenticity, validation, policies, the data model, and +formats.

+

Future versions of this text may expand the table to specify +requirements. Note that these requirements are primarily aimed at the +first version of the EUDI Wallet Solution specifications, and that they +may change as the specifications evolve.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
#Requirement
1PID attestation MUST contain the information required to identify the PID Provider.
2PID attestation MUST contain the information required to perform a data integrity check.
3PID attestation MUST contain the information required for verifying the authenticity.
4PID attestation MUST contain all the information required to perform validity status checks on the attestation.
5PID attestation MUST include all the information (as an attribute or as any other signed value) required to perform verification of the holder binding by a Relying Party.
6PID attestation MUST be issued to be presented in accordance with both the data model specified in ISO/IEC 18013-5:2021 and the W3C Verifiable Credentials Data Model 1.1.
7PID attestation MUST be encoded as CBOR and JSON format.
8PID attestation MUST enable Selective Disclosure of attributes by using Selective Disclosure for JWTs (SD-JWT) and Mobile Security Object (ISO/IEC 18013-5) scheme accordingly to the data model.
9PID attestation MUST use signatures and encryptions formats as detailed in JOSE RFCs and COSE RFCs.
10PID attestation MUST use signature and encryption algorithms in accordance with SOG-IS ACM.
+

Table 3 - Issuing requirements for PID

+

5.2 Qualified and Non-Qualified Electronic Attestation of Attributes

+

5.2.1 Issuing requirements for (Q)EAA

+

The following table defines the requirements applicable to (Q)EAA-s +regarding what information is included in the attestation, such as for +purposes of validity checks, authenticity, validation, policies related +to key management, the data model, and formats.

+

(Q)EAA-s can be also issued under requirements applicable for PID.

+

Future versions of this text may expand the table to specify +requirements. Note that these requirements are primarily aimed at the +first version of the EUDI Wallet Solution specifications, and that they +may change as the specifications evolve.

+

Mobile Driving Licence attestations are further specified in mDL Rule +Book in Annex A.7.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
#Requirement
1(Q)EAA MUST contain the information required to identify the Provider.
2(Q)EAA MUST contain the information required to perform a data integrity check.
3(Q)EAA MUST contain the information required for verifying the authenticity of the (Q)EAA.
4(Q)EAA MUST contain all the information required to perform validity status checks on the (Q)EAA.
5(Q)EAA SHOULD include all the information (as an attribute or as any other signed value) required to perform verification of the holder binding by a Relying Party.
6(Q)EAA MUST be issued in accordance with one of the data model specifications: ISO/IEC 18013-5:2021, W3C Verifiable Credentials Data Model 1.1.
7**(Q)EAA SHOULD be encoded as one of the following formats: CBOR or JSON accordingly to the data model used for the attestation **
8EAA MAY be encoded as JSON-LD, see [JSON-LD].
9(Q)EAA SHOULD enable Selective Disclosure of attributes either by using Selective Disclosure for JWTs (SD-JWT) or Mobile Security Object (ISO/IEC 18013-5) scheme accordingly to the data model used for the attestation.
10(Q)EAA SHOULD use one of the following signature and encryption formats as detailed in: JOSE RFCs, COSE RFCs accordingly to data model used for the attestation.
11(Q)EAA SHOULD use signature and encryption algorithms in accordance with SOG-IS ACM.
12(Q)EAA SHOULD be issued accordingly to OpenID4VCI protocol.
+

Table 4 - Issuing requirements for (Q)EAA

+

5.3 Attestation rulebooks

+

Since version 1.2.0 of this document, the concept of an attestation +rulebook has been introduced. This is designed to compile a set of rules, +guidelines and standards governing the verification, management, and +usage of a specific attestation or group of attestations related to a use +case within the EUDI ecosystem. The primary goal of the rulebooks is to +ensure interoperability, security, privacy, and trust for EUDI Wallet's +attestations (PID and (Q)EAA).

+

Common compulsory specifications, rules, and guidelines are outlined in +the architecture and reference framework document, while those specific +to use cases are collated in the attestation's rulebooks. Two such +rulebooks, namely the PID and mDL rulebooks, have currently been included +as annexes to this document.

+

6 Trust Model

+

6.1 Overview and scope

+

The Trust Model describes, for all interactions in the lifecycle of a +EUDI Wallet Instance and an attestation, which trust relationships SHALL +exist between the interacting parties to enable these interactions.

+

Moreover, for the 'Attestation releasing' interaction in section 6.3.2, +this version of this document also describes, on a high level, how this +required trust can be established. This description includes references +to existing or draft standards that define detailed security measures.

+

The trust model is valid for both remote and proximity use cases. +However, technical measures taken to ensure that the requirements on +trust are fulfilled may differ between these two use cases. Moreover, the +authentication and authorization mechanisms will depend on the +characteristics of the interacting parties.

+

Please note:

+
    +
  • For interactions other than the 'Attestation releasing' interaction in + section 6.3.2, the technical measures are not yet described, although + section headings have been added already.
    • +
  • User privacy is not specifically discussed in this document.
    • +
+

6.1.1 Authentication and authorization

+

Within the EUDI Wallet ecosystem, many interactions take place between +parties in which one party requests another party to release data or +perform a task. For example, a User may ask a Provider to provide a PID +or (Q)EAA to a Wallet, or a Relying Party may ask a User to release a +specific attestation from its EUDI Wallet Instance. To be able to comply +with such requests, these parties SHALL trust each other. This trust +generally requires the existence of the following two conditions:

+
    +
  1. The requestee is sure about the identity of the requester, and + optionally the requester is sure about the identity of the requestee. + This is referred to as (single-side or mutual) authentication.
    2. +
  2. The requestee is sure that the requester has the right to request + the data or task requested. This is referred to as authorization.
    3. +
+

6.1.2 Assumptions on trust

+

This document makes the following assumptions regarding the need for +trust in the EUDI Wallet ecosystem:

+
    +
  • For any party in the EUDI Wallet ecosystem, there is a risk that it + could be impersonated by an attacker. Therefore, when any interaction + between two parties takes place, both parties SHALL be able to + authenticate the other. Note that this assumption does not mean that + mutual authentication SHALL always take place; it just means that the + possibility to do so SHALL exist and be available if one party has a + business need to authenticate the other party it is interacting with. + No authenticated party can be presumed trustworthy enough not to ask + for attributes beyond their rights.
    • +
+

6.1.3 Other trust relations

+

Besides the trust relationships described in this Chapter, other trust +relations SHALL exist as well. For instance, Users, Providers and Relying +Parties SHALL implicitly trust certification bodies, trusted list +providers, vendors, OEMs, operating systems, and app stores. In many +contexts, this trust is primarily be rooted in authority and in +procedural measures, such as public oversight, published security and +operational policies, audits, etc., rather than in technical measures. To +verify that parties are indeed interacting with a trusted authority, +standard technical measures suitable for the context SHALL be used.

+

Moreover, besides the need for trust in the authenticity and +authorization of other parties in the ecosystem, parties SHALL also be +able to trust that the communication with such parties is confidential. +Measures to ensure this are not explicitly discussed in this document.

+

6.2 Trust throughout a EUDI Wallet Instance lifecycle

+

6.2.1 Wallet Instance installation

+
6.2.1.1 Required trust relationships
+

When a User decides to install an EUDI Wallet Instance on their device, +the following trust relationships SHALL exist:

+
    +
  1. The User SHALL be able to trust that the Wallet Solution (i.e., the +app or application the user is installing) is genuine, authentic and does +not contain any malware or other threats.
    2. +
  2. The User SHALL be able to trust that the PID Provider will issue the +PID into an instance of a EUDI Wallet Solution.
    3. +
  3. The User SHALL trust the EUDIW solution. This means that the User +trusts the App store and the App publisher.
    4. +
+

The next sections discuss these trust relationships.

+
6.2.1.2 User's trust in the EUDI Wallet Solution
+

To be done.

+
6.2.1.3 User's trust that the EUDI Wallet Solution is supporting the attestations
+

To be done.

+

6.2.2 EUDI Wallet Instance activation

+
6.2.2.1 Required trust relationships15
+

After its' installation, a new EUDI Wallet Instance will need to be +activated by the Wallet Provider. Activation has at least the following +purposes:

+
    +
  • The EUDI Wallet Provider makes the EUDI Wallet Instance identifiable, + by assigning an identifier to the Wallet Instance. This identifier is + internal; its purpose is to allow the EUDI Wallet Provider to identify + the EUDI Wallet Instance, for example when the User requests that the + EUDI Wallet Instance SHALL be revoked.
    • +
  • The EUDI Wallet Provider sets up a secure (authenticated) communication + channel between the EUDI Wallet Instance and the EUDI Wallet Provider + backend, for future use.
    • +
  • The EUDI Wallet Provider requests data about the User's device from the + EUDI Wallet Instance. This data may include the communication + technologies supported by the device and the characteristics of the + WSCD used by the device to securely store cryptographic keys and data + associated with the EUDI Wallet Instance and the attestations.
    • +
  • The EUDI Wallet Provider issues a EUDI Wallet Instance Attestation to + the EUDI Wallet Instance. This attestation contains data about the EUDI + Wallet Provider, the EUDI Wallet Solution, the EUDI Wallet Instance, + the device and the WSCD. The EUDI Wallet Instance attestation has the + same technical format and content as other attestations. This implies + that the attestation will contain a Wallet Instance public key. The + EUDI Wallet Instance key pair is generated by the EUDI Wallet Instance + during activation, using the WSCD present in, or connected to, the + User's device. The EUDI Wallet Instance attestation also contains + information that allows a Provider or Relying Party to verify that the + EUDI Wallet Provider did not revoke the EUDI Wallet Instance + attestation, and hence the EUDI Wallet Instance itself.
    • +
  • The EUDI Wallet Provider locally associates the EUDI Wallet Instance + with a particular User, including on-device or backend-based User + authentication methods that will be used by the EUDI Wallet Instance to + authenticate the User towards the EUDI Wallet Provider only. The User + details SHALL NOT be included in the EUDI Wallet Instance attestation.
    • +
  • The EUDI Wallet Provider sets up a User account. This User account is + needed if the User wants to interact with the EUDI Wallet Provider + without using their EUDI Wallet Instance. An example of this is a + request to revoke a EUDI Wallet Instance in case the User's device is + lost or stolen. EUDI Wallet Providers MAY also offer other + instance-related services through this User account. Please note the + following:
    • +
  • In general, the EUDI Wallet Provider does not need to know the true + identity of the User. An alias, for example an e-mail address, is + sufficient. However, the EUDI Wallet Provider MAY request the true + identity of the User to be able to offer additional services. It is + up to the EUDI Wallet Provider to determine the conditions for + creating an online account, and to the User to accept or refuse these + conditions.
    • +
  • The information in the User account, especially the identifier(s) for + the User, the User's device, and the EUDI Wallet Instance (if any), + SHALL be stored and used only in the EUDI Wallet Provider back + office. The EUDI Wallet Provider SHALL NOT put this information in + the EUDI Wallet Instance attestation.
    • +
+

For successful EUDI Wallet Instance activation, the following trust +relations need to exist:

+
    +
  1. The EUDI Wallet Instance needs to be able to trust the EUDI Wallet + Provider, meaning that the instance is sure that it is dealing with + the genuine EUDI Wallet Provider.
    2. +
  2. The EUDI Wallet Provider needs to be able to trust the EUDI Wallet + Instance. This means that the EUDI Wallet Provider is sure that the + instance is indeed a true instance of their EUDI Wallet Solution, and + not a fake app.
    3. +
+

The next sections discuss these trust relationships.

+
6.2.2.2 EUDI Wallet Instance trusts Wallet Provider
+

To be done.

+
6.2.2.3 EUDI Wallet Provider trusts Wallet Instance
+

To be done.

+

6.2.3 EUDI Wallet Instance management

+
6.2.3.1 Required trust relationships
+

Starting from EUDI Wallet Instance activation and throughout its +lifetime, a EUDI Wallet Instance SHALL be managed by the EUDI Wallet +Provider. Management actions could be initiated by the following +entities.

+
    +
  • The EUDI Wallet Provider. For example, to perform the installation + of a new version of the Wallet Solution upon users request or + approval.
    • +
  • The User. For example, to request the Wallet Provider to revoke + the Wallet Instance in case of loss or theft.
    • +
  • The EUDI Wallet Instance, potentially. For example, to request an + update of the EUDI Wallet Instance Attestation, as defined in section + 6.2.2.
    • +
+

For this, the following trust relations need to exist:

+
    +
  1. The User needs to be able to trust the EUDI Wallet Provider. This + means that the User is sure that he is dealing with the genuine EUDI + Wallet Provider responsible for their EUDI Wallet Instance.
    2. +
  2. The EUDI Wallet Instance needs to be able to trust the EUDI Wallet + Provider, meaning that the EUDI Wallet Instance is sure that it is + dealing with the genuine EUDI Wallet Provider.
    3. +
  3. The EUDI Wallet Provider needs to be able to trust the EUDI Wallet + Instance. This means that the EUDI Wallet Provider is sure that the + EUDI Wallet Instance is indeed a true instance of their EUDI Wallet + Solution, and not a fake app.
    4. +
  4. The EUDI Wallet Provider needs to be able to trust the User. This + means that the EUDI Wallet Provider is sure that the User is indeed + the User that was associated with the EUDI Wallet Instance during + activation; see section 6.2.2.1.
    5. +
+

The next sections discuss these trust relationships.

+
6.2.3.2 EUDI Wallet Instance trust in the Wallet Provider
+

Section 6.2.2.2. describes how a EUDI Wallet Instance can trust a Wallet +Provider.

+
6.2.3.3 EUDI Wallet provider trust in the EUDI Wallet Instance
+

Section 6.2.3.3. describes how a EUDI Wallet Provider can trust a Wallet +Instance.

+
6.2.3.4 User trust in the EUDI Wallet Provider
+

To be done.

+
6.2.3.5 EUDI Wallet Provider trust in the User
+

To be done.

+

6.3 Trust throughout an attestation lifecycle

+

6.3.1 Attestation issuance

+
6.3.1.1 Required trust relationships
+

When a User requests a Provider to issue a PID or (Q)EAA to their EUDI +Wallet Instance, the following trust relationships SHALL exist:

+
    +
  1. The User SHALL be able to trust the Provider, meaning that the User is + sure that the attestation they receive is issued by an authorized + Provider.
    2. +
  2. The Provider SHALL be able to trust the User, meaning that the + Provider is sure about the identity of the User. This is necessary to + be able to determine the value of the attributes that the Provider + will attest to. For instance, a PID Provider SHALL ensure it provides + the correct family name and date of birth to the Wallet Instance. + Please note that the method by which the provider performs user + identification and authentication is out of scope of this document.
    3. +
  3. The Provider SHALL be able to trust the EUDI Wallet Provider.
    4. +
  4. The Provider SHALL be able to trust the EUDI Wallet Instance. This + means the Provider can verify that the app that it is interacting with + is indeed an instance of the approved Wallet Solution of a trusted + EUDI Wallet Provider. Moreover, If the Provider has specific + functional requirements for EUDI Wallet Instances containing 'their' + attestations, the Provider SHALL be able to trust that the User's EUDI + Wallet Instance indeed supports all these features.
    5. +
+

The next sections discuss these trust relationships.

+
6.3.1.2 User trust in the Provider
+

To be done.

+
6.3.1.3 Provider trust in the User
+

To be done.

+
6.3.1.4 Provider trust in the EUDI Wallet Instance
+

To be done.

+

6.3.2 Attestation releasing

+
6.3.2.1 Required trust relationships
+

When a Relying Party (RP) requests a User to release some attributes from his/her EUDI Wallet Instance, the following trust relationships mustSHALL exist:

+
    +
  1. The Relying Party SHALL be able to trust the attestation Provider.
    2. +
  2. The Relying Party SHALL be able to trust that the attestation released + by the EUDI Wallet Instance is authentic, meaning that it originated + from a trusted Provider and has not been changed.
    3. +
  3. The Relying Party SHALL be able to trust that the attestation Provider + issued this attestation to the EUDI Wallet Instance that provided it + to the Relying Party. In other words, the attestation was not copied + and replayed. This is generally called device binding.
    4. +
  4. The Relying Party SHALL be able to trust the EUDI Wallet.
    5. +
  5. The User SHALL be able to trust the Relying Party, meaning that the + User is sure about the Relying Party's identity.
    6. +
  6. The User SHALL be able to trust that the Relying Party does not + request more data than it reasonably needs for the use case.
    7. +
+

The next sections discuss these trust relationships.

+

Please note the following assumptions, which are valid at least for the +current version of this document:

+
    +
  • All attestations are assumed to be signed by the attestation Provider, + rather than by the EUDI Wallet Instance (the latter are sometimes + called self-signed attestations). The only attestations that will be + trusted by Relying Parties are those that are signed by a trusted + attestation Provider. The only potential exception may be a pseudonym + for the User. If the value of a pseudonym attribute is assigned by the + User or generated by the Wallet instance, it MAY be signed by the EUDI + Wallet Instance rather than the Provider. If so, a Relying Party using + such a pseudonym SHALL accept the associated risks or mitigate it in an + out-of-band manner. These risks may include the possibility of fake + pseudonyms, created by an attacker capable of lifting an attestation + private key from a WSCD.
    • +
  • A Relying Party is assumed to trust the attestation Provider to have + verified the technical properties of the EUDI Wallet Instance and the + User's device and WSCD (as documented in the Wallet Instance + attestation) at the time it issued the attestation. Consequently, the + Relying Party does not verify these technical properties during the + attestation release process. To elaborate: A Relying Party typically has + a list of attestations that it accepts for a certain use case. For + example, a Relying Party MAY accept a mobile driving license as a proof + of identity. If so, that Relying Party SHALL accept any valid and + authentic mDL, regardless of the mobile device it is installed on. If the + Relying Party were to make its own independent assessment of the security + of the User's device, there is a possibility that an mDL will not be + accepted, even though it is valid. That would be confusing to Users and + might diminish their trust in the EUDI Wallet Instance as well as the + attestation.
    • +
  • An attestation is assumed to be bound to the EUDI Wallet Instance (and + thus the device) to which the Provider issued it, and the Relying Party + will verify that this is indeed the case. In other words, a Relying + Party verifies device binding as described in section 6.3.2.4. This is + a consequence of the fact that either ISO/IEC 18013-5 or OpenID4VP is + mandatory for the EUDI Wallet Solutions that are in scope of the + current version of this document.
    • +
+
6.3.2.2 Relying Party trusts Provider
+

A Relying Party SHALL be able to verify that the Provider is trusted to +issue the type of attestation in question. For instance, a Provider may +be trusted to issue a diploma, but not a PID, or conversely.

+

As part of this verification process, the Relying Party also obtains a +public key of the Provider, which functions as a trust anchor and allows +it to verify the attestation signatures created by the Provider. There +are at least two methods to communicate this public key, using +peer-to-peer communication, or using a trusted list. The public key +itself may be encapsulated, for instance in a X.509 certificate or in an +Entity Statement according to OpenID Federation.

+

Peer-to-peer communication of the Provider public key (trust anchor) +means that every Relying Party individually decides to trust each +Provider. The Relying Party then obtains the Provider's public key via a +manual or automated process agreed between the Provider and the Relying +Party, for instance by downloading it from the Provider's website. A +peer-to-peer process has the advantages of flexibility and low overhead. +However, it is hardly scalable and therefore not suitable for +attestations such as PIDs, mDLs, diplomas, or health insurance cards, for +which there many tens to hundreds of different providers in the EU and +thousands of Relying Parties, which moreover do not (necessarily) know +each other. Moreover, a peer-to-peer process assumes that each Relying +Party has sufficient technical knowledge and budget to judge the level of +security of each Provider's systems and processes for, among others, +private key management. This is not realistic for high-value +attestations. A peer-to-peer process may therefore be suitable for +low-value attestations in contexts where Providers and Relying Parties +know each other, for example membership cards or vouchers.

+

For more valuable attestations, or for attestations for which Providers +and Relying Parties do not know each other, a trusted list of Providers +is a better solution. This trusted list is provided by a trusted list +provider, which is a central party responsible for (and capable of) +verifying that the level of security of an Providers' systems and +processes is sufficient for the type of attestation it issues, and +comparable to the level of security of other Providers for the same type +of attestation. This may include requiring that a Provider documents +these systems and processes, for example in a certificate policy +complying with EN 319 411, and is audited regularly for compliance to +that policy. The trusted list provider also validates that each Provider +is (legally) allowed to issue the type(s) of attestation it wants to +issue. The trusted list provider documents that in its trusted list, +together with the public key (trust anchor) of each trusted Provider. The +list is signed by the trusted list provider and can be downloaded and +processed by a Relying Party in an automated fashion.

+

Please note the following:

+
    +
  • A trusted list provider may become a single point of failure. A + successful attack may mean that untrusted Providers are put on the + trusted list. It is therefore essential that the systems and processes + used by a trusted list provider are secure.
    • +
  • There can be multiple trusted list providers. It is conceivable that + there will be trusted list providers on the EU level and for individual + member states, as well as trusted list providers per sector, for + example education or health care.
    • +
  • It is not mandatory for each Relying Party to possess the root + certificates of all Providers. Relying Parties will choose which + trusted list providers they need to subscribe to, depending on the + Member States and industries they are operating in.
    • +
+

Finally, note that freedom of contract applies to all Relying Parties. +This means that a Relying Party can determine itself which Providers they +want to recognize, except if there is a legal requirement that the +attestations of certain Providers SHALL be accepted. That is generally +the case for PID Providers and QEAA Providers. However, this does not +mean that the above process is not necessary for these providers.

+
6.3.2.3 Relying Party trusts the authenticity of the attestation
+

The following steps are essential for ensuring that the Relying Party +can trust the attestation:

+
    +
  1. The Relying Party verifies the seal or signature over the attestation.
    2. +
  2. The Relying Party verifies that the public key it used for verifying + the seal or signature can be trusted, either because the Relying Party + obtained the key in a manner described in section 6.3.2.2, or because + is protected by means of a chain of trust that ends in a trusted + Provider public key that was obtained in such a manner.
    3. +
  3. The Relying Party validates that the Provider has not revoked the + attestation.
    4. +
+

If and only if all these verifications succeed, the Relying Party can +trust the authenticity of the attestation.

+

Regarding the technical implementation of these steps:

+
    +
  • For proximity flows, requirements 6 and 7 in section 5.1.2 require support for [ISO18013-5]. This standard describes a mechanism for this authentication, called Provider data authentication.
    • +
  • For step 1 above, this mechanism uses a cryptographically signed data construct called a Mobile Security Object (MSO). The seal or signature over the MSO is created by a Document Signer, which is a function of the Provider. The Document Signer certificate is signed by the Provider's certificate.
    • +
  • For step 2 above, ISO/IEC 18013-5 specifies a Public Key Infrastructure, including certificate formats and a format for implementing a trust list.
    • +
  • The mechanism for step 3 is described in section 6.3.4.
    • +
  • For remote flows, requirements 6 and 7 in section 5.1.2 require support for [SD-JWT].
    • +
  • For step 1 above, [SD-JWT] provides a similar trust mechanism as the MSO mechanism in ISO/IEC 18013-5.
    • +
  • The mechanism for step 3 is described in section 6.3.4.
    • +
+
6.3.2.4 Relying Party trusts device binding
+

The Relying Party SHALL be able to trust that an attestation it receives was not copied and replayed. In other words, the Relying Party trusts that the attestation is bound to the same device to which the Provider issued it 16.

+

The Relying Party can trust that this is the case if the EUDI Wallet Instance signs some contextual information with the private key of the attestation. This information SHALL include a random number generated by the Relying Party. To verify this signature, the Relying Party needs to receive the public key of the attestation, which SHALL be signed (directly or indirectly) by the Provider of the attestation. By signing the public key, the Provider certifies that the public key indeed belongs to the attestation. The Relying Party SHALL additionally verify that the Wallet Instance is in possession of the corresponding private key; the Relying Party does so by verifying the signature over the random number generated by the Relying Party.

+

Note that a EUDI Wallet Instance can contain multiple attestations, originating from multiple Providers. For each attestation, the EUDI Wallet Instance has access to an attestation private key, which is stored in the WSCD in (or connected to) the User's device. As discussed in section 6.2.2, the EUDI Wallet Instance also contains a EUDI Wallet Instance private key. Depending on the attestation requested by the 6.3.2.4, the EUDI Wallet Instance SHALL use the correct private key for signing the random number generated by the Relying Party.

+

[ISO/IEC 18013-5] specifies a mechanism for this, called mdoc authentication. The EUDI Wallet Instance signs contextual information (called the SessionTranscript), which includes a nonce from the Relying Party, namely its ephemeral public key for session encryption. The standard specifies which algorithms can be used for signing and how the attestation public key is incorporated in the MSO.

+

[SD-JWT] similarly specifies how an attestation public key can be incorporated in the JWT.

+

To trust these mechanisms, the Relying Party SHALL trust that the security of the attestation private key has not been compromised. This private key is stored in a WSCD, or connected to, the device on which the EUDI Wallet Instance is installed. As discussed in section 6.3.2.1, the Relying Party does not need to perform an independent evaluation of the security of the WSCD, because it trusts the Provider to have done this. However, the Relying Party SHALL verify that the Provider did not revoke the attestation.

+
6.3.2.5 Relying Party trusts User binding
+

A Relying Party SHALL be able to trust the EUDI Wallet.

+

Note: Use cases involving legal representation and similar situations, +which imply that the person presenting is different from the User, but +the same as the person having the legal representation rights, are out of +scope of the current version of the Trust Model and will be explored in +future versions of this document.

+

The mechanism(s) for User binding depend on the type of use case:

+
    +
  • For supervised proximity flows, a human is present during the + transaction, on behalf of the Relying Party. If User binding is + required in such cases, the Relying Party can request the User + portrait, next to other attributes, and the EUDI Wallet Instance can + release it. The portrait SHALL be signed by a trusted Provider 17. + The human supervisor then visually compares this portrait to the face + of the person presenting the attestation. However, please note that the + presence and use of the User portrait in the PID will be further + detailed in a future version of this document.
    • +
  • For some unsupervised proximity flows, the User portrait may similarly + be released and be used for face recognition by a machine. This may + happen for example in automatic border control systems. However, to + generate trustworthy outcomes this process requires special conditions, + such as good lighting and clear instructions for the User for + positioning their face.
    • +
  • For other unsupervised use cases and for remote use cases, using the + User portrait for user authentication by the Relying Party is generally + considered to be impractical. Relying Parties SHALL therefore trust + User authentication mechanisms present on or connected to the device + which the EUDI Wallet Instance is installed on 18.
    • +
+
6.3.2.6 User trusts the identity of the Relying Party
+

To ensure that the User knows and trusts the identity of the Relying +Party, a mechanism for Relying Party authentication mustSHALL be +implemented. In essence, such a mechanism works as follows:

+
    +
  1. The Relying Party creates a signature over the request using a Relying + Party private key. The Relying Party includes the associated Relying + Party certificate in the request. This certificate is signed by a + certificate authority (CA) trusted by the Wallet Instance for this + purpose. This step will include mechanisms that will prevent replay + attacks and possible other attacks.
    2. +
  2. The Wallet Instance verifies the signature over the request, and + verifies that the Relying Party certificate is indeed issued by the + trusted CA.
    3. +
  3. The Wallet Instance validates that the trusted CA has not revoked the + Relying Party certificate.
    4. +
+
6.3.2.7 User trusts that the Relying Party does not over-ask
+

How this trust relationship is established is described in section 7.6 on Relying Party authorization.

+

6.3.3 Attestation management

+

Throughout its lifetime, an attestation needs to be managed by the +Provider. This means that for the purposes of this Trust Model, +attestation management has similarities to the part of EUDI Wallet +Instance management that involves the EUDI Wallet Provider as the +Provider of a EUDI Wallet Instance attestation, which was already +discussed in section 6.2.3.

+

6.3.4 Attestation revocation

+

Attestation revocation is a process whereby the Provider of an +attestation declares that Relying Parties SHOULD no longer trust a +particular attestation, even though the attestation is still valid +temporally and contains a valid Provider signature. As described in +section 4.2.4 of [TrustModel], during the process of releasing an +attestation, a Relying Party SHOULD verify that the Provider has not +revoked the attestation. Revocation checking is a process that takes +place after the Relying Party has validated that the validity period of +the attestation has not expired and the signature over the attestation is +correct.

+

The Relying Party uses a Relying Party Instance to interact with the +User's Wallet Instance. This includes carrying out attestation revocation +checking.

+

When discussing attestation revocation, it is essential to realize that +in many cases there is a difference between an attestation and the +document it represents, for instance a driving license, passport, +recurring medicine prescription, health insurance card, vehicle +registration card, etc. Such a document typically has an administrative +validity period of multiple years. A diploma typically even has no end of +validity at all. In contrast, an attestation is a digital representation +of such a document and has a cryptographic proof of its authenticity with +a validity period that is typically short, for example - several weeks.

+

This implies that an attestation Provider will renew the attestation +regularly during the validity period of the document19. Also, an +attestation Provider MAY issue multiple attestations that are +simultaneously valid but represent the same document. For example, a User +MAY have a mobile passport on their private phone and their work phone. +The attestations representing the passport on both phones will be +different, even though they contain the same attributes. The difference +is in the MSO (for ISO-compliant attestation) or SD-JWT + JWS (for SD-JWT +compliant attestation).

+

In some cases, this difference is relevant for revocation. For example, +if the above User loses their personal phone, the Provider will probably +revoke the mobile passport on that phone. But the attestations on the +work phone will remain valid, and the User will continue to be able to +use their passport on that phone. On the other hand, if the passport +itself is revoked, then all attestations representing their passport, +across both devices, will be revoked.

+
6.3.4.1 Use cases for revocation of an attestation
+

Within the EUDI Wallet ecosystem, an attestation SHALL be revoked if one +of the following conditions occur:

+
    +
  • The value of some attributes in the attestation has changed, and the + attestation can be valid still for some time. In such cases, the + Provider can issue a new attestation to the Wallet Instance, containing + the new, correct value for the changed attribute. However, the Provider + also needs to ensure that Relying Parties can no longer accept the + existing attestation. For example,
    • +
  • A PID contains the age_over_18 attribute, and the User has their + 18th birthday. The value of the attribute needs to change from False + to True.
    • +
  • A User loses an existing driving category. A category needs to be + removed.
    • +
  • The attestation was wrongly issued.
    • +
  • The attestation Provider suspects or knows the User has committed fraud + or other relevant crime.
    • +
  • The User notified the attestation Provider.
    • +
  • In case of any (suspected) breach of security.
    • +
+

The attestation Provider SHALL analyze whether revocation is required in +these circumstances. Also, the Provider SHALL analyze if there are more +situations in which attestation revocation is required.

+

A PID Provider or a (Q)EAA Provider MAY outsource the responsibility of +operating the revocation solution to a third party. However, the Provider +SHALL always remain responsible for triggering the revocation process for +an attestation if needed, and for the correctness of the revocation +information.

+

The only party in the EUDI Wallet ecosystem capable of revoking an +attestation SHALL be the attestation Provider. This is important, because +in some use cases, there are third parties that have the (legal) right to +invalidate an attestation. For example, in many jurisdictions the police +are allowed to confiscate a driving license if the User is caught is a +serious traffic violation. Another example is an electronic prescription +for medicines that is valid only once and must not be usable anymore +after the User has received the medicines20 . A third example is when +the attestation Provider and the Authentic Source for that attestation +are different parties. If so, the Authentic Source contains the +authoritative information about whether an attribute value must be +changed, and an attestation revoked or reissued. It must be the +responsibility of attestation Providers to regularly query the authentic +source for changes and reissue or revoke the relevant attestations +accordingly.

+

However, third parties that want to invalidate an attestation SHALL use +an out-of-band mechanism to notify the Providers about the attestation +that must be revoked. It is then up to the Provider to revoke the +attestation.

+

Comment: In case an attestation Provider is hacked, lost or ceases to +operate permanently for any reason, regular procedures SHALL be initiated +according to the situation. Instead of revoking each attestation that was +issued by that attestation Provider, the Provider itself SHALL be +revoked and taken out from the relevant Trusted List, for example, so +that each time that attestation will be verified, it will fail because +the Providers' anchor of trust was not found in the Trusted List.

+
6.3.4.2 Use cases for revocation of a Wallet Instance
+

This document assumes that in some circumstances, a Wallet Provider +(perhaps on the initiative of a Member State) will need to revoke a +Wallet Instance. For example:

+
    +
  • if a major security incident has been found in the Wallet Solution. In + this case, all instances of that Wallet Solution might be revoked (or + suspended, see section 6.3.4.3).
    • +
  • if a major security Incident has been found in the mobile device on + which the Wallet Instance runs, or in the WSCD it uses.
    • +
  • if a particular Wallet Instance has been the subject of an attack.
    • +
  • if the User notified the Wallet Provider that their device is lost or + stolen.
    • +
+

As can be seen from these examples, Wallet Instance revocation is more +complicated than attestation revocation, as a Wallet Instance consists of +multiple components that each may fail for different reasons. This +document does not specify a mechanism to be used by a Wallet Provider to +revoke a Wallet Instance, and by a Relying Party to verify if a Wallet +Instance has been revoked. Such a mechanism will be specified in a future +Epic.

+
6.3.4.3 Use cases for suspension
+

In addition to revocation, there is the concept of suspension of an attestation. The main difference between these concepts is that suspension is reversible, whereas revocation SHALL be irreversible. However, suspension is inherently more complex to manage than revocation. Moreover, in the EUDI Wallet ecosystem, in which issuance of a new attestation to replace a revoked one is typically easy, the advantages of a suspension mechanism are limited. Therefore, a Provider SHOULD NOT suspend any attestation. No mechanisms for suspension of attributes are foreseen in this document.

+

A (possible) exception to this rule is that Wallet Providers MAY be able to suspend a Wallet Instance in case the corresponding Wallet Solution is suspended. As described in section 4.2.3, this MAY be a legal requirement. This will be discussed in a future Epic.

+

Unless indicated otherwise, all requirements and other statements in this document for a revocation mechanism are applicable for a suspension mechanism as well.

+
6.3.4.4 Revocation checking in wallet-to-wallet use cases
+

To be done.

+
6.3.4.5 Cross-border and cross-sector use cases
+

To be done.

+
6.3.4.6 Revocation chaining
+

To be done.

+
6.3.4.7 Requirements for attestation revocation mechanisms
+

A mechanism for attestation revocation and revocation checking SHALL comply with the following requirements:

+
    +
  1. The revocation mechanism SHALL be easy to implement and be integrated + with Wallet Instances based on ISO/IEC 18013-5 and [SD-JWT].
    2. +
  2. The revocation mechanism SHALL be independent of the Wallet Instance, + meaning that even if the Wallet Instance is not trustworthy anymore, + the Relying Party Instance can still verify, in a trustworthy manner, + whether the attestation has been revoked. This implies that the + Relying Party SHALL be able to obtain revocation status information + independently from the Wallet Instance.
    3. +
  3. The revocation mechanism SHALL be privacy-preserving, to the maximum + extent feasible given operational constraints.
    4. +
  4. The Provider SHALL NOT be able to learn anything about the User's + use of an attestation based upon interactions between Relying + Parties and the Provider related to attestation revocation checking.
    5. +
  5. Any attestation identifiers and other values used for enabling + revocation checking SHALL NOT allow Relying Parties to correlate + (and thus track) the User, even if they collude with other Relying + Parties.
    6. +
  6. The revocation mechanism SHALL be efficient, meaning that it SHALL + require minimal resources from both the Provider and the Relying + Parties in terms of bandwidth and storage.
    7. +
  7. The revocation mechanism SHALL be timely, meaning that revocation + updates SHALL be fresh enough to satisfy the needs of Relying Parties + that need to trust the attestation.
    8. +
  8. The revocation mechanism SHALL support use cases in which the Relying + Party Instance is offline.
    9. +
  9. If required by national legislation, the revocation mechanism SHALL + allow a Relying Party to prove afterwards that an attestation was not + revoked at the time of verification, for example in case of a dispute + between the Relying Party and the User.
    10. +
  10. The revocation mechanism SHOULD be mature, meaning that many different + parties have experience with implementing and operating the mechanism.
    11. +
+
6.3.4.8 Possible revocation mechanisms
+

The concept of an attestation, is in many ways similar to digital +certificates in Public Key Infrastructures (PKI). The experience of +revoking such certificates can therefore be drawn upon. Two main +revocation mechanisms are generally supported in a PKI:

+
    +
  • In the first place, the Provider of the digital certificate can create + a list of revoked certificates, sign it, and make it available to all + interested Relying Parties. When a Relying Party needs to use a + certificate, it SHALL verify that the identifier of this certificate is + not included in the list of revoked certificates. Such a list is known + as a Certificate Revocation List (CRL). In the context of the EUDI + Wallet ecosystem, we will refer to it as an Attestation Revocation List + (ARL).
    • +
  • Secondly, the Provider of the digital certificate can set up a service + that may be interrogated by a Relying Party in real time when the + Relying Party needs to use a certificate. The Relying Party provides an + identifier of the certificate, and the Provider responds with the + corresponding current status, e.g., 'valid' or 'revoked'. A variation + of this mechanism is possible, where it's not the Relying Party, but + rather the subject of the certificate that requests the current + revocation status of the certificate from the Provider service. The + certificate subject then sends the response to the Relying Party + together with the certificate itself. This mechanism is known as the + Online Certificate Status Protocol (OCSP), and the variation is known + as 'OCSP stapling'. The server from which a Relying Party can get + information regarding the revocation status of an attestation is the + OCSP Responder. In the context of the EUDI Wallet ecosystem, we will + refer to it as an Online Attestation Status Protocol (OASP), OASP + stapling and an OASP Responder.
    • +
+

Apart from these two mechanisms, Attestation Status Lists (ASL) are often +mentioned as a third possible revocation mechanism. The basic idea of an +Attestation Status List is that an attestation Provider, or a trusted +party acting on its behalf, publishes revocation status information for +all of its valid attestations in the form of a bitstring or byte array. +Each attestation is associated with a specific position in the +Attestation Status List. If the binary value of the position in the list +is 1, the associated attestation has status Revoked. If it is 0, it is +Valid. To verify whether a specific attestation has been revoked, a +Relying Party needs to retrieve the Attestation Status List. Therefore, +each attestation contains the URL where the ASL is located. The +attestation also contains an index, which is the position of the bit +associated with the attestation within the Attestation Status List. The +Relying Party then verifies if the value of the bit at the index position +is equal to 0 (Valid) or 1 (Revoked).

+

Other approaches to revocation exist. However, these have not been +implemented widely compared to the CRL and OCSP mechanisms described +above, and sometimes require comparatively more advanced cryptography.

+
6.3.4.9 Requirements for support of attestation revocation mechanisms
+

Relying Party Instances and Relying Parties SHALL support the Attestation +Status List mechanism and the Attestation Revocation List mechanism +specified in section 6.3.4.8. Relying Party Instances and Relying Parties +MAY additionally support the Online Attestation Status Protocol specified +in section 6.3.4.8.

+

Wallet Instances SHALL support the Attestation Status List mechanism +specified below and the Attestation Revocation List mechanism specified +in section 6.3.4.8. Wallet Instances MAY additionally support the Online +Attestation Status Protocol specified in section 6.3.4.8.

+

Wallet Instances and Relying Party instances MAY additionally support +OASP stapling. However, the current version of this document does not +contain a full specification of this mechanism.

+

Attestation Providers SHALL support one of the following methods for +attestation revocation:

+
    +
  1. Use short-lived attestations only, such that attestation revocation + will never be necessary since the revocation process will take longer + than the validity period of the attestation. In this case, the + Provider does not need to support any of the revocation methods + specified in this Chapter and attestations do not need to contain any + information enabling the Relying Party to do a revocation check. + According to requirement REV-6.2.4-03A in ETSI EN 319 411-1 (Trust + Service Providers issuing certificates; Part 1: General requirements), + the revocation process must take at most 24 hours. Therefore, + Providers SHALL NOT use this method for attestations having a validity + period of more than 24 hours except for non-qualified attestations.
    2. +
  2. The Attestation Status List mechanism specified in section 6.3.4.8. In + this case, depending on whether the attestations are ISO-compliant or + SD-JWT-compliant, the Provider SHALL extend the MSO of its + attestations, or the Provider SHALL extend the SD-JWT of its + attestations.
    3. +
  3. Regarding the Attestation Revocation List mechanism, depending on + whether the attestations are ISO-compliant or SD-JWT-compliant, the + Provider SHALL extend the MSO of its attestations, or the Provider + SHALL extend the SD-JWT of its attestations.
    4. +
+

Providers MAY additionally support the Online Attestation Status +Protocol. In this case, depending on whether the attestations are +ISO-compliant or SD-JWT-compliant, the Provider SHALL extend the MSO of +its attestations or the Provider SHALL extend the SD-JWT of its +attestations.

+
6.3.4.10 Specification of revocation mechanisms in the EUDI Wallet ecosystem
+

To be done.

+
6.3.4.11 Revocation validation by a Relying Party Instance
+

After obtaining an attestation from a Wallet Instance, a Relying Party +Instance SHALL verify the revocation status of the attestation. To do so, +the Relying Party Instance SHALL perform the following steps:

+
    +
  1. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the + attestation to see if it contains any revocation information. If not, + the Relying Party Instance SHALL verify that the validity period of + the attestation is equal to or less than 24 hours. If this is not the + case, the Relying Party SHALL conclude that no reliable information + regarding the revocation status of the attestation could be obtained.
    2. +
  2. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the + attestation to see if it contains Attestation Status List information. + If so, the Relying Party Instance SHALL use the inspection procedure + specified in [JWTStatusList]21 to find out the current status of + the attestation.
    3. +
  3. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the + attestation to see if it contains Attestation Revocation List + information. If so, the Relying Party Instance SHALL use the CRL + Validation process described in Section 6.3 of [RFC 5280] to verify + whether the attestation is revoked.
    4. +
  4. The Relying Party Instance SHALL inspect the response from the Wallet + Instance to see if it contains an OASP response for the attestation + (i.e., the attestation supports OASP stapling). If so, and if the + Relying Party Instance supports OASP stapling, it SHALL inspect the + OASP response as described in [RFC 6960] to find out the current + status of the attestation.
    5. +
  5. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the + attestation to see if it contains Online Attestation Status Protocol + information. If so, and if the Relying Party Instance supports OASP, + the Relying Party Instance SHALL send an OASP request 1.1.1.1to the + OASP Responder. The Relying Party Instance SHALL verify the signature + over the OASP response and SHALL inspect the OASP response as + described in [RFC 6960] to find out the current status of the + attestation.
    6. +
+

If none of these methods result in reliable information regarding the +revocation status of the attestation, it is up to the Relying Party to +take a decision on acceptance or refusal of the attestation. A Relying +Party SHALL perform a risk analysis to support this decision and SHALL +consider all relevant factors for the use case.

+

7 Specifications for Wallet Solutions

+

The reference architecture represents a set of choices made during the +architecture design process for EUDI Wallet Solutions. These choices were +informed by the need for EUDI Wallet Solutions to support various +scenarios where either the User or the Relying Party, or both, are +offline while providing flexibility for Member States to implement an +EUDI Wallet Solution in various configurations of components

+

7.1 Design considerations

+

To limit complexity, the initial EUDI Wallet Solution specifications will +include only a minimum number of solution components that enable the use +of the EUDI Wallet Instance for identification of the User, so that it +can function as an eID means.

+

The choices herein are neither a reflection of relative importance nor a +long-term commitment. Instead, the selection was guided by factors such +as the availability and maturity of standards and specifications, an +estimation of ease of adoption, and how much flexibility (in terms of use +cases enabled) is afforded by each solution component.

+

The solution components proposed herein evidence the current expectation +of using the ISO/IEC 23220 standard series, once publicly available, for +future ARF versions.

+

7.2 Architecture components

+

The following components have been identified as the building blocks of +the EUDI Wallet architecture needed to implement an EUDI Wallet +Solution:

+
    +
  • +

    Cryptographic keys management system. This component is + responsible to manage and store cryptographic information like the + private keys generated for instance during the PID issuance process.

    +
    • +
  • +

    Attestation exchange Protocol. This protocol defines how to + request and present the PID and the (Q)EAA in a secure and privacy + preserving fashion. The protocol also defines how authentication is + performed between the Relying Party and the EUDI Wallet Instance, in + particular the mechanism through which the Relying Party can request + identification through the EUDI Wallet. The request contains all the + required information about the Relying Party and the requested data. + Trust negotiation and mutual authentication are addressed by this + protocol.

    +
    • +
  • +

    Issuance Protocol. The protocol defines how PID and (Q)EAA SHOULD + be issued and in which formats.

    +
    • +
  • +

    Data model. The data model defines and describes the data elements + and how they interact with each other and their properties.

    +
    • +
  • +

    PID and (Q)EAA schemas. The attestation schema contains the + structure and the logical organisation of the data that define the + properties of the attestation, the attributes of the User. The + attestation schema also contains additional information including, but + not limited to, the verification mechanisms, the underlying identity + assurance, and Trust Framework to which the properties are related, + and the proof of possession by the legitimate User.

    +
    • +
  • +

    PID and (Q)EAA formats. PID and (Q)EAA formats are used to + represent the characteristic, quality, right or permission of a + natural or legal person or of an object, in the form of signed and + verifiable digital artifacts, containing any additional properties for + interoperability purposes.

    +
    • +
  • +

    Signature formats. Technical implementation of one or more + mathematical methods in the form of a digital artifact, aimed at + demonstrating the authenticity of a digital document, its integrity, + authenticating the author of a document and optionally also its + recipient (audience of the document).

    +
    • +
  • +

    Trust Model. Collection of rules that ensure the legitimacy of the + components and the entities involved in the EUDI Wallet + infrastructure, covering:

    +
    • +
  • User authentication.
    • +
  • Providers identification.
    • +
  • Providers registration.
    • +
  • Recognised data models and schemas.
    • +
  • Relying Parties' registration and authentication.
    • +
  • Mechanisms to establish the trust in a cross-domain scenario.
    • +
+
+

Trust Model components enable the identification of the entities that +rely on the EUDI Wallet and are instrumental for the authenticity, +confidentiality, integrity, and non-repudiation of the information. +Different Trust Models are available based on different rules.

+

Trusted List is a mechanism under a Trust Model to publish and obtain +information about authoritative parties, e.g., Providers of PID, (Q)EAA +and Relying Parties.

+
+
    +
  • +

    Cryptographic suites and mechanisms. Algorithms and methods that + secure the data exchange in terms of confidentiality and integrity.

    +
    • +
  • +

    Entity identifiers. Unique identifiers for all the elements of the + data model.

    +
    • +
  • +

    Validity status check. Mechanism to publish and obtain information + about validity status of, inter alia, PID, (Q)EAA, certificate, etc.

    +
    • +
+

7.3 Logical architecture

+

Where an EUDI Wallet Solution has an application running on a mobile +device, there may be a need for additional trusted components which are +not part of that application but are nevertheless logically part of the +EUDI Wallet. Such a need may arise for various reasons:

+
    +
  • Security: e.g., if a particular device does not have sufficiently + secure hardware like a secure element, external hardware components + like smartcards may be needed .
    • +
  • Re-use of backend systems.
    • +
  • Re-use of decentralised identity infrastructure.
    • +
+

These trusted components may be: external trusted storage, external or +embedded trusted hardware or other remote EUDI Wallets components. Below +is a conceptual representation of variations in implementing the EUDI +Wallet components:

+

Figure 6: EUDI Wallet configurations conceptual model

+ + +

Figure 6: EUDI Wallet logical architecture

+

The table below maps the EUDI Wallet components with the conceptual +model in Figure 6 above.

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Functional block in the conceptual model

+		 +

Applicable EUDI Wallet Solution components

+
+

EUDI Wallet Secure Cryptographic Device (WSCD)

+		 +

User Keys & Certificates

+
+

Secure and isolated environment for keys and data

+
+

Cryptographic algorithms (e.g., symmetric, asymmetric key derivation, +hash functions, random number generation) and protocols (e.g., ECDH, +TLS).

+
+

HW-defined secure environment for keys and data: a secure Elements +(SE), Trusted Execution Environments (TEEs), Hardware Security Module +(HSM) etc. (remote or local)

+
+

Authentication data (PIN, biometrics)

+
+

EUDI Wallet Data Storage Components

+
+

User unique identifier(as persistent as possible in time)

+
+

User attributes

+
+

User personal data and attributes

+
+

Secure environment for keys and data

+
+

EUDI Wallet "PID/EAA Presentation" Creation Application (WCA)

+		 +

Logs, history of EUDI Wallet Instance operations, telemetry

+
+

EUDI Wallet Instance application identifier (e.g., configuration, +manufacturer, and version)

+
+

Internal EUDI Wallet Instance interfaces (e.g., between storage, +components, encryption)

+
+

EUDI Wallet Driving Application (WDA)

+		 +

Logs, history of EUDI Wallet Instance operations, telemetry

+
+

EUDI Wallet Instance application identifier (e.g., configuration, +manufacturer, and version)

+
+

EUDI Wallet User interface

+
+

Relying Party interface

+		 +

EUDI Wallet interface to (Q)TSP, (Q)EAA providers, Member States +Infrastructures, National e-ID, Relying Parties, and other sources of +EEAs

+

Communication channels (online/offline) between the EUDI Wallet and +other parties

+
+ +

Table 5 - Mapping between EUDI Wallet components and conceptual model +functional blocks

+

The table below maps the EUDI Wallet components to the two perimeters +represented in Figure 6.

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
PerimetersApplicable EUDI Wallet Solution Components
Potential trusted components perimeters +

Device Information (type, configuration, firmware version, status, +etc)

+
+

System Keys & Certificates

+
+

Back-end systems (Database servers)

+
+

Trusted Connected devices

+
Potential mobile perimeter +

Device Information (type, configuration, firmware version, status, +etc)

+
+

Smartphone sensors: camera, NFC reader, fingerprint sensor, +accelerometer etc.

+
+ +

Table 6: mapping of the EUDI Wallet components to perimeters

+

Figure 7. EUDI Wallet configurations.

+ + +

Figure 7. EUDI Wallet configurations.

+

7.4 Types of flows

+

This section describes the four types of flows that the EUDI Wallet SHALL +support on a general level. The four flows are as follows:

+
    +
  1. Proximity supervised flow.
    2. +
  2. Proximity unsupervised flow.
    3. +
  3. Remote cross-device flow.
    4. +
  4. Remote same-device flow.
    5. +
+

Flows 1 and 2 are related to a scenario where the EUDI Wallet User is +physically close to a Relying Party and the attestation exchange and +disclosure (PID and/or QEAA) happens using proximity protocols (NFC, +Bluetooth, QR-Code, etc.), without the User having internet connectivity +(note that this does not imply that any other function aside from +transport is possible offline). The two proximity flows differ in one +important way. In the supervised flow, the EUDI Wallet presents +verifiable attributes to, or under supervision of, a human acting as a +Relying Party (who may operate a device of their own). In the +unsupervised flow, the EUDI Wallet presents verifiable attributes to a +machine without human supervision.

+

Flows 3 and 4 are related to a scenario where data exchange happens over +the Internet. The two remote flows differ in one important way. In the +remote cross-device flow, the EUDI Wallet User consumes information from +the service on another device than the EUDI Wallet device, which is only +used to secure the session (for instance using the EUDI Wallet to scan a +QR code on a login page to access a bank account on their web browser). +In contrast, in the remote same-device flow, the EUDI Wallet User uses +the EUDI Wallet device both for securing the session and to consume the +information from the service.

+

The User journeys will rely on at least one, and likely a combination, +of the above described four flows. Note that the four flows can be +implemented in multiple ways. The specific implementations are outside +the scope of this text.

+

Further consideration is particularly warranted with regards to the two +proximity flows as these are possible with or without internet +connectivity. Possible scenarios include:

+
    +
  • the User and Relying Party are both online,
    • +
  • only the User is online,
    • +
  • only the Relying Party is online,
    • +
  • The User and the Relying Party are both offline.
    • +
+

For all the flows described above and specifically for the proximity +unsupervised flow the User authorization is a prerequisite for data +exchange.

+

The initial PID and EAA configurations are detailed next (configurations +may be added as required in the future).

+

7.5 Relying Party authentication

+

7.5.1 High-Level requirements

+

To perform Relying Party authentication, the Wallet Instance needs to +check and validate the module entity with which it communicates, which is +called a "Relying Party Instance". There could be multiple Relying Party +Instances for each Relying Party. Let's take for example a Relying Party +called the "Traffic Police", which is represented by numerous policemen +stationed along the highways and in the cities, each policeman carrying a +hand-held Relying Party device and a suitable application, that has the +capability to authenticate the Traffic Police to a User holding a Wallet +Instance and an mDL stored inside it. The concept of a Relying Party +Instance is readily understood in this proximity scenario.

+

The same could be visualized for the remote scenarios. Let's take for +example the Tax Authority as a Relying Party that wants to communicate +with Wallet Instances. To do so, the Tax Authority needs a software +module that is capable of sending ISO-compliant or SD-JWT-compliant +requests to Wallet Instances, and to receive (and possibly process) the +responses. The Tax Authority can have one Relying Party Instance for all +of its activities, or alternatively, it can decide to have several +Relying Party Instances, for separate operational purposes. For example, +it could have separate Relying Party Instances for different geographical +regions, or one Relying Party Instance for natural persons' Wallet +Instances and a separate Relying Party Instance for legal persons' Wallet +Instances. In each use case, a User will authenticate the relevant +Relying Party Instance that has contacted him during the session.

+

When a Relying Party requests a User to release some attributes from +their Wallet Instance, the User SHALL be able to trust that they are +dealing with an identified and authenticated Relying Party. Additionally, +the User SHALL be able to trust that the request from the Relying party +was not copied and replayed.

+

To allow this, the following is required:

+
    +
  • The Wallet Instance used by a User, as well as the Relying Party + Instance used by the Relying Party, SHALL implement a mechanism for + Relying Party authentication.
    • +
  • A Wallet Instance and a Relying Party Instance SHALL perform Relying + Party authentication in all use cases, whether proximity or remote.
    • +
+

Note: This requirement was discussed and there were different opinions +about the need to authenticate the Relying Party in each of the scenarios +– proximity or remote. The goal of this requirement is to secure the +users of the EUDI wallets in any transaction they are involved in, from +any risk of false authentication - without exceptions.

+

Note: This recommendation stems from realizing that strict requirements +to use HSMs for all relying parties will not be practical to enforce and +will limit the usage of the wallets in cases where this high-level +security is not necessary.

+
    +
  • The Wallet Instance SHALL keep a record of the communication with the + Relying Party (as per article 6a(3.ae) [eIDAS 2.0].
    • +
+

7.5.2 General Relying Party authentication mechanism

+

In essence, a Relying Party authentication mechanism works as follows:

+
    +
  1. The Relying Party Instance SHALL create a signature over some data in + the protocol for the request, using a Relying Party Instance private + key.
    2. +
  2. The Relying Party Instance SHALL include its certificate22 (and all + other certificates in the trust chain leading up to its trust anchor) + associated with the private key in the request. The certificate SHALL + be signed (directly or indirectly) by a Certification Authority, whose + certificate is present in the Wallet Instance as a trust anchor.
    3. +
  3. The Wallet Instance SHALL verify the signature over the request using + the Relying Party Instance public key.
    4. +
  4. The Wallet Instance SHALL verify that the signature of the + Certification Authority over the Relying Party Instance certificate - + and all other certificates in the trust chain leading up the trust + anchor - is correct.
    5. +
  5. The Wallet Instance SHALL validate that the CA that issued the + certificate for the Relying Party Instance, did not revoke since then + the certificate of the Relying Party Instance, or any other + certificate in the trust chain leading up to its trust anchor).
    6. +
+

Below is a high-level sequence diagram for Relying Party Authentication, +independent of the protocol beneath for retrieving the attestations;

+

Figure 8. High-level sequence diagram for Relying Party Authentication. +Figure 8. High-level sequence diagram for Relying Party Authentication

+

Section 7.5.8 specifies in detail how Relying Party authentication SHALL be implemented by ISO-compliant Wallet Instances and Relying Party Instances. Section 7.5.9 describes the same for SD-JWT-compliant Wallet Instances and Relying Party Instances.

+

7.5.3 Relying Party authentication mechanisms

+

As explained above, for the authentication process, each Relying Party +Instance SHALL have a unique Relying Party Instance certificate. This +certificate SHALL be signed (directly or indirectly) by a Relying Party +root Certificate Authority.

+

To obtain certificates for its Relying Party Instances, each Relying +Party SHALL therefore register itself and after going through this +process successfully, a registered Relying Party SHALL obtain the Relying +Party Instance certificates it needs for all of its Relying Party +Instances.

+

During the authentication of a Relying Party Instance, it is necessary to +validate the certificate of that Relying Party Instance, and the whole +chain of trust up to the anchor of trust.

+

7.5.4 Relying Party authentication trust infrastructure

+

Within the EUDI Wallet ecosystem, Relying Party Instance certificates +SHALL be signed by a Certification Authority. Each CA in the trust chain +SHALL employ operational and security practices that are sufficient to +guarantee the trustworthiness of the certificates it issues. Each CA +SHALL document these operational and security practices in a Certificate +Policy complying with [EN 319 411].

+

7.5.5 A risk-based approach to Relying Party authentication failures

+

This section outlines a risk analysis for each failure reason and proposes an action for the Wallet Instance. If Relying Party authentication fails for any reason, the Wallet Instance SHALL NOT release the requested attributes to the Relying Party when failures listed below occur.

+

There are quite a few reasons for which a Relying Party authentication mechanism as described in section 7.5.2 can fail or indicate a MITM attack. This document categorizes these reasons in the following manner:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
No.Reason for failureAssociated risk
1The Relying Party request does not contain a signature created by the Relying Party Instance.If the request does not contain a Relying Party Instance signature, most probably the Relying Party did not yet register itself and the Relying Party Instance does have a Relying Party Instance key pair and/or an associated Relying Party Instance certificate. This does not imply that the Relying Party is untrustworthy. In fact, it will probably take a long time after the start of the EUDI Wallet ecosystem before most Relying Parties are registered, and we may never reach a point where 100% of all Relying Parties are registered. If this error occurs, the Wallet Instance SHALL NOT release any attributes to the Relying Party.
2The Relying Party signature is wrong.In this case, the Relying Party Instance signed the wrong data, for example data that does not represent the requested attributes. Alternatively, to create the signature, the Relying Party Instance used a private key not corresponding to the public key in the Relying Party Instance certificate. In both cases, there is a real risk that a Man-In-The-Middle attack is going on or that a fake Relying Party Instance attempts to use another Relying Party certificate. If this error occurs, the Wallet Instance SHALL NOT release any attributes to the Relying Party.
3The signature over the Relying Party Instance certificate (or any of the other CA certificates in the trust chain) is wrong.If the signature over the Relying Party Instance certificate or any of the other CA certificates in the trust chain is wrong, there is a real risk that the Relying Party attempted to create its own (fake) certificate or other CA. If this error occurs, the Wallet Instance SHALL NOT release any attributes to the Relying Party.
4The Wallet Instance does not contain the trust anchor indicated in the Relying Party Instance certificate (or in a higher-level CA certificate, if a multiple-level PKI is used).If the Wallet Instance does not contain the trust anchor indicated in the certificate, several things can have gone wrong. Perhaps the Relying Party authentication CA changed its key pair recently, and the Wallet Instance did not update its trust anchors yet. However, there is also a possibility that the Relying Party attempted to create its own fake CA. Therefore, if this error occurs, the Wallet Instance SHOULD attempt to update its trust anchors. If that is not possible, or the problem persists, the Wallet Instance SHALL NOT release any attributes to the Relying Party.
5The Relying Party Instance certificate (or any of the other CA certificates in the trust chain) has expired.If the Relying Party Instance certificate, or any of the other CA certificates in the trust chain has expired, the problem is most likely due to an omission by the Relying Party to timely update its certificates. This does not imply that the Relying Party is untrustworthy, but the Wallet Instance SHALL NOT release any attributes to the Relying Party.
6The Relying Party Instance certificate (or any of the other CA certificates in the trust chain) has been revoked.If the Relying Party Instance certificate or any of the other CA certificates in the trust chain, has been revoked, this means that the issuer of that certificate has concluded that the certificate cannot be trusted anymore and has actively taken measures to prevent that Wallet Instances from using this certificate. If this error occurs, the Wallet Instance SHALL NOT release any attributes to the Relying Party.
+

Note: A more detailed risk analysis may be performed on this section if +deemed necessary.

+

7.5.6 Relying Party authentication Wallet-to-Wallet communication

+

To be done.

+

7.5.7 Informing the User about Relying Party authentication outcomes

+

The Wallet Instance SHALL inform the User about the outcome of Relying +Party authentication. This document does not contain detailed guidance +for how the Wallet Instance must do this. However, it requires that,

+
    +
  • If Relying Party authentication succeeds, then the Wallet Instance + SHALL show the name in the Relying Party name extension of the Relying + Party Instance certificate (see 7.5.8.2) to the User. The Wallet + Instance can do this when asking for User approval (see section 7.7). + For example, the Wallet Instance MAY use a phrase like ' asks for the following: . Do you + agree?" This is only an example of a response.
    • +
  • If Relying Party authentication fails, the Wallet Instance SHALL inform + the User. For example, the Wallet Instance MAY use a phrase like "A + party claiming to be '' is asking for data. This + party is untrusted. For your security, the transaction will be + cancelled."
    • +
+

Additionally, if Relying Party authentication fails, the Wallet Instance +MAY inform the User about the reason for failure

+

7.5.8 Relying Party authentication mechanism for ISO/IEC 18013-5 compliant Wallet Instances

+
7.5.8.1 Implementation notes
+

Relying Party Instances interacting with an ISO/IEC 18013-5-compliant +Wallet Instance SHALL implement the general Relying Party authentication +mechanism outlined in section 7.5.2 as follows:

+
    +
  1. For step 1, a Relying Party Instance SHALL implement mdoc reader + authentication as specified in [ISO/IEC 18013-5]. Using this + mechanism, the Relying Party Instance signs contextual information in + the request (called the SessionTranscript), which includes the Wallet + Instance ephemeral public key for session encryption.
    2. +
  2. Regarding step 2, the public key of the Relying Party Instance + interacting with an ISO-compliant Wallet Instance SHALL be included in + a Relying Party Instance certificate. [ISO/IEC 18013-5] specifies the + format of this certificate under the name of mdoc reader + authentication certificate. However, for use within the EUDI Wallet + ecosystem, there is a need for additional information in the Relying + Party Instance certificate. The format of the ISO-compliant Relying + Party Instance certificate to be used within the EUDI Wallet ecosystem + is specified in section 7.5.8.2.
    3. +
  3. For step 3, the Wallet Instance SHALL validate the signature of the + Relying Party Instance over the data in the request in the manner + specified for mdoc reader authentication in [ISO/IEC 18013-5].
    4. +
  4. For step 4, the Wallet Instance SHALL validate the Relying Party + Instance certificate and all other CA certificates in the trust chain, + if any. The Wallet Instance SHALL use the method specified in clause + 9.3.3 of ISO/IEC 18013-5. To enable this, each Wallet Instance SHALL + contain one or more Relying Party authentication root CA public keys + as a trust anchor for Relying Party authentication. These public keys + SHALL be distributed in the form of root certificates, which SHALL + have the format specified in section 7.5.8.3. Comment: Both steps 3 + and 4 are required, even though they MAY be implemented in a different + order, that is – first the trust chain will be validated (step 4) and + afterwards the signature will be validated (step 3).
    5. +
  5. For step 5, if the Relying Party Instance requests the release of a + Relying Party-specific pseudonym for the User, the Wallet Instance + SHALL use the Relying Party unique ID from the Relying Party Instance + certificate to derive the pseudonym (or identify it if the Wallet + Instance already has a pseudonym for this Relying Party). If the + Relying Party unique ID is not present in the certificate, the Wallet + Instance SHALL NOT release a Relying Party -specific pseudonym.
    6. +
  6. For step 6, the Wallet Instance SHALL verify that the Relying Party + authentication root CA did not revoke the Relying Party Instance + certificate or any other CA certificates in the trust chain. To do + this, it SHALL use the CRL distribution point or OCSP access location + indicated in the certificate.
    7. +
+
7.5.8.2 Relying Party Instance certificate format
+

The Relying Party Instance certificate format SHALL comply with the +requirements for mdoc reader authentication certificates in Appendix +B.1.7 of [ISO/IEC18013-5], with the following exceptions:

+
    +
  • The OID to be used for a Relying Party Instance dedicated to a specific + attestation (see section 7.5.3) SHALL be specified in the applicable + Rule Book.
    • +
  • As discussed in [PseudonymRulebook], a Relying Party MAY request a + Wallet Instance for an Relying Party-specific pseudonym. To be able to + do so, the Wallet Instance needs a unique and persistent identifier for + the Relying Party. Therefore, if an Relying Party wants to use an + Relying Party-specific pseudonym, it SHALL ensure that its Relying + Party Instance certificates contain a relying party unique ID + extension.
    • +
  • The Relying Party Instance certificate SHALL contain the legal name for + the Relying Party in the subject's Common Name, which the Wallet + Instance can show to the User when asking for User approval, see + section 7.6.1. The Relying Party Instance certificate MAY contain a + Relying Party name extension that further defines the Relying Party + service that, if existent, will also be shown to the User.
    • +
+
7.5.8.3 Relying Party authentication root CA certificate format
+

The Relying Party authentication root CA certificate format SHALL comply +with the requirements for Issuing Authority CA certificates in Appendix +B.1.2 of [ISO/IEC18013-5], with the following exceptions:

+
    +
  • The validity period of this certificate SHALL be 5 years maximum.
    • +
  • For the Provider field, the requirements regarding the issuing_country + data element (for countryName) and the issuing_jurisdiction data + element (for stateOrProvinceName) SHALL be disregarded. Where the + issuing country is mentioned, this SHALL be taken to refer to the + country in which the Relying Party authentication root CA is + established. 
    • +
+

7.5.9 Relying Party authentication mechanism for SD-JWT-compliant Wallet Instances

+

To be done.

+

7.6 Relying Party authorization

+

There is a risk that relying parties may over-ask, i.e., ask a Wallet +instance for more attributes than the Relying Party reasonably needs for +its use case. This is obviously a risk for the privacy of the user, and +this risk must be mitigated. At least three approaches can in principle +be used to protect the user against over-asking: the user approval +mechanism discussed in Chapter 4, technical measures in the Wallet +Instance, and legal and organizational measures on Member State or EU +level.

+

7.6.1 User approval as a means for Relying Party authorization

+

User Approval protects against over-asking by allowing the User to refuse +sharing attributes that they deem unnecessary for the specific use case +and the specific Relying Party they are dealing with.

+

User approval SHALL be implemented in all use cases.

+

However, User Approval has some limitations that MAY make it +insufficiently effective in preventing Relying Parties from over-asking, +as described below:

+
    +
  • Firstly, it makes the User solely responsible for verifying (and + preventing) that the Relying Party does not misbehave. This puts a + heavy burden on the User's level of knowledge and awareness. For + example, if a Relying Party present the release of all requested + attributes as a precondition for the use case that is going on, a User + may not have the resources to determine whether this is indeed the + case, or to judge the impact of sharing attributes that the Relying + Party does not actually need. Moreover, Users will be tempted to + release all requested attributes, just to ensure they can enjoy the + benefits of the use case.
    • +
  • Secondly, although User Approval may prevent a misbehaving Relying + Party from over-asking in individual cases, it does not provide + authorities with a means to solve disagreements between User and + Relying Party as to what attributes can be reasonably requested, and + neither does it allow authorities to detect and penalize Relying + Parties that over-ask.
    • +
+

7.7 User approval

+

In this document the term 'User approval' exclusively refers to a User's +decision to release an attribute to the Relying Party requesting it. +Under no circumstances User approval to releasing data from their EUDI +Wallet Instance SHOULD be construed as lawful grounds for the processing +of personal data by the Relying Party or any other party. Relying Party +or any party requesting or processing personal data from a EUDI Wallet +Instance SHALL ensure that they have grounds for lawful processing that +data, according to Article 6 of the GDPR.

+

7.7.1 Overview

+

User approval refers to a decision by a User to release one or more +attributes to a Relying Party that is requesting these attributes. This +document requires the following:

+
    +
  1. A Wallet Instance SHALL always ask the User to approve any release of + an attribute in the Wallet Instance to any Relying Party.
    2. +
  2. A Wallet Instance SHALL authenticate the User before allowing the User + to give or refuse approval.
    3. +
  3. A Relying Party SHALL be able to distinguish between attributes that + are critical for its use case, and those that are optional. If so, a + Wallet Instance SHALL ensure that the User approval for critical + attributes is granted on an 'all or nothing' basis. For optional + attributes, User approval is granted per attribute.
    4. +
+

These requirements are explained in more detail in the next subsections. +This document does not specify any further details on how Wallet +Providers SHALL implement a User's approval mechanism.

+

7.7.2 Asking for User approval

+

A Wallet Instance SHALL always ask the User to give approval for any +attribute released. This goes for any use case, both in proximity and +remote, and including:

+
    +
  • Use cases where the Relying Party could be assumed to be trusted, for + example when the Relying Party is part of law enforcement or another + government agency.
    • +
  • Use cases where the requested attributes are critical for the Relying + Party to grant access to the User or deliver the requested services.
    • +
  • Use cases where there is, according to the GDPR or other legislation, + no (legal) need to ask for the User's approval because another legal + basis exists for requesting the attributes.
    • +
+

This principle is a basic protection of the User's privacy. It also +ensures a consistent User experience. Moreover, this principle means that +the level of control Users have over their attributes is not less than in +the existing 'plastic-card based' situation. That is, a User SHALL always +be able to refuse presenting an attribute that is requested by a Relying +Party, even when knowing that the consequence of that refusal may have +negative consequences for the User.

+

Note: Attributes that the Relying Party intends to store is regulated +GDPR. This feature is seen as preference known in ISO as "intent to +retain" and is included in the ARF as "privacy by design" element.

+

7.7.3 User authentication and User approval

+

A Wallet Instance SHALL authenticate the User before allowing the User to +approve the request. This means that the Wallet Instance SHALL verify +that the person handling the Wallet Instance and approves the request is +the User, i.e., the person to whom the attributes in the attestation +apply. If this is not the case, then the person handling the Wallet +Instance is legally not allowed to approve to release the attributes.

+

Note that this requirement is slightly different from the requirement of +User binding discussed in section 6.3.2.5 of [TrustModel]. In some use +cases, for example in attended proximity use cases, the Relying Party can +use a portrait of the User to do User binding, if that portrait is issued +as an attribute in an attestation. Obviously, this is not a possibility +for a Wallet Instance.

+

Wallet Instances therefore have no choice but to trust the User +authentication mechanisms present on or connected to the device on which +the Wallet Instance is installed. The discussions in the third bullet of +section 6.3.2.5 therefore apply for User authentication by the Wallet +Instance as well.

+

Note that use cases in which the User and the subject of the attributes +are two different persons, such as when somebody has power of attorney or +custodianship, are out of scope of this version of this document.

+

8 The Certification process of EUDI Wallets Solutions

+

Member States, according to Article 6c (3) of the proposal, SHALL +designate accredited CABs which will oversee carrying out conformity +assessment of EUDI Wallets Solutions. This designation process should be +harmonised between Member States.

+

Once this designation has been made, Member States SHALL communicate to +the European Commission the names and addresses of these public or +private bodies under Article 6c(5) of the proposal.

+

EUDI Wallet Provider SHALL request (select, contract) one or more +designated CABs to assess and certify the conformity of their EUDI Wallet +Solution against the requirements of the eIDAS Regulation.

+

EUDI Wallet certification is conducted by the CAB to evaluate and certify +the conformity of the EUDI Wallet Solution (target of the certification) +against normative document(s) which will be the Art. 6a(11) implementing +act(s) on technical and operational specifications and reference +standards. The EUDI Wallet SHALL be certified to ensure conformity +assessments but also security robustness assessment of conformance to a +high level of security.

+

The use of a cybersecurity certification scheme should bring a harmonised +level of trust in the security of EUDI Wallet Solution. The secure +storage of cryptographic material is expected to become subject to +cybersecurity certification too.

+

The Certification process of EUDI Wallet Providers should leverage, rely +on, and mandate the use of relevant and existing Cybersecurity Act +certification schemes, or parts thereof, to certify the compliance of +wallets, or parts thereof, with the applicable cybersecurity +requirements.

+

9 The Architecture and Reference Framework Development Process

+

9.1 Publication

+

This document and the backlog items are made publicly available at +the EU Digital Identity Wallet repository in GitHub, where it will be regularly updated according to the workflow described +in Chapter 9.2.

+ +

9.2 Update

+

To ensure steady and fast progress on elaborating and updating this +document, the following process and work methodology is applied.

+

The eIDAS Expert Group SHOULD maintain a backlog, which is a prioritised +list of work items to complete the ARF. The backlog will be updated based +on feedback from the eIDAS Expert Group, LSPs, the Commission or other +stakeholders such as international standardisation organisations. For +instance, feedback from the development of the reference implementation +of an EUDI Wallet and ensuing drafts of detailed technical specifications +may prompt new work items.

+

The European Commission (DG CONNECT) will organise the work on the +backlog items and will facilitate that work is progressing according to +the expected timeline.

+

The eIDAS Expert Group will regularly discuss and compare different +proposals regarding technical solutions, recommendations and requirements +related to the relevant backlog issue with a view of updating the ARF. +The eIDAS Expert Group SHALL in this regard maintain a list of +Architecture Decision Records (ADRs), so that it is possible to keep +track of and understand the motivation behind technical decisions +described in the ARF.

+

Any changes and/or updates to this document SHALL be agreed by the eIDAS +Expert Group. The eIDAS Expert Group will convene in regular meetings, +with the objective to discuss and approve new release of this document, +as well as updating the development backlog.

+

This document will be aligned to the outcome of the legislative +negotiations of the proposal for a European Digital Identity Framework +with updates being made accordingly.

+

9.2.1 Document versioning

+

To avoid interoperability issues and changes to the ARF going unnoticed, +version control system and the following semantic versioning scheme will +be used for the ARF.

+

The ARF document will have a given version number following the format +MAJOR.MINOR.PATCH, where:

+

MAJOR version is incremented (i.e., new version), when the ARF +document has undergone significant changes, for example introducing some +breaking changes in the architecture,

+

MINOR version is incremented when new information has been added to +the document or information has been removed from the document, and

+

PATCH version is incremented when minor changes have been made +(e.g., fixing typos).

+

10 References

+

[2015/1505] COMMISSION IMPLEMENTING DECISION (EU) 2015/1505 +of 8 September 2015 laying down technical specifications and formats relating to trusted lists pursuant to Article 22(5) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market

+

[RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997

+

[Key words for use in ARF to indicate requirement levels] +https://www.rfc-editor.org/rfc/rfc2119

+

[ISO/IEC 18013-5] https://www.iso.org/standard/69084.html

+

[ISO/IEC AWI TS 23220-4] https://www.iso.org/standard/79126.html

+

[W3C-VC-DATA-MODEL] Sporny, M., Noble, G., Longley, D., Burnett, D. +C., Zundel, B., and D. Chadwick, "Verifiable Credentials Data Model +1.0", 19 November 2019, \<https://www.w3.org/TR/vc-data-model>.

+

[OpenID4VP] Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. +Looker, "OpenID for Verifiable Presentations", 30 December 2022, +https://openid.net/specs/openid-4-verifiable-presentations-1_0.html

+

[OpenID4VCI] Lodderstedt, T., Yasuda, K., and T. Looker, OpenID for Verifiable Presentations – draft 18, 21 April 202323 Retrievable from OpenID for Verifiable Credential Issuance - draft 12

+

[Prop_eIDAS] COM(2021) 281 final

+

[SIOPv2] K. Yasuda, T. Lodderstedt, M. Jones, "Self-Issued OpenID Provider V2", 1 January 2023, https://openid.net/specs/openid-connect-self-issued-v2-1_0.html

+

[DP_Revoc] eIDAS Expert Group WG1 Discussion Paper Revocation for PID and (Q)EAA, v.1.0

+

[SD-JWT] Selective Disclosure for JWTs (SD-JWT) draft-ietf-oauth-selective-disclosure-jwt 04, 11 April 202324

+

[W3C StatusList2021] https://w3c-ccg.github.io/vc-status-list-2021/

+

[COSE] RFC9052 https://www.rfc-editor.org/rfc/rfc9052,
+RFC9053 https://www.rfc-editor.org/rfc/rfc9053

+

[JOSE] RFC7515 https://www.rfc-editor.org/rfc/rfc7515.html,
+RFC7516 https://www.rfc-editor.org/rfc/rfc7516.html,
+RFC7517 https://www.rfc-editor.org/rfc/rfc7517.html,
+RFC7518 https://www.rfc-editor.org/rfc/rfc7518.html

+

[SOG-IS] Agreed Cryptographic Mechanisms v1.2 +https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf

+

[JSON-LD] JSON-LD 1.1 Manu Sporny, Dave Longley, Gregg Kellogg, Markus +Lanthaler, Pierre-Antoine Champin, Niklas Lindström, +https://www.w3.org/TR/json-ld/

+

A.1 Annex 01 - initialisation and activation

+

The service blueprint about initialisation and activation of the Wallet +is described in the attached file:

+ +

A.2 Annex 02 – online identification and authentication

+

The service blueprint about online identification and authentication for +the Wallet is described in the attached file:

+ +

A.3 Annex 03 – issuing mDL

+

The service blueprint about issuing mDL is described in the attached +file:

+ +

A.4 Annex 04 – presenting mDL (proximity-supervised)

+

The service blueprint about presenting mDL (proximity-supervised) is +described in the attached file:

+ +

A.5 Annex 05 – presenting mDL (proximity-unsupervised)

+

The service blueprint about presenting mDL (proximity-unsupervised) is +described in the attached file: +* Annex 05 – EUDI Wallet – presenting mDL (proximity-unsupervised).pdf

+

A.6 Annex 06 – PID rulebook

+

The PID attribute schema, indicative EUDI Wallet Instance Attestation +and Trust Infrastructure details are further detailed in the attached +file: +* Annex 06 – EUDI Wallet – PID rulebook.pdf

+

A.7 Annex 07 - mDL rulebook

+

The mDL attribute schema is further detailed in the attached file: +* Annex 07 – EUDI Wallet – mDL rulebook.pdf

+

A.8 Annex 08 - Design Guide

+

A first iteration of an EUDI Wallet Design Guide can be found in the attached file: +* Annex 08 – EUDI Wallet Design Guide.pdf

+

A.9 Annex 09 - Design guide data sharing scenarios

+ +
+
+
    +
  1. +

    The date of adoption by the eIDAS Expert Group. ↩

    +
    2. +
  2. +

    COMMISSION RECOMMENDATION (EU) C(2021) 3968 final of 3 June 2021 on +a common Union Toolbox for a coordinated approach towards a European +Digital Identity Framework, OJ L 210/51, 14.6.2021 ↩

    +
    3. +
  3. +

    All references in the document to the revision of the eIDAS +regulation are to be understood as a reference to the Commission's +proposal of 3 June 2021, unless otherwise indicated. Proposal for a +REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL amending +Regulation (EU) No 910/2014 as regards establishing a framework for a +European Digital Identity, COM(2021) 281 final, 3.6.2021 ↩

    +
    4. +
  4. +

    https://ec.europa.eu/transparency/expert-groups-register/screen/expert-groups/consult?lang=en&groupID=3032 ↩

    +
    5. +
  5. +

    https://futurium.ec.europa.eu/en/digital-identity/toolbox/architecture-and-reference-framework-outline ↩

    +
    6. +
  6. +

    All references in the document to the revision of the eIDAS +Regulation are to be understood as a reference to the Commission's +proposal of 3 June 2021, unless otherwise indicated. ↩

    +
    7. +
  7. +

    "OASIS Trust," [Online]. Available: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html. ↩

    +
    8. +
  8. +

    Regarding registration of Relying Pary entities, please refer to +epic 27 that deals with Relying Party Registry. Also, under no +circumstances, Police Relying Party Instances should not be open to +the general public ↩

    +
    9. +
  9. +

    Communication from the Commission to the European Parliament, the +Council, the European Economic and Social Committee and the +Committee of the Regions on a Retail Payments Strategy for the EU +COM/2020/592 final. ↩

    +
    10. +
  10. +

    Without prejudice to the actual mechanism of how the information +is provided, including whether directly or indirectly. ↩

    +
    11. +
  11. +

    Further precisions to the specifics about how the trusted lists +could be implemented will be brought later. ↩

    +
    12. +
  12. +

    Article 6c (3) ↩

    +
    13. +
  13. +

    Regulation (EC) No 765/2008 of the European Parliament and of the +Council of 9 July 2008 setting out the requirements for +accreditation and market surveillance relating to the marketing of +products and repealing Regulation (EEC) No 339/93 ↩

    +
    14. +
  14. +

    Commission Implementing Regulation (EU)2015/1501 of 8 September +2015 on the interoperability framework pursuant to Article 12(8) of +Regulation (EU) No 910/2014 of the European Parliament and of the Council +on electronic identification and trust services for electronic +transactions in the internal market. ↩

    +
    15. +
  15. +

    Please note that work on further specifying the EUDI Wallet +Instance Attestation is planned to be carried out. This section may +need to be revised depending on the results of that work. For +instance, EUDI Wallet Instance Attestation may not be issued in all +cases nor are alternative possibilities excluded from consideration. ↩

    +
    16. +
  16. +

    The ARF implicitly requires device binding for the Wallet Instance +(by requiring support for ISO/IEC 18013-5 and SD-JWT) ↩

    +
    17. +
  17. +

    Preferably the same Issuer that also signed the other attributes +that were released. However, the combined presentation of attributes +originating from different attestations will be further detailed in +a future version of this document. ↩

    +
    18. +
  18. +

    Note that this implies that Relying Parties SHALL also trust +device binding, see section 6.2.3.4. The Relying Party trusts that +the attestation is bound to a device trusted by the Provider, and +subsequently trusts that this device has properly authenticated the +User. ↩

    +
    19. +
  19. +

    A PID MAY be an exception: because the concept of a PID is new, it +is not known yet what validity period PID Providers will use for +their PIDs, and if there will be a difference between the +administrative validity period as seen by the User and the +cryptographic validity period of the attestation. ↩

    +
    20. +
  20. +

    In this case, an alternative to revocation is that the pharmacy +backend marks the prescription as used, and all pharmacies check that +backend before handing out the medicines. This goes in fact for any +attestation: if there is a backend system that allows Relying Parties +to verify whether the attestation is still usable, then revocation is +not needed. However, we cannot assume that such a backend system +exists for all attestations that can be ‘consumed’, i.e., that must +become unusable once they have been used. ↩

    +
    21. +
  21. +

    The current version of [JWTStatusList] does not explicitly +describe such a procedure. The EC will point out to the authors that +this should be added. ↩

    +
    22. +
  22. +

    Please note that the term "certificate" does not mean only X.509 +certificates, but it includes also other formats of certificates, +such as in Distributed Ledgers. ↩

    +
    23. +
  23. +

    The exact version to be referenced is to be determined. [ARF] +references v0.14 of 30 December 2022. Draft 18 is the latest version +available at the time of writing of this document. The level of +interoperability between these versions is not known. As [OpenID4VP] +is still under development, presumably later versions will become +available over time. ↩

    +
    24. +
  24. +

    The exact version to be referenced is to be determined. Draft 18 +the latest version available at the time of writing of this document. +The level of interoperability between these versions is not known. As +[SD-JWT] is still under development, presumably later versions may +become available over time. ↩

    +
    25. +
+
+ + + + + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/1.3.0/assets/images/favicon.png b/1.3.0/assets/images/favicon.png new file mode 100644 index 0000000..1cf13b9 Binary files /dev/null and b/1.3.0/assets/images/favicon.png differ diff --git a/1.3.0/assets/javascripts/bundle.c8d2eff1.min.js b/1.3.0/assets/javascripts/bundle.c8d2eff1.min.js new file mode 100644 index 0000000..4b1b31f --- /dev/null +++ b/1.3.0/assets/javascripts/bundle.c8d2eff1.min.js @@ -0,0 +1,29 @@ +"use strict";(()=>{var _i=Object.create;var br=Object.defineProperty;var Ai=Object.getOwnPropertyDescriptor;var Ci=Object.getOwnPropertyNames,Ft=Object.getOwnPropertySymbols,ki=Object.getPrototypeOf,vr=Object.prototype.hasOwnProperty,eo=Object.prototype.propertyIsEnumerable;var Zr=(e,t,r)=>t in e?br(e,t,{enumerable:!0,configurable:!0,writable:!0,value:r}):e[t]=r,F=(e,t)=>{for(var r in t||(t={}))vr.call(t,r)&&Zr(e,r,t[r]);if(Ft)for(var r of Ft(t))eo.call(t,r)&&Zr(e,r,t[r]);return e};var to=(e,t)=>{var r={};for(var o in e)vr.call(e,o)&&t.indexOf(o)<0&&(r[o]=e[o]);if(e!=null&&Ft)for(var o of Ft(e))t.indexOf(o)<0&&eo.call(e,o)&&(r[o]=e[o]);return r};var gr=(e,t)=>()=>(t||e((t={exports:{}}).exports,t),t.exports);var Hi=(e,t,r,o)=>{if(t&&typeof t=="object"||typeof t=="function")for(let n of Ci(t))!vr.call(e,n)&&n!==r&&br(e,n,{get:()=>t[n],enumerable:!(o=Ai(t,n))||o.enumerable});return e};var jt=(e,t,r)=>(r=e!=null?_i(ki(e)):{},Hi(t||!e||!e.__esModule?br(r,"default",{value:e,enumerable:!0}):r,e));var ro=(e,t,r)=>new Promise((o,n)=>{var i=c=>{try{a(r.next(c))}catch(p){n(p)}},s=c=>{try{a(r.throw(c))}catch(p){n(p)}},a=c=>c.done?o(c.value):Promise.resolve(c.value).then(i,s);a((r=r.apply(e,t)).next())});var no=gr((xr,oo)=>{(function(e,t){typeof xr=="object"&&typeof oo!="undefined"?t():typeof define=="function"&&define.amd?define(t):t()})(xr,function(){"use strict";function e(r){var o=!0,n=!1,i=null,s={text:!0,search:!0,url:!0,tel:!0,email:!0,password:!0,number:!0,date:!0,month:!0,week:!0,time:!0,datetime:!0,"datetime-local":!0};function a(C){return!!(C&&C!==document&&C.nodeName!=="HTML"&&C.nodeName!=="BODY"&&"classList"in C&&"contains"in C.classList)}function c(C){var ct=C.type,Ne=C.tagName;return!!(Ne==="INPUT"&&s[ct]&&!C.readOnly||Ne==="TEXTAREA"&&!C.readOnly||C.isContentEditable)}function p(C){C.classList.contains("focus-visible")||(C.classList.add("focus-visible"),C.setAttribute("data-focus-visible-added",""))}function l(C){C.hasAttribute("data-focus-visible-added")&&(C.classList.remove("focus-visible"),C.removeAttribute("data-focus-visible-added"))}function f(C){C.metaKey||C.altKey||C.ctrlKey||(a(r.activeElement)&&p(r.activeElement),o=!0)}function u(C){o=!1}function h(C){a(C.target)&&(o||c(C.target))&&p(C.target)}function w(C){a(C.target)&&(C.target.classList.contains("focus-visible")||C.target.hasAttribute("data-focus-visible-added"))&&(n=!0,window.clearTimeout(i),i=window.setTimeout(function(){n=!1},100),l(C.target))}function A(C){document.visibilityState==="hidden"&&(n&&(o=!0),Z())}function Z(){document.addEventListener("mousemove",J),document.addEventListener("mousedown",J),document.addEventListener("mouseup",J),document.addEventListener("pointermove",J),document.addEventListener("pointerdown",J),document.addEventListener("pointerup",J),document.addEventListener("touchmove",J),document.addEventListener("touchstart",J),document.addEventListener("touchend",J)}function te(){document.removeEventListener("mousemove",J),document.removeEventListener("mousedown",J),document.removeEventListener("mouseup",J),document.removeEventListener("pointermove",J),document.removeEventListener("pointerdown",J),document.removeEventListener("pointerup",J),document.removeEventListener("touchmove",J),document.removeEventListener("touchstart",J),document.removeEventListener("touchend",J)}function J(C){C.target.nodeName&&C.target.nodeName.toLowerCase()==="html"||(o=!1,te())}document.addEventListener("keydown",f,!0),document.addEventListener("mousedown",u,!0),document.addEventListener("pointerdown",u,!0),document.addEventListener("touchstart",u,!0),document.addEventListener("visibilitychange",A,!0),Z(),r.addEventListener("focus",h,!0),r.addEventListener("blur",w,!0),r.nodeType===Node.DOCUMENT_FRAGMENT_NODE&&r.host?r.host.setAttribute("data-js-focus-visible",""):r.nodeType===Node.DOCUMENT_NODE&&(document.documentElement.classList.add("js-focus-visible"),document.documentElement.setAttribute("data-js-focus-visible",""))}if(typeof window!="undefined"&&typeof document!="undefined"){window.applyFocusVisiblePolyfill=e;var t;try{t=new CustomEvent("focus-visible-polyfill-ready")}catch(r){t=document.createEvent("CustomEvent"),t.initCustomEvent("focus-visible-polyfill-ready",!1,!1,{})}window.dispatchEvent(t)}typeof document!="undefined"&&e(document)})});var zr=gr((kt,Vr)=>{/*! + * clipboard.js v2.0.11 + * https://clipboardjs.com/ + * + * Licensed MIT © Zeno Rocha + */(function(t,r){typeof kt=="object"&&typeof Vr=="object"?Vr.exports=r():typeof define=="function"&&define.amd?define([],r):typeof kt=="object"?kt.ClipboardJS=r():t.ClipboardJS=r()})(kt,function(){return function(){var e={686:function(o,n,i){"use strict";i.d(n,{default:function(){return Li}});var s=i(279),a=i.n(s),c=i(370),p=i.n(c),l=i(817),f=i.n(l);function u(D){try{return document.execCommand(D)}catch(M){return!1}}var h=function(M){var O=f()(M);return u("cut"),O},w=h;function A(D){var M=document.documentElement.getAttribute("dir")==="rtl",O=document.createElement("textarea");O.style.fontSize="12pt",O.style.border="0",O.style.padding="0",O.style.margin="0",O.style.position="absolute",O.style[M?"right":"left"]="-9999px";var I=window.pageYOffset||document.documentElement.scrollTop;return O.style.top="".concat(I,"px"),O.setAttribute("readonly",""),O.value=D,O}var Z=function(M,O){var I=A(M);O.container.appendChild(I);var W=f()(I);return u("copy"),I.remove(),W},te=function(M){var O=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body},I="";return typeof M=="string"?I=Z(M,O):M instanceof HTMLInputElement&&!["text","search","url","tel","password"].includes(M==null?void 0:M.type)?I=Z(M.value,O):(I=f()(M),u("copy")),I},J=te;function C(D){"@babel/helpers - typeof";return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?C=function(O){return typeof O}:C=function(O){return O&&typeof Symbol=="function"&&O.constructor===Symbol&&O!==Symbol.prototype?"symbol":typeof O},C(D)}var ct=function(){var M=arguments.length>0&&arguments[0]!==void 0?arguments[0]:{},O=M.action,I=O===void 0?"copy":O,W=M.container,K=M.target,Ce=M.text;if(I!=="copy"&&I!=="cut")throw new Error('Invalid "action" value, use either "copy" or "cut"');if(K!==void 0)if(K&&C(K)==="object"&&K.nodeType===1){if(I==="copy"&&K.hasAttribute("disabled"))throw new Error('Invalid "target" attribute. Please use "readonly" instead of "disabled" attribute');if(I==="cut"&&(K.hasAttribute("readonly")||K.hasAttribute("disabled")))throw new Error(`Invalid "target" attribute. You can't cut text from elements with "readonly" or "disabled" attributes`)}else throw new Error('Invalid "target" value, use a valid Element');if(Ce)return J(Ce,{container:W});if(K)return I==="cut"?w(K):J(K,{container:W})},Ne=ct;function Pe(D){"@babel/helpers - typeof";return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?Pe=function(O){return typeof O}:Pe=function(O){return O&&typeof Symbol=="function"&&O.constructor===Symbol&&O!==Symbol.prototype?"symbol":typeof O},Pe(D)}function xi(D,M){if(!(D instanceof M))throw new TypeError("Cannot call a class as a function")}function Xr(D,M){for(var O=0;O0&&arguments[0]!==void 0?arguments[0]:{};this.action=typeof W.action=="function"?W.action:this.defaultAction,this.target=typeof W.target=="function"?W.target:this.defaultTarget,this.text=typeof W.text=="function"?W.text:this.defaultText,this.container=Pe(W.container)==="object"?W.container:document.body}},{key:"listenClick",value:function(W){var K=this;this.listener=p()(W,"click",function(Ce){return K.onClick(Ce)})}},{key:"onClick",value:function(W){var K=W.delegateTarget||W.currentTarget,Ce=this.action(K)||"copy",It=Ne({action:Ce,container:this.container,target:this.target(K),text:this.text(K)});this.emit(It?"success":"error",{action:Ce,text:It,trigger:K,clearSelection:function(){K&&K.focus(),window.getSelection().removeAllRanges()}})}},{key:"defaultAction",value:function(W){return hr("action",W)}},{key:"defaultTarget",value:function(W){var K=hr("target",W);if(K)return document.querySelector(K)}},{key:"defaultText",value:function(W){return hr("text",W)}},{key:"destroy",value:function(){this.listener.destroy()}}],[{key:"copy",value:function(W){var K=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body};return J(W,K)}},{key:"cut",value:function(W){return w(W)}},{key:"isSupported",value:function(){var W=arguments.length>0&&arguments[0]!==void 0?arguments[0]:["copy","cut"],K=typeof W=="string"?[W]:W,Ce=!!document.queryCommandSupported;return K.forEach(function(It){Ce=Ce&&!!document.queryCommandSupported(It)}),Ce}}]),O}(a()),Li=Mi},828:function(o){var n=9;if(typeof Element!="undefined"&&!Element.prototype.matches){var i=Element.prototype;i.matches=i.matchesSelector||i.mozMatchesSelector||i.msMatchesSelector||i.oMatchesSelector||i.webkitMatchesSelector}function s(a,c){for(;a&&a.nodeType!==n;){if(typeof a.matches=="function"&&a.matches(c))return a;a=a.parentNode}}o.exports=s},438:function(o,n,i){var s=i(828);function a(l,f,u,h,w){var A=p.apply(this,arguments);return l.addEventListener(u,A,w),{destroy:function(){l.removeEventListener(u,A,w)}}}function c(l,f,u,h,w){return typeof l.addEventListener=="function"?a.apply(null,arguments):typeof u=="function"?a.bind(null,document).apply(null,arguments):(typeof l=="string"&&(l=document.querySelectorAll(l)),Array.prototype.map.call(l,function(A){return a(A,f,u,h,w)}))}function p(l,f,u,h){return function(w){w.delegateTarget=s(w.target,f),w.delegateTarget&&h.call(l,w)}}o.exports=c},879:function(o,n){n.node=function(i){return i!==void 0&&i instanceof HTMLElement&&i.nodeType===1},n.nodeList=function(i){var s=Object.prototype.toString.call(i);return i!==void 0&&(s==="[object NodeList]"||s==="[object HTMLCollection]")&&"length"in i&&(i.length===0||n.node(i[0]))},n.string=function(i){return typeof i=="string"||i instanceof String},n.fn=function(i){var s=Object.prototype.toString.call(i);return s==="[object Function]"}},370:function(o,n,i){var s=i(879),a=i(438);function c(u,h,w){if(!u&&!h&&!w)throw new Error("Missing required arguments");if(!s.string(h))throw new TypeError("Second argument must be a String");if(!s.fn(w))throw new TypeError("Third argument must be a Function");if(s.node(u))return p(u,h,w);if(s.nodeList(u))return l(u,h,w);if(s.string(u))return f(u,h,w);throw new TypeError("First argument must be a String, HTMLElement, HTMLCollection, or NodeList")}function p(u,h,w){return u.addEventListener(h,w),{destroy:function(){u.removeEventListener(h,w)}}}function l(u,h,w){return Array.prototype.forEach.call(u,function(A){A.addEventListener(h,w)}),{destroy:function(){Array.prototype.forEach.call(u,function(A){A.removeEventListener(h,w)})}}}function f(u,h,w){return a(document.body,u,h,w)}o.exports=c},817:function(o){function n(i){var s;if(i.nodeName==="SELECT")i.focus(),s=i.value;else if(i.nodeName==="INPUT"||i.nodeName==="TEXTAREA"){var a=i.hasAttribute("readonly");a||i.setAttribute("readonly",""),i.select(),i.setSelectionRange(0,i.value.length),a||i.removeAttribute("readonly"),s=i.value}else{i.hasAttribute("contenteditable")&&i.focus();var c=window.getSelection(),p=document.createRange();p.selectNodeContents(i),c.removeAllRanges(),c.addRange(p),s=c.toString()}return s}o.exports=n},279:function(o){function n(){}n.prototype={on:function(i,s,a){var c=this.e||(this.e={});return(c[i]||(c[i]=[])).push({fn:s,ctx:a}),this},once:function(i,s,a){var c=this;function p(){c.off(i,p),s.apply(a,arguments)}return p._=s,this.on(i,p,a)},emit:function(i){var s=[].slice.call(arguments,1),a=((this.e||(this.e={}))[i]||[]).slice(),c=0,p=a.length;for(c;c{"use strict";/*! + * escape-html + * Copyright(c) 2012-2013 TJ Holowaychuk + * Copyright(c) 2015 Andreas Lubbe + * Copyright(c) 2015 Tiancheng "Timothy" Gu + * MIT Licensed + */var Va=/["'&<>]/;qn.exports=za;function za(e){var t=""+e,r=Va.exec(t);if(!r)return t;var o,n="",i=0,s=0;for(i=r.index;i0&&i[i.length-1])&&(p[0]===6||p[0]===2)){r=0;continue}if(p[0]===3&&(!i||p[1]>i[0]&&p[1]=e.length&&(e=void 0),{value:e&&e[o++],done:!e}}};throw new TypeError(t?"Object is not iterable.":"Symbol.iterator is not defined.")}function V(e,t){var r=typeof Symbol=="function"&&e[Symbol.iterator];if(!r)return e;var o=r.call(e),n,i=[],s;try{for(;(t===void 0||t-- >0)&&!(n=o.next()).done;)i.push(n.value)}catch(a){s={error:a}}finally{try{n&&!n.done&&(r=o.return)&&r.call(o)}finally{if(s)throw s.error}}return i}function z(e,t,r){if(r||arguments.length===2)for(var o=0,n=t.length,i;o1||a(u,h)})})}function a(u,h){try{c(o[u](h))}catch(w){f(i[0][3],w)}}function c(u){u.value instanceof ot?Promise.resolve(u.value.v).then(p,l):f(i[0][2],u)}function p(u){a("next",u)}function l(u){a("throw",u)}function f(u,h){u(h),i.shift(),i.length&&a(i[0][0],i[0][1])}}function so(e){if(!Symbol.asyncIterator)throw new TypeError("Symbol.asyncIterator is not defined.");var t=e[Symbol.asyncIterator],r;return t?t.call(e):(e=typeof ue=="function"?ue(e):e[Symbol.iterator](),r={},o("next"),o("throw"),o("return"),r[Symbol.asyncIterator]=function(){return this},r);function o(i){r[i]=e[i]&&function(s){return new Promise(function(a,c){s=e[i](s),n(a,c,s.done,s.value)})}}function n(i,s,a,c){Promise.resolve(c).then(function(p){i({value:p,done:a})},s)}}function k(e){return typeof e=="function"}function pt(e){var t=function(o){Error.call(o),o.stack=new Error().stack},r=e(t);return r.prototype=Object.create(Error.prototype),r.prototype.constructor=r,r}var Wt=pt(function(e){return function(r){e(this),this.message=r?r.length+` errors occurred during unsubscription: +`+r.map(function(o,n){return n+1+") "+o.toString()}).join(` + `):"",this.name="UnsubscriptionError",this.errors=r}});function Ve(e,t){if(e){var r=e.indexOf(t);0<=r&&e.splice(r,1)}}var Ie=function(){function e(t){this.initialTeardown=t,this.closed=!1,this._parentage=null,this._finalizers=null}return e.prototype.unsubscribe=function(){var t,r,o,n,i;if(!this.closed){this.closed=!0;var s=this._parentage;if(s)if(this._parentage=null,Array.isArray(s))try{for(var a=ue(s),c=a.next();!c.done;c=a.next()){var p=c.value;p.remove(this)}}catch(A){t={error:A}}finally{try{c&&!c.done&&(r=a.return)&&r.call(a)}finally{if(t)throw t.error}}else s.remove(this);var l=this.initialTeardown;if(k(l))try{l()}catch(A){i=A instanceof Wt?A.errors:[A]}var f=this._finalizers;if(f){this._finalizers=null;try{for(var u=ue(f),h=u.next();!h.done;h=u.next()){var w=h.value;try{co(w)}catch(A){i=i!=null?i:[],A instanceof Wt?i=z(z([],V(i)),V(A.errors)):i.push(A)}}}catch(A){o={error:A}}finally{try{h&&!h.done&&(n=u.return)&&n.call(u)}finally{if(o)throw o.error}}}if(i)throw new Wt(i)}},e.prototype.add=function(t){var r;if(t&&t!==this)if(this.closed)co(t);else{if(t instanceof e){if(t.closed||t._hasParent(this))return;t._addParent(this)}(this._finalizers=(r=this._finalizers)!==null&&r!==void 0?r:[]).push(t)}},e.prototype._hasParent=function(t){var r=this._parentage;return r===t||Array.isArray(r)&&r.includes(t)},e.prototype._addParent=function(t){var r=this._parentage;this._parentage=Array.isArray(r)?(r.push(t),r):r?[r,t]:t},e.prototype._removeParent=function(t){var r=this._parentage;r===t?this._parentage=null:Array.isArray(r)&&Ve(r,t)},e.prototype.remove=function(t){var r=this._finalizers;r&&Ve(r,t),t instanceof e&&t._removeParent(this)},e.EMPTY=function(){var t=new e;return t.closed=!0,t}(),e}();var Er=Ie.EMPTY;function Dt(e){return e instanceof Ie||e&&"closed"in e&&k(e.remove)&&k(e.add)&&k(e.unsubscribe)}function co(e){k(e)?e():e.unsubscribe()}var ke={onUnhandledError:null,onStoppedNotification:null,Promise:void 0,useDeprecatedSynchronousErrorHandling:!1,useDeprecatedNextContext:!1};var lt={setTimeout:function(e,t){for(var r=[],o=2;o0},enumerable:!1,configurable:!0}),t.prototype._trySubscribe=function(r){return this._throwIfClosed(),e.prototype._trySubscribe.call(this,r)},t.prototype._subscribe=function(r){return this._throwIfClosed(),this._checkFinalizedStatuses(r),this._innerSubscribe(r)},t.prototype._innerSubscribe=function(r){var o=this,n=this,i=n.hasError,s=n.isStopped,a=n.observers;return i||s?Er:(this.currentObservers=null,a.push(r),new Ie(function(){o.currentObservers=null,Ve(a,r)}))},t.prototype._checkFinalizedStatuses=function(r){var o=this,n=o.hasError,i=o.thrownError,s=o.isStopped;n?r.error(i):s&&r.complete()},t.prototype.asObservable=function(){var r=new j;return r.source=this,r},t.create=function(r,o){return new vo(r,o)},t}(j);var vo=function(e){se(t,e);function t(r,o){var n=e.call(this)||this;return n.destination=r,n.source=o,n}return t.prototype.next=function(r){var o,n;(n=(o=this.destination)===null||o===void 0?void 0:o.next)===null||n===void 0||n.call(o,r)},t.prototype.error=function(r){var o,n;(n=(o=this.destination)===null||o===void 0?void 0:o.error)===null||n===void 0||n.call(o,r)},t.prototype.complete=function(){var r,o;(o=(r=this.destination)===null||r===void 0?void 0:r.complete)===null||o===void 0||o.call(r)},t.prototype._subscribe=function(r){var o,n;return(n=(o=this.source)===null||o===void 0?void 0:o.subscribe(r))!==null&&n!==void 0?n:Er},t}(v);var St={now:function(){return(St.delegate||Date).now()},delegate:void 0};var Ot=function(e){se(t,e);function t(r,o,n){r===void 0&&(r=1/0),o===void 0&&(o=1/0),n===void 0&&(n=St);var i=e.call(this)||this;return i._bufferSize=r,i._windowTime=o,i._timestampProvider=n,i._buffer=[],i._infiniteTimeWindow=!0,i._infiniteTimeWindow=o===1/0,i._bufferSize=Math.max(1,r),i._windowTime=Math.max(1,o),i}return t.prototype.next=function(r){var o=this,n=o.isStopped,i=o._buffer,s=o._infiniteTimeWindow,a=o._timestampProvider,c=o._windowTime;n||(i.push(r),!s&&i.push(a.now()+c)),this._trimBuffer(),e.prototype.next.call(this,r)},t.prototype._subscribe=function(r){this._throwIfClosed(),this._trimBuffer();for(var o=this._innerSubscribe(r),n=this,i=n._infiniteTimeWindow,s=n._buffer,a=s.slice(),c=0;c0?e.prototype.requestAsyncId.call(this,r,o,n):(r.actions.push(this),r._scheduled||(r._scheduled=ut.requestAnimationFrame(function(){return r.flush(void 0)})))},t.prototype.recycleAsyncId=function(r,o,n){var i;if(n===void 0&&(n=0),n!=null?n>0:this.delay>0)return e.prototype.recycleAsyncId.call(this,r,o,n);var s=r.actions;o!=null&&((i=s[s.length-1])===null||i===void 0?void 0:i.id)!==o&&(ut.cancelAnimationFrame(o),r._scheduled=void 0)},t}(zt);var yo=function(e){se(t,e);function t(){return e!==null&&e.apply(this,arguments)||this}return t.prototype.flush=function(r){this._active=!0;var o=this._scheduled;this._scheduled=void 0;var n=this.actions,i;r=r||n.shift();do if(i=r.execute(r.state,r.delay))break;while((r=n[0])&&r.id===o&&n.shift());if(this._active=!1,i){for(;(r=n[0])&&r.id===o&&n.shift();)r.unsubscribe();throw i}},t}(qt);var de=new yo(xo);var L=new j(function(e){return e.complete()});function Kt(e){return e&&k(e.schedule)}function _r(e){return e[e.length-1]}function Je(e){return k(_r(e))?e.pop():void 0}function Ae(e){return Kt(_r(e))?e.pop():void 0}function Qt(e,t){return typeof _r(e)=="number"?e.pop():t}var dt=function(e){return e&&typeof e.length=="number"&&typeof e!="function"};function Yt(e){return k(e==null?void 0:e.then)}function Bt(e){return k(e[ft])}function Gt(e){return Symbol.asyncIterator&&k(e==null?void 0:e[Symbol.asyncIterator])}function Jt(e){return new TypeError("You provided "+(e!==null&&typeof e=="object"?"an invalid object":"'"+e+"'")+" where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.")}function Di(){return typeof Symbol!="function"||!Symbol.iterator?"@@iterator":Symbol.iterator}var Xt=Di();function Zt(e){return k(e==null?void 0:e[Xt])}function er(e){return ao(this,arguments,function(){var r,o,n,i;return Ut(this,function(s){switch(s.label){case 0:r=e.getReader(),s.label=1;case 1:s.trys.push([1,,9,10]),s.label=2;case 2:return[4,ot(r.read())];case 3:return o=s.sent(),n=o.value,i=o.done,i?[4,ot(void 0)]:[3,5];case 4:return[2,s.sent()];case 5:return[4,ot(n)];case 6:return[4,s.sent()];case 7:return s.sent(),[3,2];case 8:return[3,10];case 9:return r.releaseLock(),[7];case 10:return[2]}})})}function tr(e){return k(e==null?void 0:e.getReader)}function N(e){if(e instanceof j)return e;if(e!=null){if(Bt(e))return Ni(e);if(dt(e))return Vi(e);if(Yt(e))return zi(e);if(Gt(e))return Eo(e);if(Zt(e))return qi(e);if(tr(e))return Ki(e)}throw Jt(e)}function Ni(e){return new j(function(t){var r=e[ft]();if(k(r.subscribe))return r.subscribe(t);throw new TypeError("Provided object does not correctly implement Symbol.observable")})}function Vi(e){return new j(function(t){for(var r=0;r=2;return function(o){return o.pipe(e?g(function(n,i){return e(n,i,o)}):ce,ye(1),r?Qe(t):jo(function(){return new or}))}}function $r(e){return e<=0?function(){return L}:x(function(t,r){var o=[];t.subscribe(S(r,function(n){o.push(n),e=2,!0))}function le(e){e===void 0&&(e={});var t=e.connector,r=t===void 0?function(){return new v}:t,o=e.resetOnError,n=o===void 0?!0:o,i=e.resetOnComplete,s=i===void 0?!0:i,a=e.resetOnRefCountZero,c=a===void 0?!0:a;return function(p){var l,f,u,h=0,w=!1,A=!1,Z=function(){f==null||f.unsubscribe(),f=void 0},te=function(){Z(),l=u=void 0,w=A=!1},J=function(){var C=l;te(),C==null||C.unsubscribe()};return x(function(C,ct){h++,!A&&!w&&Z();var Ne=u=u!=null?u:r();ct.add(function(){h--,h===0&&!A&&!w&&(f=Pr(J,c))}),Ne.subscribe(ct),!l&&h>0&&(l=new it({next:function(Pe){return Ne.next(Pe)},error:function(Pe){A=!0,Z(),f=Pr(te,n,Pe),Ne.error(Pe)},complete:function(){w=!0,Z(),f=Pr(te,s),Ne.complete()}}),N(C).subscribe(l))})(p)}}function Pr(e,t){for(var r=[],o=2;oe.next(document)),e}function R(e,t=document){return Array.from(t.querySelectorAll(e))}function P(e,t=document){let r=me(e,t);if(typeof r=="undefined")throw new ReferenceError(`Missing element: expected "${e}" to be present`);return r}function me(e,t=document){return t.querySelector(e)||void 0}function Re(){var e,t,r,o;return(o=(r=(t=(e=document.activeElement)==null?void 0:e.shadowRoot)==null?void 0:t.activeElement)!=null?r:document.activeElement)!=null?o:void 0}var la=T(d(document.body,"focusin"),d(document.body,"focusout")).pipe(be(1),q(void 0),m(()=>Re()||document.body),B(1));function vt(e){return la.pipe(m(t=>e.contains(t)),Y())}function Vo(e,t){return T(d(e,"mouseenter").pipe(m(()=>!0)),d(e,"mouseleave").pipe(m(()=>!1))).pipe(t?be(t):ce,q(!1))}function Ue(e){return{x:e.offsetLeft,y:e.offsetTop}}function zo(e){return T(d(window,"load"),d(window,"resize")).pipe(Me(0,de),m(()=>Ue(e)),q(Ue(e)))}function ir(e){return{x:e.scrollLeft,y:e.scrollTop}}function et(e){return T(d(e,"scroll"),d(window,"resize")).pipe(Me(0,de),m(()=>ir(e)),q(ir(e)))}function qo(e,t){if(typeof t=="string"||typeof t=="number")e.innerHTML+=t.toString();else if(t instanceof Node)e.appendChild(t);else if(Array.isArray(t))for(let r of t)qo(e,r)}function E(e,t,...r){let o=document.createElement(e);if(t)for(let n of Object.keys(t))typeof t[n]!="undefined"&&(typeof t[n]!="boolean"?o.setAttribute(n,t[n]):o.setAttribute(n,""));for(let n of r)qo(o,n);return o}function ar(e){if(e>999){let t=+((e-950)%1e3>99);return`${((e+1e-6)/1e3).toFixed(t)}k`}else return e.toString()}function gt(e){let t=E("script",{src:e});return H(()=>(document.head.appendChild(t),T(d(t,"load"),d(t,"error").pipe(b(()=>Ar(()=>new ReferenceError(`Invalid script: ${e}`))))).pipe(m(()=>{}),_(()=>document.head.removeChild(t)),ye(1))))}var Ko=new v,ma=H(()=>typeof ResizeObserver=="undefined"?gt("https://unpkg.com/resize-observer-polyfill"):$(void 0)).pipe(m(()=>new ResizeObserver(e=>{for(let t of e)Ko.next(t)})),b(e=>T(qe,$(e)).pipe(_(()=>e.disconnect()))),B(1));function pe(e){return{width:e.offsetWidth,height:e.offsetHeight}}function Ee(e){return ma.pipe(y(t=>t.observe(e)),b(t=>Ko.pipe(g(({target:r})=>r===e),_(()=>t.unobserve(e)),m(()=>pe(e)))),q(pe(e)))}function xt(e){return{width:e.scrollWidth,height:e.scrollHeight}}function sr(e){let t=e.parentElement;for(;t&&(e.scrollWidth<=t.scrollWidth&&e.scrollHeight<=t.scrollHeight);)t=(e=t).parentElement;return t?e:void 0}var Qo=new v,fa=H(()=>$(new IntersectionObserver(e=>{for(let t of e)Qo.next(t)},{threshold:0}))).pipe(b(e=>T(qe,$(e)).pipe(_(()=>e.disconnect()))),B(1));function yt(e){return fa.pipe(y(t=>t.observe(e)),b(t=>Qo.pipe(g(({target:r})=>r===e),_(()=>t.unobserve(e)),m(({isIntersecting:r})=>r))))}function Yo(e,t=16){return et(e).pipe(m(({y:r})=>{let o=pe(e),n=xt(e);return r>=n.height-o.height-t}),Y())}var cr={drawer:P("[data-md-toggle=drawer]"),search:P("[data-md-toggle=search]")};function Bo(e){return cr[e].checked}function Be(e,t){cr[e].checked!==t&&cr[e].click()}function We(e){let t=cr[e];return d(t,"change").pipe(m(()=>t.checked),q(t.checked))}function ua(e,t){switch(e.constructor){case HTMLInputElement:return e.type==="radio"?/^Arrow/.test(t):!0;case HTMLSelectElement:case HTMLTextAreaElement:return!0;default:return e.isContentEditable}}function da(){return T(d(window,"compositionstart").pipe(m(()=>!0)),d(window,"compositionend").pipe(m(()=>!1))).pipe(q(!1))}function Go(){let e=d(window,"keydown").pipe(g(t=>!(t.metaKey||t.ctrlKey)),m(t=>({mode:Bo("search")?"search":"global",type:t.key,claim(){t.preventDefault(),t.stopPropagation()}})),g(({mode:t,type:r})=>{if(t==="global"){let o=Re();if(typeof o!="undefined")return!ua(o,r)}return!0}),le());return da().pipe(b(t=>t?L:e))}function ve(){return new URL(location.href)}function st(e,t=!1){if(G("navigation.instant")&&!t){let r=E("a",{href:e.href});document.body.appendChild(r),r.click(),r.remove()}else location.href=e.href}function Jo(){return new v}function Xo(){return location.hash.slice(1)}function Zo(e){let t=E("a",{href:e});t.addEventListener("click",r=>r.stopPropagation()),t.click()}function ha(e){return T(d(window,"hashchange"),e).pipe(m(Xo),q(Xo()),g(t=>t.length>0),B(1))}function en(e){return ha(e).pipe(m(t=>me(`[id="${t}"]`)),g(t=>typeof t!="undefined"))}function At(e){let t=matchMedia(e);return nr(r=>t.addListener(()=>r(t.matches))).pipe(q(t.matches))}function tn(){let e=matchMedia("print");return T(d(window,"beforeprint").pipe(m(()=>!0)),d(window,"afterprint").pipe(m(()=>!1))).pipe(q(e.matches))}function Ur(e,t){return e.pipe(b(r=>r?t():L))}function Wr(e,t){return new j(r=>{let o=new XMLHttpRequest;return o.open("GET",`${e}`),o.responseType="blob",o.addEventListener("load",()=>{o.status>=200&&o.status<300?(r.next(o.response),r.complete()):r.error(new Error(o.statusText))}),o.addEventListener("error",()=>{r.error(new Error("Network error"))}),o.addEventListener("abort",()=>{r.complete()}),typeof(t==null?void 0:t.progress$)!="undefined"&&(o.addEventListener("progress",n=>{var i;if(n.lengthComputable)t.progress$.next(n.loaded/n.total*100);else{let s=(i=o.getResponseHeader("Content-Length"))!=null?i:0;t.progress$.next(n.loaded/+s*100)}}),t.progress$.next(5)),o.send(),()=>o.abort()})}function De(e,t){return Wr(e,t).pipe(b(r=>r.text()),m(r=>JSON.parse(r)),B(1))}function rn(e,t){let r=new DOMParser;return Wr(e,t).pipe(b(o=>o.text()),m(o=>r.parseFromString(o,"text/html")),B(1))}function on(e,t){let r=new DOMParser;return Wr(e,t).pipe(b(o=>o.text()),m(o=>r.parseFromString(o,"text/xml")),B(1))}function nn(){return{x:Math.max(0,scrollX),y:Math.max(0,scrollY)}}function an(){return T(d(window,"scroll",{passive:!0}),d(window,"resize",{passive:!0})).pipe(m(nn),q(nn()))}function sn(){return{width:innerWidth,height:innerHeight}}function cn(){return d(window,"resize",{passive:!0}).pipe(m(sn),q(sn()))}function pn(){return Q([an(),cn()]).pipe(m(([e,t])=>({offset:e,size:t})),B(1))}function pr(e,{viewport$:t,header$:r}){let o=t.pipe(X("size")),n=Q([o,r]).pipe(m(()=>Ue(e)));return Q([r,t,n]).pipe(m(([{height:i},{offset:s,size:a},{x:c,y:p}])=>({offset:{x:s.x-c,y:s.y-p+i},size:a})))}function ba(e){return d(e,"message",t=>t.data)}function va(e){let t=new v;return t.subscribe(r=>e.postMessage(r)),t}function ln(e,t=new Worker(e)){let r=ba(t),o=va(t),n=new v;n.subscribe(o);let i=o.pipe(ee(),oe(!0));return n.pipe(ee(),$e(r.pipe(U(i))),le())}var ga=P("#__config"),Et=JSON.parse(ga.textContent);Et.base=`${new URL(Et.base,ve())}`;function we(){return Et}function G(e){return Et.features.includes(e)}function ge(e,t){return typeof t!="undefined"?Et.translations[e].replace("#",t.toString()):Et.translations[e]}function Te(e,t=document){return P(`[data-md-component=${e}]`,t)}function ne(e,t=document){return R(`[data-md-component=${e}]`,t)}function xa(e){let t=P(".md-typeset > :first-child",e);return d(t,"click",{once:!0}).pipe(m(()=>P(".md-typeset",e)),m(r=>({hash:__md_hash(r.innerHTML)})))}function mn(e){if(!G("announce.dismiss")||!e.childElementCount)return L;if(!e.hidden){let t=P(".md-typeset",e);__md_hash(t.innerHTML)===__md_get("__announce")&&(e.hidden=!0)}return H(()=>{let t=new v;return t.subscribe(({hash:r})=>{e.hidden=!0,__md_set("__announce",r)}),xa(e).pipe(y(r=>t.next(r)),_(()=>t.complete()),m(r=>F({ref:e},r)))})}function ya(e,{target$:t}){return t.pipe(m(r=>({hidden:r!==e})))}function fn(e,t){let r=new v;return r.subscribe(({hidden:o})=>{e.hidden=o}),ya(e,t).pipe(y(o=>r.next(o)),_(()=>r.complete()),m(o=>F({ref:e},o)))}function Ct(e,t){return t==="inline"?E("div",{class:"md-tooltip md-tooltip--inline",id:e,role:"tooltip"},E("div",{class:"md-tooltip__inner md-typeset"})):E("div",{class:"md-tooltip",id:e,role:"tooltip"},E("div",{class:"md-tooltip__inner md-typeset"}))}function un(e,t){if(t=t?`${t}_annotation_${e}`:void 0,t){let r=t?`#${t}`:void 0;return E("aside",{class:"md-annotation",tabIndex:0},Ct(t),E("a",{href:r,class:"md-annotation__index",tabIndex:-1},E("span",{"data-md-annotation-id":e})))}else return E("aside",{class:"md-annotation",tabIndex:0},Ct(t),E("span",{class:"md-annotation__index",tabIndex:-1},E("span",{"data-md-annotation-id":e})))}function dn(e){return E("button",{class:"md-clipboard md-icon",title:ge("clipboard.copy"),"data-clipboard-target":`#${e} > code`})}function Dr(e,t){let r=t&2,o=t&1,n=Object.keys(e.terms).filter(c=>!e.terms[c]).reduce((c,p)=>[...c,E("del",null,p)," "],[]).slice(0,-1),i=we(),s=new URL(e.location,i.base);G("search.highlight")&&s.searchParams.set("h",Object.entries(e.terms).filter(([,c])=>c).reduce((c,[p])=>`${c} ${p}`.trim(),""));let{tags:a}=we();return E("a",{href:`${s}`,class:"md-search-result__link",tabIndex:-1},E("article",{class:"md-search-result__article md-typeset","data-md-score":e.score.toFixed(2)},r>0&&E("div",{class:"md-search-result__icon md-icon"}),r>0&&E("h1",null,e.title),r<=0&&E("h2",null,e.title),o>0&&e.text.length>0&&e.text,e.tags&&e.tags.map(c=>{let p=a?c in a?`md-tag-icon md-tag--${a[c]}`:"md-tag-icon":"";return E("span",{class:`md-tag ${p}`},c)}),o>0&&n.length>0&&E("p",{class:"md-search-result__terms"},ge("search.result.term.missing"),": ",...n)))}function hn(e){let t=e[0].score,r=[...e],o=we(),n=r.findIndex(l=>!`${new URL(l.location,o.base)}`.includes("#")),[i]=r.splice(n,1),s=r.findIndex(l=>l.scoreDr(l,1)),...c.length?[E("details",{class:"md-search-result__more"},E("summary",{tabIndex:-1},E("div",null,c.length>0&&c.length===1?ge("search.result.more.one"):ge("search.result.more.other",c.length))),...c.map(l=>Dr(l,1)))]:[]];return E("li",{class:"md-search-result__item"},p)}function bn(e){return E("ul",{class:"md-source__facts"},Object.entries(e).map(([t,r])=>E("li",{class:`md-source__fact md-source__fact--${t}`},typeof r=="number"?ar(r):r)))}function Nr(e){let t=`tabbed-control tabbed-control--${e}`;return E("div",{class:t,hidden:!0},E("button",{class:"tabbed-button",tabIndex:-1,"aria-hidden":"true"}))}function vn(e){return E("div",{class:"md-typeset__scrollwrap"},E("div",{class:"md-typeset__table"},e))}function Ea(e){let t=we(),r=new URL(`../${e.version}/`,t.base);return E("li",{class:"md-version__item"},E("a",{href:`${r}`,class:"md-version__link"},e.title))}function gn(e,t){return E("div",{class:"md-version"},E("button",{class:"md-version__current","aria-label":ge("select.version")},t.title),E("ul",{class:"md-version__list"},e.map(Ea)))}var wa=0;function Ta(e,t){document.body.append(e);let{width:r}=pe(e);e.style.setProperty("--md-tooltip-width",`${r}px`),e.remove();let o=sr(t),n=typeof o!="undefined"?et(o):$({x:0,y:0}),i=T(vt(t),Vo(t)).pipe(Y());return Q([i,n]).pipe(m(([s,a])=>{let{x:c,y:p}=Ue(t),l=pe(t),f=t.closest("table");return f&&t.parentElement&&(c+=f.offsetLeft+t.parentElement.offsetLeft,p+=f.offsetTop+t.parentElement.offsetTop),{active:s,offset:{x:c-a.x+l.width/2-r/2,y:p-a.y+l.height+8}}}))}function Ge(e){let t=e.title;if(!t.length)return L;let r=`__tooltip_${wa++}`,o=Ct(r,"inline"),n=P(".md-typeset",o);return n.innerHTML=t,H(()=>{let i=new v;return i.subscribe({next({offset:s}){o.style.setProperty("--md-tooltip-x",`${s.x}px`),o.style.setProperty("--md-tooltip-y",`${s.y}px`)},complete(){o.style.removeProperty("--md-tooltip-x"),o.style.removeProperty("--md-tooltip-y")}}),T(i.pipe(g(({active:s})=>s)),i.pipe(be(250),g(({active:s})=>!s))).subscribe({next({active:s}){s?(e.insertAdjacentElement("afterend",o),e.setAttribute("aria-describedby",r),e.removeAttribute("title")):(o.remove(),e.removeAttribute("aria-describedby"),e.setAttribute("title",t))},complete(){o.remove(),e.removeAttribute("aria-describedby"),e.setAttribute("title",t)}}),i.pipe(Me(16,de)).subscribe(({active:s})=>{o.classList.toggle("md-tooltip--active",s)}),i.pipe(_t(125,de),g(()=>!!e.offsetParent),m(()=>e.offsetParent.getBoundingClientRect()),m(({x:s})=>s)).subscribe({next(s){s?o.style.setProperty("--md-tooltip-0",`${-s}px`):o.style.removeProperty("--md-tooltip-0")},complete(){o.style.removeProperty("--md-tooltip-0")}}),Ta(o,e).pipe(y(s=>i.next(s)),_(()=>i.complete()),m(s=>F({ref:e},s)))}).pipe(ze(ie))}function Sa(e,t){let r=H(()=>Q([zo(e),et(t)])).pipe(m(([{x:o,y:n},i])=>{let{width:s,height:a}=pe(e);return{x:o-i.x+s/2,y:n-i.y+a/2}}));return vt(e).pipe(b(o=>r.pipe(m(n=>({active:o,offset:n})),ye(+!o||1/0))))}function xn(e,t,{target$:r}){let[o,n]=Array.from(e.children);return H(()=>{let i=new v,s=i.pipe(ee(),oe(!0));return i.subscribe({next({offset:a}){e.style.setProperty("--md-tooltip-x",`${a.x}px`),e.style.setProperty("--md-tooltip-y",`${a.y}px`)},complete(){e.style.removeProperty("--md-tooltip-x"),e.style.removeProperty("--md-tooltip-y")}}),yt(e).pipe(U(s)).subscribe(a=>{e.toggleAttribute("data-md-visible",a)}),T(i.pipe(g(({active:a})=>a)),i.pipe(be(250),g(({active:a})=>!a))).subscribe({next({active:a}){a?e.prepend(o):o.remove()},complete(){e.prepend(o)}}),i.pipe(Me(16,de)).subscribe(({active:a})=>{o.classList.toggle("md-tooltip--active",a)}),i.pipe(_t(125,de),g(()=>!!e.offsetParent),m(()=>e.offsetParent.getBoundingClientRect()),m(({x:a})=>a)).subscribe({next(a){a?e.style.setProperty("--md-tooltip-0",`${-a}px`):e.style.removeProperty("--md-tooltip-0")},complete(){e.style.removeProperty("--md-tooltip-0")}}),d(n,"click").pipe(U(s),g(a=>!(a.metaKey||a.ctrlKey))).subscribe(a=>{a.stopPropagation(),a.preventDefault()}),d(n,"mousedown").pipe(U(s),ae(i)).subscribe(([a,{active:c}])=>{var p;if(a.button!==0||a.metaKey||a.ctrlKey)a.preventDefault();else if(c){a.preventDefault();let l=e.parentElement.closest(".md-annotation");l instanceof HTMLElement?l.focus():(p=Re())==null||p.blur()}}),r.pipe(U(s),g(a=>a===o),Ye(125)).subscribe(()=>e.focus()),Sa(e,t).pipe(y(a=>i.next(a)),_(()=>i.complete()),m(a=>F({ref:e},a)))})}function Oa(e){return e.tagName==="CODE"?R(".c, .c1, .cm",e):[e]}function Ma(e){let t=[];for(let r of Oa(e)){let o=[],n=document.createNodeIterator(r,NodeFilter.SHOW_TEXT);for(let i=n.nextNode();i;i=n.nextNode())o.push(i);for(let i of o){let s;for(;s=/(\(\d+\))(!)?/.exec(i.textContent);){let[,a,c]=s;if(typeof c=="undefined"){let p=i.splitText(s.index);i=p.splitText(a.length),t.push(p)}else{i.textContent=a,t.push(i);break}}}}return t}function yn(e,t){t.append(...Array.from(e.childNodes))}function lr(e,t,{target$:r,print$:o}){let n=t.closest("[id]"),i=n==null?void 0:n.id,s=new Map;for(let a of Ma(t)){let[,c]=a.textContent.match(/\((\d+)\)/);me(`:scope > li:nth-child(${c})`,e)&&(s.set(c,un(c,i)),a.replaceWith(s.get(c)))}return s.size===0?L:H(()=>{let a=new v,c=a.pipe(ee(),oe(!0)),p=[];for(let[l,f]of s)p.push([P(".md-typeset",f),P(`:scope > li:nth-child(${l})`,e)]);return o.pipe(U(c)).subscribe(l=>{e.hidden=!l,e.classList.toggle("md-annotation-list",l);for(let[f,u]of p)l?yn(f,u):yn(u,f)}),T(...[...s].map(([,l])=>xn(l,t,{target$:r}))).pipe(_(()=>a.complete()),le())})}function En(e){if(e.nextElementSibling){let t=e.nextElementSibling;if(t.tagName==="OL")return t;if(t.tagName==="P"&&!t.children.length)return En(t)}}function wn(e,t){return H(()=>{let r=En(e);return typeof r!="undefined"?lr(r,e,t):L})}var Tn=jt(zr());var La=0;function Sn(e){if(e.nextElementSibling){let t=e.nextElementSibling;if(t.tagName==="OL")return t;if(t.tagName==="P"&&!t.children.length)return Sn(t)}}function _a(e){return Ee(e).pipe(m(({width:t})=>({scrollable:xt(e).width>t})),X("scrollable"))}function On(e,t){let{matches:r}=matchMedia("(hover)"),o=H(()=>{let n=new v,i=n.pipe($r(1));n.subscribe(({scrollable:c})=>{c&&r?e.setAttribute("tabindex","0"):e.removeAttribute("tabindex")});let s=[];if(Tn.default.isSupported()&&(e.closest(".copy")||G("content.code.copy")&&!e.closest(".no-copy"))){let c=e.closest("pre");c.id=`__code_${La++}`;let p=dn(c.id);c.insertBefore(p,e),G("content.tooltips")&&s.push(Ge(p))}let a=e.closest(".highlight");if(a instanceof HTMLElement){let c=Sn(a);if(typeof c!="undefined"&&(a.classList.contains("annotate")||G("content.code.annotate"))){let p=lr(c,e,t);s.push(Ee(a).pipe(U(i),m(({width:l,height:f})=>l&&f),Y(),b(l=>l?p:L)))}}return _a(e).pipe(y(c=>n.next(c)),_(()=>n.complete()),m(c=>F({ref:e},c)),$e(...s))});return G("content.lazy")?yt(e).pipe(g(n=>n),ye(1),b(()=>o)):o}function Aa(e,{target$:t,print$:r}){let o=!0;return T(t.pipe(m(n=>n.closest("details:not([open])")),g(n=>e===n),m(()=>({action:"open",reveal:!0}))),r.pipe(g(n=>n||!o),y(()=>o=e.open),m(n=>({action:n?"open":"close"}))))}function Mn(e,t){return H(()=>{let r=new v;return r.subscribe(({action:o,reveal:n})=>{e.toggleAttribute("open",o==="open"),n&&e.scrollIntoView()}),Aa(e,t).pipe(y(o=>r.next(o)),_(()=>r.complete()),m(o=>F({ref:e},o)))})}var Ln=".node circle,.node ellipse,.node path,.node polygon,.node rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}marker{fill:var(--md-mermaid-edge-color)!important}.edgeLabel .label rect{fill:#0000}.label{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.label foreignObject{line-height:normal;overflow:visible}.label div .edgeLabel{color:var(--md-mermaid-label-fg-color)}.edgeLabel,.edgeLabel rect,.label div .edgeLabel{background-color:var(--md-mermaid-label-bg-color)}.edgeLabel,.edgeLabel rect{fill:var(--md-mermaid-label-bg-color);color:var(--md-mermaid-edge-color)}.edgePath .path,.flowchart-link{stroke:var(--md-mermaid-edge-color);stroke-width:.05rem}.edgePath .arrowheadPath{fill:var(--md-mermaid-edge-color);stroke:none}.cluster rect{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}.cluster span{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}g #flowchart-circleEnd,g #flowchart-circleStart,g #flowchart-crossEnd,g #flowchart-crossStart,g #flowchart-pointEnd,g #flowchart-pointStart{stroke:none}g.classGroup line,g.classGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.classGroup text{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.classLabel .box{fill:var(--md-mermaid-label-bg-color);background-color:var(--md-mermaid-label-bg-color);opacity:1}.classLabel .label{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.node .divider{stroke:var(--md-mermaid-node-fg-color)}.relation{stroke:var(--md-mermaid-edge-color)}.cardinality{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.cardinality text{fill:inherit!important}defs #classDiagram-compositionEnd,defs #classDiagram-compositionStart,defs #classDiagram-dependencyEnd,defs #classDiagram-dependencyStart,defs #classDiagram-extensionEnd,defs #classDiagram-extensionStart{fill:var(--md-mermaid-edge-color)!important;stroke:var(--md-mermaid-edge-color)!important}defs #classDiagram-aggregationEnd,defs #classDiagram-aggregationStart{fill:var(--md-mermaid-label-bg-color)!important;stroke:var(--md-mermaid-edge-color)!important}g.stateGroup rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}g.stateGroup .state-title{fill:var(--md-mermaid-label-fg-color)!important;font-family:var(--md-mermaid-font-family)}g.stateGroup .composit{fill:var(--md-mermaid-label-bg-color)}.nodeLabel,.nodeLabel p{color:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.node circle.state-end,.node circle.state-start,.start-state{fill:var(--md-mermaid-edge-color);stroke:none}.end-state-inner,.end-state-outer{fill:var(--md-mermaid-edge-color)}.end-state-inner,.node circle.state-end{stroke:var(--md-mermaid-label-bg-color)}.transition{stroke:var(--md-mermaid-edge-color)}[id^=state-fork] rect,[id^=state-join] rect{fill:var(--md-mermaid-edge-color)!important;stroke:none!important}.statediagram-cluster.statediagram-cluster .inner{fill:var(--md-default-bg-color)}.statediagram-cluster rect{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.statediagram-state rect.divider{fill:var(--md-default-fg-color--lightest);stroke:var(--md-default-fg-color--lighter)}defs #statediagram-barbEnd{stroke:var(--md-mermaid-edge-color)}.attributeBoxEven,.attributeBoxOdd{fill:var(--md-mermaid-node-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityBox{fill:var(--md-mermaid-label-bg-color);stroke:var(--md-mermaid-node-fg-color)}.entityLabel{fill:var(--md-mermaid-label-fg-color);font-family:var(--md-mermaid-font-family)}.relationshipLabelBox{fill:var(--md-mermaid-label-bg-color);fill-opacity:1;background-color:var(--md-mermaid-label-bg-color);opacity:1}.relationshipLabel{fill:var(--md-mermaid-label-fg-color)}.relationshipLine{stroke:var(--md-mermaid-edge-color)}defs #ONE_OR_MORE_END *,defs #ONE_OR_MORE_START *,defs #ONLY_ONE_END *,defs #ONLY_ONE_START *,defs #ZERO_OR_MORE_END *,defs #ZERO_OR_MORE_START *,defs #ZERO_OR_ONE_END *,defs #ZERO_OR_ONE_START *{stroke:var(--md-mermaid-edge-color)!important}defs #ZERO_OR_MORE_END circle,defs #ZERO_OR_MORE_START circle{fill:var(--md-mermaid-label-bg-color)}.actor{fill:var(--md-mermaid-sequence-actor-bg-color);stroke:var(--md-mermaid-sequence-actor-border-color)}text.actor>tspan{fill:var(--md-mermaid-sequence-actor-fg-color);font-family:var(--md-mermaid-font-family)}line{stroke:var(--md-mermaid-sequence-actor-line-color)}.actor-man circle,.actor-man line{fill:var(--md-mermaid-sequence-actorman-bg-color);stroke:var(--md-mermaid-sequence-actorman-line-color)}.messageLine0,.messageLine1{stroke:var(--md-mermaid-sequence-message-line-color)}.note{fill:var(--md-mermaid-sequence-note-bg-color);stroke:var(--md-mermaid-sequence-note-border-color)}.loopText,.loopText>tspan,.messageText,.noteText>tspan{stroke:none;font-family:var(--md-mermaid-font-family)!important}.messageText{fill:var(--md-mermaid-sequence-message-fg-color)}.loopText,.loopText>tspan{fill:var(--md-mermaid-sequence-loop-fg-color)}.noteText>tspan{fill:var(--md-mermaid-sequence-note-fg-color)}#arrowhead path{fill:var(--md-mermaid-sequence-message-line-color);stroke:none}.loopLine{fill:var(--md-mermaid-sequence-loop-bg-color);stroke:var(--md-mermaid-sequence-loop-border-color)}.labelBox{fill:var(--md-mermaid-sequence-label-bg-color);stroke:none}.labelText,.labelText>span{fill:var(--md-mermaid-sequence-label-fg-color);font-family:var(--md-mermaid-font-family)}.sequenceNumber{fill:var(--md-mermaid-sequence-number-fg-color)}rect.rect{fill:var(--md-mermaid-sequence-box-bg-color);stroke:none}rect.rect+text.text{fill:var(--md-mermaid-sequence-box-fg-color)}defs #sequencenumber{fill:var(--md-mermaid-sequence-number-bg-color)!important}";var qr,ka=0;function Ha(){return typeof mermaid=="undefined"||mermaid instanceof Element?gt("https://unpkg.com/mermaid@10.7.0/dist/mermaid.min.js"):$(void 0)}function _n(e){return e.classList.remove("mermaid"),qr||(qr=Ha().pipe(y(()=>mermaid.initialize({startOnLoad:!1,themeCSS:Ln,sequence:{actorFontSize:"16px",messageFontSize:"16px",noteFontSize:"16px"}})),m(()=>{}),B(1))),qr.subscribe(()=>ro(this,null,function*(){e.classList.add("mermaid");let t=`__mermaid_${ka++}`,r=E("div",{class:"mermaid"}),o=e.textContent,{svg:n,fn:i}=yield mermaid.render(t,o),s=r.attachShadow({mode:"closed"});s.innerHTML=n,e.replaceWith(r),i==null||i(s)})),qr.pipe(m(()=>({ref:e})))}var An=E("table");function Cn(e){return e.replaceWith(An),An.replaceWith(vn(e)),$({ref:e})}function $a(e){let t=e.find(r=>r.checked)||e[0];return T(...e.map(r=>d(r,"change").pipe(m(()=>P(`label[for="${r.id}"]`))))).pipe(q(P(`label[for="${t.id}"]`)),m(r=>({active:r})))}function kn(e,{viewport$:t,target$:r}){let o=P(".tabbed-labels",e),n=R(":scope > input",e),i=Nr("prev");e.append(i);let s=Nr("next");return e.append(s),H(()=>{let a=new v,c=a.pipe(ee(),oe(!0));Q([a,Ee(e)]).pipe(U(c),Me(1,de)).subscribe({next([{active:p},l]){let f=Ue(p),{width:u}=pe(p);e.style.setProperty("--md-indicator-x",`${f.x}px`),e.style.setProperty("--md-indicator-width",`${u}px`);let h=ir(o);(f.xh.x+l.width)&&o.scrollTo({left:Math.max(0,f.x-16),behavior:"smooth"})},complete(){e.style.removeProperty("--md-indicator-x"),e.style.removeProperty("--md-indicator-width")}}),Q([et(o),Ee(o)]).pipe(U(c)).subscribe(([p,l])=>{let f=xt(o);i.hidden=p.x<16,s.hidden=p.x>f.width-l.width-16}),T(d(i,"click").pipe(m(()=>-1)),d(s,"click").pipe(m(()=>1))).pipe(U(c)).subscribe(p=>{let{width:l}=pe(o);o.scrollBy({left:l*p,behavior:"smooth"})}),r.pipe(U(c),g(p=>n.includes(p))).subscribe(p=>p.click()),o.classList.add("tabbed-labels--linked");for(let p of n){let l=P(`label[for="${p.id}"]`);l.replaceChildren(E("a",{href:`#${l.htmlFor}`,tabIndex:-1},...Array.from(l.childNodes))),d(l.firstElementChild,"click").pipe(U(c),g(f=>!(f.metaKey||f.ctrlKey)),y(f=>{f.preventDefault(),f.stopPropagation()})).subscribe(()=>{history.replaceState({},"",`#${l.htmlFor}`),l.click()})}return G("content.tabs.link")&&a.pipe(Le(1),ae(t)).subscribe(([{active:p},{offset:l}])=>{let f=p.innerText.trim();if(p.hasAttribute("data-md-switching"))p.removeAttribute("data-md-switching");else{let u=e.offsetTop-l.y;for(let w of R("[data-tabs]"))for(let A of R(":scope > input",w)){let Z=P(`label[for="${A.id}"]`);if(Z!==p&&Z.innerText.trim()===f){Z.setAttribute("data-md-switching",""),A.click();break}}window.scrollTo({top:e.offsetTop-u});let h=__md_get("__tabs")||[];__md_set("__tabs",[...new Set([f,...h])])}}),a.pipe(U(c)).subscribe(()=>{for(let p of R("audio, video",e))p.pause()}),$a(n).pipe(y(p=>a.next(p)),_(()=>a.complete()),m(p=>F({ref:e},p)))}).pipe(ze(ie))}function Hn(e,{viewport$:t,target$:r,print$:o}){return T(...R(".annotate:not(.highlight)",e).map(n=>wn(n,{target$:r,print$:o})),...R("pre:not(.mermaid) > code",e).map(n=>On(n,{target$:r,print$:o})),...R("pre.mermaid",e).map(n=>_n(n)),...R("table:not([class])",e).map(n=>Cn(n)),...R("details",e).map(n=>Mn(n,{target$:r,print$:o})),...R("[data-tabs]",e).map(n=>kn(n,{viewport$:t,target$:r})),...R("[title]",e).filter(()=>G("content.tooltips")).map(n=>Ge(n)))}function Ra(e,{alert$:t}){return t.pipe(b(r=>T($(!0),$(!1).pipe(Ye(2e3))).pipe(m(o=>({message:r,active:o})))))}function $n(e,t){let r=P(".md-typeset",e);return H(()=>{let o=new v;return o.subscribe(({message:n,active:i})=>{e.classList.toggle("md-dialog--active",i),r.textContent=n}),Ra(e,t).pipe(y(n=>o.next(n)),_(()=>o.complete()),m(n=>F({ref:e},n)))})}function Pa({viewport$:e}){if(!G("header.autohide"))return $(!1);let t=e.pipe(m(({offset:{y:n}})=>n),Ke(2,1),m(([n,i])=>[nMath.abs(i-n.y)>100),m(([,[n]])=>n),Y()),o=We("search");return Q([e,o]).pipe(m(([{offset:n},i])=>n.y>400&&!i),Y(),b(n=>n?r:$(!1)),q(!1))}function Rn(e,t){return H(()=>Q([Ee(e),Pa(t)])).pipe(m(([{height:r},o])=>({height:r,hidden:o})),Y((r,o)=>r.height===o.height&&r.hidden===o.hidden),B(1))}function Pn(e,{header$:t,main$:r}){return H(()=>{let o=new v,n=o.pipe(ee(),oe(!0));o.pipe(X("active"),je(t)).subscribe(([{active:s},{hidden:a}])=>{e.classList.toggle("md-header--shadow",s&&!a),e.hidden=a});let i=fe(R("[title]",e)).pipe(g(()=>G("content.tooltips")),re(s=>Ge(s)));return r.subscribe(o),t.pipe(U(n),m(s=>F({ref:e},s)),$e(i.pipe(U(n))))})}function Ia(e,{viewport$:t,header$:r}){return pr(e,{viewport$:t,header$:r}).pipe(m(({offset:{y:o}})=>{let{height:n}=pe(e);return{active:o>=n}}),X("active"))}function In(e,t){return H(()=>{let r=new v;r.subscribe({next({active:n}){e.classList.toggle("md-header__title--active",n)},complete(){e.classList.remove("md-header__title--active")}});let o=me(".md-content h1");return typeof o=="undefined"?L:Ia(o,t).pipe(y(n=>r.next(n)),_(()=>r.complete()),m(n=>F({ref:e},n)))})}function Fn(e,{viewport$:t,header$:r}){let o=r.pipe(m(({height:i})=>i),Y()),n=o.pipe(b(()=>Ee(e).pipe(m(({height:i})=>({top:e.offsetTop,bottom:e.offsetTop+i})),X("bottom"))));return Q([o,n,t]).pipe(m(([i,{top:s,bottom:a},{offset:{y:c},size:{height:p}}])=>(p=Math.max(0,p-Math.max(0,s-c,i)-Math.max(0,p+c-a)),{offset:s-i,height:p,active:s-i<=c})),Y((i,s)=>i.offset===s.offset&&i.height===s.height&&i.active===s.active))}function Fa(e){let t=__md_get("__palette")||{index:e.findIndex(o=>matchMedia(o.getAttribute("data-md-color-media")).matches)},r=Math.max(0,Math.min(t.index,e.length-1));return $(...e).pipe(re(o=>d(o,"change").pipe(m(()=>o))),q(e[r]),m(o=>({index:e.indexOf(o),color:{media:o.getAttribute("data-md-color-media"),scheme:o.getAttribute("data-md-color-scheme"),primary:o.getAttribute("data-md-color-primary"),accent:o.getAttribute("data-md-color-accent")}})),B(1))}function jn(e){let t=R("input",e),r=E("meta",{name:"theme-color"});document.head.appendChild(r);let o=E("meta",{name:"color-scheme"});document.head.appendChild(o);let n=At("(prefers-color-scheme: light)");return H(()=>{let i=new v;return i.subscribe(s=>{if(document.body.setAttribute("data-md-color-switching",""),s.color.media==="(prefers-color-scheme)"){let a=matchMedia("(prefers-color-scheme: light)"),c=document.querySelector(a.matches?"[data-md-color-media='(prefers-color-scheme: light)']":"[data-md-color-media='(prefers-color-scheme: dark)']");s.color.scheme=c.getAttribute("data-md-color-scheme"),s.color.primary=c.getAttribute("data-md-color-primary"),s.color.accent=c.getAttribute("data-md-color-accent")}for(let[a,c]of Object.entries(s.color))document.body.setAttribute(`data-md-color-${a}`,c);for(let a=0;a{let s=Te("header"),a=window.getComputedStyle(s);return o.content=a.colorScheme,a.backgroundColor.match(/\d+/g).map(c=>(+c).toString(16).padStart(2,"0")).join("")})).subscribe(s=>r.content=`#${s}`),i.pipe(Oe(ie)).subscribe(()=>{document.body.removeAttribute("data-md-color-switching")}),Fa(t).pipe(U(n.pipe(Le(1))),at(),y(s=>i.next(s)),_(()=>i.complete()),m(s=>F({ref:e},s)))})}function Un(e,{progress$:t}){return H(()=>{let r=new v;return r.subscribe(({value:o})=>{e.style.setProperty("--md-progress-value",`${o}`)}),t.pipe(y(o=>r.next({value:o})),_(()=>r.complete()),m(o=>({ref:e,value:o})))})}var Kr=jt(zr());function ja(e){e.setAttribute("data-md-copying","");let t=e.closest("[data-copy]"),r=t?t.getAttribute("data-copy"):e.innerText;return e.removeAttribute("data-md-copying"),r.trimEnd()}function Wn({alert$:e}){Kr.default.isSupported()&&new j(t=>{new Kr.default("[data-clipboard-target], [data-clipboard-text]",{text:r=>r.getAttribute("data-clipboard-text")||ja(P(r.getAttribute("data-clipboard-target")))}).on("success",r=>t.next(r))}).pipe(y(t=>{t.trigger.focus()}),m(()=>ge("clipboard.copied"))).subscribe(e)}function Dn(e,t){return e.protocol=t.protocol,e.hostname=t.hostname,e}function Ua(e,t){let r=new Map;for(let o of R("url",e)){let n=P("loc",o),i=[Dn(new URL(n.textContent),t)];r.set(`${i[0]}`,i);for(let s of R("[rel=alternate]",o)){let a=s.getAttribute("href");a!=null&&i.push(Dn(new URL(a),t))}}return r}function mr(e){return on(new URL("sitemap.xml",e)).pipe(m(t=>Ua(t,new URL(e))),he(()=>$(new Map)))}function Wa(e,t){if(!(e.target instanceof Element))return L;let r=e.target.closest("a");if(r===null)return L;if(r.target||e.metaKey||e.ctrlKey)return L;let o=new URL(r.href);return o.search=o.hash="",t.has(`${o}`)?(e.preventDefault(),$(new URL(r.href))):L}function Nn(e){let t=new Map;for(let r of R(":scope > *",e.head))t.set(r.outerHTML,r);return t}function Vn(e){for(let t of R("[href], [src]",e))for(let r of["href","src"]){let o=t.getAttribute(r);if(o&&!/^(?:[a-z]+:)?\/\//i.test(o)){t[r]=t[r];break}}return $(e)}function Da(e){for(let o of["[data-md-component=announce]","[data-md-component=container]","[data-md-component=header-topic]","[data-md-component=outdated]","[data-md-component=logo]","[data-md-component=skip]",...G("navigation.tabs.sticky")?["[data-md-component=tabs]"]:[]]){let n=me(o),i=me(o,e);typeof n!="undefined"&&typeof i!="undefined"&&n.replaceWith(i)}let t=Nn(document);for(let[o,n]of Nn(e))t.has(o)?t.delete(o):document.head.appendChild(n);for(let o of t.values()){let n=o.getAttribute("name");n!=="theme-color"&&n!=="color-scheme"&&o.remove()}let r=Te("container");return Fe(R("script",r)).pipe(b(o=>{let n=e.createElement("script");if(o.src){for(let i of o.getAttributeNames())n.setAttribute(i,o.getAttribute(i));return o.replaceWith(n),new j(i=>{n.onload=()=>i.complete()})}else return n.textContent=o.textContent,o.replaceWith(n),L}),ee(),oe(document))}function zn({location$:e,viewport$:t,progress$:r}){let o=we();if(location.protocol==="file:")return L;let n=mr(o.base);$(document).subscribe(Vn);let i=d(document.body,"click").pipe(je(n),b(([c,p])=>Wa(c,p)),le()),s=d(window,"popstate").pipe(m(ve),le());i.pipe(ae(t)).subscribe(([c,{offset:p}])=>{history.replaceState(p,""),history.pushState(null,"",c)}),T(i,s).subscribe(e);let a=e.pipe(X("pathname"),b(c=>rn(c,{progress$:r}).pipe(he(()=>(st(c,!0),L)))),b(Vn),b(Da),le());return T(a.pipe(ae(e,(c,p)=>p)),e.pipe(X("pathname"),b(()=>e),X("hash")),e.pipe(Y((c,p)=>c.pathname===p.pathname&&c.hash===p.hash),b(()=>i),y(()=>history.back()))).subscribe(c=>{var p,l;history.state!==null||!c.hash?window.scrollTo(0,(l=(p=history.state)==null?void 0:p.y)!=null?l:0):(history.scrollRestoration="auto",Zo(c.hash),history.scrollRestoration="manual")}),e.subscribe(()=>{history.scrollRestoration="manual"}),d(window,"beforeunload").subscribe(()=>{history.scrollRestoration="auto"}),t.pipe(X("offset"),be(100)).subscribe(({offset:c})=>{history.replaceState(c,"")}),a}var Qn=jt(Kn());function Yn(e){let t=e.separator.split("|").map(n=>n.replace(/(\(\?[!=<][^)]+\))/g,"").length===0?"\uFFFD":n).join("|"),r=new RegExp(t,"img"),o=(n,i,s)=>`${i}${s}`;return n=>{n=n.replace(/[\s*+\-:~^]+/g," ").trim();let i=new RegExp(`(^|${e.separator}|)(${n.replace(/[|\\{}()[\]^$+*?.-]/g,"\\$&").replace(r,"|")})`,"img");return s=>(0,Qn.default)(s).replace(i,o).replace(/<\/mark>(\s+)]*>/img,"$1")}}function Ht(e){return e.type===1}function fr(e){return e.type===3}function Bn(e,t){let r=ln(e);return T($(location.protocol!=="file:"),We("search")).pipe(He(o=>o),b(()=>t)).subscribe(({config:o,docs:n})=>r.next({type:0,data:{config:o,docs:n,options:{suggest:G("search.suggest")}}})),r}function Gn({document$:e}){let t=we(),r=De(new URL("../versions.json",t.base)).pipe(he(()=>L)),o=r.pipe(m(n=>{let[,i]=t.base.match(/([^/]+)\/?$/);return n.find(({version:s,aliases:a})=>s===i||a.includes(i))||n[0]}));r.pipe(m(n=>new Map(n.map(i=>[`${new URL(`../${i.version}/`,t.base)}`,i]))),b(n=>d(document.body,"click").pipe(g(i=>!i.metaKey&&!i.ctrlKey),ae(o),b(([i,s])=>{if(i.target instanceof Element){let a=i.target.closest("a");if(a&&!a.target&&n.has(a.href)){let c=a.href;return!i.target.closest(".md-version")&&n.get(c)===s?L:(i.preventDefault(),$(c))}}return L}),b(i=>{let{version:s}=n.get(i);return mr(new URL(i)).pipe(m(a=>{let p=ve().href.replace(t.base,"");return a.has(p.split("#")[0])?new URL(`../${s}/${p}`,t.base):new URL(i)}))})))).subscribe(n=>st(n,!0)),Q([r,o]).subscribe(([n,i])=>{P(".md-header__topic").appendChild(gn(n,i))}),e.pipe(b(()=>o)).subscribe(n=>{var s;let i=__md_get("__outdated",sessionStorage);if(i===null){i=!0;let a=((s=t.version)==null?void 0:s.default)||"latest";Array.isArray(a)||(a=[a]);e:for(let c of a)for(let p of n.aliases.concat(n.version))if(new RegExp(c,"i").test(p)){i=!1;break e}__md_set("__outdated",i,sessionStorage)}if(i)for(let a of ne("outdated"))a.hidden=!1})}function Ka(e,{worker$:t}){let{searchParams:r}=ve();r.has("q")&&(Be("search",!0),e.value=r.get("q"),e.focus(),We("search").pipe(He(i=>!i)).subscribe(()=>{let i=ve();i.searchParams.delete("q"),history.replaceState({},"",`${i}`)}));let o=vt(e),n=T(t.pipe(He(Ht)),d(e,"keyup"),o).pipe(m(()=>e.value),Y());return Q([n,o]).pipe(m(([i,s])=>({value:i,focus:s})),B(1))}function Jn(e,{worker$:t}){let r=new v,o=r.pipe(ee(),oe(!0));Q([t.pipe(He(Ht)),r],(i,s)=>s).pipe(X("value")).subscribe(({value:i})=>t.next({type:2,data:i})),r.pipe(X("focus")).subscribe(({focus:i})=>{i&&Be("search",i)}),d(e.form,"reset").pipe(U(o)).subscribe(()=>e.focus());let n=P("header [for=__search]");return d(n,"click").subscribe(()=>e.focus()),Ka(e,{worker$:t}).pipe(y(i=>r.next(i)),_(()=>r.complete()),m(i=>F({ref:e},i)),B(1))}function Xn(e,{worker$:t,query$:r}){let o=new v,n=Yo(e.parentElement).pipe(g(Boolean)),i=e.parentElement,s=P(":scope > :first-child",e),a=P(":scope > :last-child",e);We("search").subscribe(l=>a.setAttribute("role",l?"list":"presentation")),o.pipe(ae(r),Ir(t.pipe(He(Ht)))).subscribe(([{items:l},{value:f}])=>{switch(l.length){case 0:s.textContent=f.length?ge("search.result.none"):ge("search.result.placeholder");break;case 1:s.textContent=ge("search.result.one");break;default:let u=ar(l.length);s.textContent=ge("search.result.other",u)}});let c=o.pipe(y(()=>a.innerHTML=""),b(({items:l})=>T($(...l.slice(0,10)),$(...l.slice(10)).pipe(Ke(4),jr(n),b(([f])=>f)))),m(hn),le());return c.subscribe(l=>a.appendChild(l)),c.pipe(re(l=>{let f=me("details",l);return typeof f=="undefined"?L:d(f,"toggle").pipe(U(o),m(()=>f))})).subscribe(l=>{l.open===!1&&l.offsetTop<=i.scrollTop&&i.scrollTo({top:l.offsetTop})}),t.pipe(g(fr),m(({data:l})=>l)).pipe(y(l=>o.next(l)),_(()=>o.complete()),m(l=>F({ref:e},l)))}function Qa(e,{query$:t}){return t.pipe(m(({value:r})=>{let o=ve();return o.hash="",r=r.replace(/\s+/g,"+").replace(/&/g,"%26").replace(/=/g,"%3D"),o.search=`q=${r}`,{url:o}}))}function Zn(e,t){let r=new v,o=r.pipe(ee(),oe(!0));return r.subscribe(({url:n})=>{e.setAttribute("data-clipboard-text",e.href),e.href=`${n}`}),d(e,"click").pipe(U(o)).subscribe(n=>n.preventDefault()),Qa(e,t).pipe(y(n=>r.next(n)),_(()=>r.complete()),m(n=>F({ref:e},n)))}function ei(e,{worker$:t,keyboard$:r}){let o=new v,n=Te("search-query"),i=T(d(n,"keydown"),d(n,"focus")).pipe(Oe(ie),m(()=>n.value),Y());return o.pipe(je(i),m(([{suggest:a},c])=>{let p=c.split(/([\s-]+)/);if(a!=null&&a.length&&p[p.length-1]){let l=a[a.length-1];l.startsWith(p[p.length-1])&&(p[p.length-1]=l)}else p.length=0;return p})).subscribe(a=>e.innerHTML=a.join("").replace(/\s/g," ")),r.pipe(g(({mode:a})=>a==="search")).subscribe(a=>{switch(a.type){case"ArrowRight":e.innerText.length&&n.selectionStart===n.value.length&&(n.value=e.innerText);break}}),t.pipe(g(fr),m(({data:a})=>a)).pipe(y(a=>o.next(a)),_(()=>o.complete()),m(()=>({ref:e})))}function ti(e,{index$:t,keyboard$:r}){let o=we();try{let n=Bn(o.search,t),i=Te("search-query",e),s=Te("search-result",e);d(e,"click").pipe(g(({target:c})=>c instanceof Element&&!!c.closest("a"))).subscribe(()=>Be("search",!1)),r.pipe(g(({mode:c})=>c==="search")).subscribe(c=>{let p=Re();switch(c.type){case"Enter":if(p===i){let l=new Map;for(let f of R(":first-child [href]",s)){let u=f.firstElementChild;l.set(f,parseFloat(u.getAttribute("data-md-score")))}if(l.size){let[[f]]=[...l].sort(([,u],[,h])=>h-u);f.click()}c.claim()}break;case"Escape":case"Tab":Be("search",!1),i.blur();break;case"ArrowUp":case"ArrowDown":if(typeof p=="undefined")i.focus();else{let l=[i,...R(":not(details) > [href], summary, details[open] [href]",s)],f=Math.max(0,(Math.max(0,l.indexOf(p))+l.length+(c.type==="ArrowUp"?-1:1))%l.length);l[f].focus()}c.claim();break;default:i!==Re()&&i.focus()}}),r.pipe(g(({mode:c})=>c==="global")).subscribe(c=>{switch(c.type){case"f":case"s":case"/":i.focus(),i.select(),c.claim();break}});let a=Jn(i,{worker$:n});return T(a,Xn(s,{worker$:n,query$:a})).pipe($e(...ne("search-share",e).map(c=>Zn(c,{query$:a})),...ne("search-suggest",e).map(c=>ei(c,{worker$:n,keyboard$:r}))))}catch(n){return e.hidden=!0,qe}}function ri(e,{index$:t,location$:r}){return Q([t,r.pipe(q(ve()),g(o=>!!o.searchParams.get("h")))]).pipe(m(([o,n])=>Yn(o.config)(n.searchParams.get("h"))),m(o=>{var s;let n=new Map,i=document.createNodeIterator(e,NodeFilter.SHOW_TEXT);for(let a=i.nextNode();a;a=i.nextNode())if((s=a.parentElement)!=null&&s.offsetHeight){let c=a.textContent,p=o(c);p.length>c.length&&n.set(a,p)}for(let[a,c]of n){let{childNodes:p}=E("span",null,c);a.replaceWith(...Array.from(p))}return{ref:e,nodes:n}}))}function Ya(e,{viewport$:t,main$:r}){let o=e.closest(".md-grid"),n=o.offsetTop-o.parentElement.offsetTop;return Q([r,t]).pipe(m(([{offset:i,height:s},{offset:{y:a}}])=>(s=s+Math.min(n,Math.max(0,a-i))-n,{height:s,locked:a>=i+n})),Y((i,s)=>i.height===s.height&&i.locked===s.locked))}function Qr(e,o){var n=o,{header$:t}=n,r=to(n,["header$"]);let i=P(".md-sidebar__scrollwrap",e),{y:s}=Ue(i);return H(()=>{let a=new v,c=a.pipe(ee(),oe(!0)),p=a.pipe(Me(0,de));return p.pipe(ae(t)).subscribe({next([{height:l},{height:f}]){i.style.height=`${l-2*s}px`,e.style.top=`${f}px`},complete(){i.style.height="",e.style.top=""}}),p.pipe(He()).subscribe(()=>{for(let l of R(".md-nav__link--active[href]",e)){if(!l.clientHeight)continue;let f=l.closest(".md-sidebar__scrollwrap");if(typeof f!="undefined"){let u=l.offsetTop-f.offsetTop,{height:h}=pe(f);f.scrollTo({top:u-h/2})}}}),fe(R("label[tabindex]",e)).pipe(re(l=>d(l,"click").pipe(Oe(ie),m(()=>l),U(c)))).subscribe(l=>{let f=P(`[id="${l.htmlFor}"]`);P(`[aria-labelledby="${l.id}"]`).setAttribute("aria-expanded",`${f.checked}`)}),Ya(e,r).pipe(y(l=>a.next(l)),_(()=>a.complete()),m(l=>F({ref:e},l)))})}function oi(e,t){if(typeof t!="undefined"){let r=`https://api.github.com/repos/${e}/${t}`;return Lt(De(`${r}/releases/latest`).pipe(he(()=>L),m(o=>({version:o.tag_name})),Qe({})),De(r).pipe(he(()=>L),m(o=>({stars:o.stargazers_count,forks:o.forks_count})),Qe({}))).pipe(m(([o,n])=>F(F({},o),n)))}else{let r=`https://api.github.com/users/${e}`;return De(r).pipe(m(o=>({repositories:o.public_repos})),Qe({}))}}function ni(e,t){let r=`https://${e}/api/v4/projects/${encodeURIComponent(t)}`;return De(r).pipe(he(()=>L),m(({star_count:o,forks_count:n})=>({stars:o,forks:n})),Qe({}))}function ii(e){let t=e.match(/^.+github\.com\/([^/]+)\/?([^/]+)?/i);if(t){let[,r,o]=t;return oi(r,o)}if(t=e.match(/^.+?([^/]*gitlab[^/]+)\/(.+?)\/?$/i),t){let[,r,o]=t;return ni(r,o)}return L}var Ba;function Ga(e){return Ba||(Ba=H(()=>{let t=__md_get("__source",sessionStorage);if(t)return $(t);if(ne("consent").length){let o=__md_get("__consent");if(!(o&&o.github))return L}return ii(e.href).pipe(y(o=>__md_set("__source",o,sessionStorage)))}).pipe(he(()=>L),g(t=>Object.keys(t).length>0),m(t=>({facts:t})),B(1)))}function ai(e){let t=P(":scope > :last-child",e);return H(()=>{let r=new v;return r.subscribe(({facts:o})=>{t.appendChild(bn(o)),t.classList.add("md-source__repository--active")}),Ga(e).pipe(y(o=>r.next(o)),_(()=>r.complete()),m(o=>F({ref:e},o)))})}function Ja(e,{viewport$:t,header$:r}){return Ee(document.body).pipe(b(()=>pr(e,{header$:r,viewport$:t})),m(({offset:{y:o}})=>({hidden:o>=10})),X("hidden"))}function si(e,t){return H(()=>{let r=new v;return r.subscribe({next({hidden:o}){e.hidden=o},complete(){e.hidden=!1}}),(G("navigation.tabs.sticky")?$({hidden:!1}):Ja(e,t)).pipe(y(o=>r.next(o)),_(()=>r.complete()),m(o=>F({ref:e},o)))})}function Xa(e,{viewport$:t,header$:r}){let o=new Map,n=R(".md-nav__link",e);for(let a of n){let c=decodeURIComponent(a.hash.substring(1)),p=me(`[id="${c}"]`);typeof p!="undefined"&&o.set(a,p)}let i=r.pipe(X("height"),m(({height:a})=>{let c=Te("main"),p=P(":scope > :first-child",c);return a+.8*(p.offsetTop-c.offsetTop)}),le());return Ee(document.body).pipe(X("height"),b(a=>H(()=>{let c=[];return $([...o].reduce((p,[l,f])=>{for(;c.length&&o.get(c[c.length-1]).tagName>=f.tagName;)c.pop();let u=f.offsetTop;for(;!u&&f.parentElement;)f=f.parentElement,u=f.offsetTop;let h=f.offsetParent;for(;h;h=h.offsetParent)u+=h.offsetTop;return p.set([...c=[...c,l]].reverse(),u)},new Map))}).pipe(m(c=>new Map([...c].sort(([,p],[,l])=>p-l))),je(i),b(([c,p])=>t.pipe(Rr(([l,f],{offset:{y:u},size:h})=>{let w=u+h.height>=Math.floor(a.height);for(;f.length;){let[,A]=f[0];if(A-p=u&&!w)f=[l.pop(),...f];else break}return[l,f]},[[],[...c]]),Y((l,f)=>l[0]===f[0]&&l[1]===f[1])))))).pipe(m(([a,c])=>({prev:a.map(([p])=>p),next:c.map(([p])=>p)})),q({prev:[],next:[]}),Ke(2,1),m(([a,c])=>a.prev.length{let i=new v,s=i.pipe(ee(),oe(!0));if(i.subscribe(({prev:a,next:c})=>{for(let[p]of c)p.classList.remove("md-nav__link--passed"),p.classList.remove("md-nav__link--active");for(let[p,[l]]of a.entries())l.classList.add("md-nav__link--passed"),l.classList.toggle("md-nav__link--active",p===a.length-1)}),G("toc.follow")){let a=T(t.pipe(be(1),m(()=>{})),t.pipe(be(250),m(()=>"smooth")));i.pipe(g(({prev:c})=>c.length>0),je(o.pipe(Oe(ie))),ae(a)).subscribe(([[{prev:c}],p])=>{let[l]=c[c.length-1];if(l.offsetHeight){let f=sr(l);if(typeof f!="undefined"){let u=l.offsetTop-f.offsetTop,{height:h}=pe(f);f.scrollTo({top:u-h/2,behavior:p})}}})}return G("navigation.tracking")&&t.pipe(U(s),X("offset"),be(250),Le(1),U(n.pipe(Le(1))),at({delay:250}),ae(i)).subscribe(([,{prev:a}])=>{let c=ve(),p=a[a.length-1];if(p&&p.length){let[l]=p,{hash:f}=new URL(l.href);c.hash!==f&&(c.hash=f,history.replaceState({},"",`${c}`))}else c.hash="",history.replaceState({},"",`${c}`)}),Xa(e,{viewport$:t,header$:r}).pipe(y(a=>i.next(a)),_(()=>i.complete()),m(a=>F({ref:e},a)))})}function Za(e,{viewport$:t,main$:r,target$:o}){let n=t.pipe(m(({offset:{y:s}})=>s),Ke(2,1),m(([s,a])=>s>a&&a>0),Y()),i=r.pipe(m(({active:s})=>s));return Q([i,n]).pipe(m(([s,a])=>!(s&&a)),Y(),U(o.pipe(Le(1))),oe(!0),at({delay:250}),m(s=>({hidden:s})))}function pi(e,{viewport$:t,header$:r,main$:o,target$:n}){let i=new v,s=i.pipe(ee(),oe(!0));return i.subscribe({next({hidden:a}){e.hidden=a,a?(e.setAttribute("tabindex","-1"),e.blur()):e.removeAttribute("tabindex")},complete(){e.style.top="",e.hidden=!0,e.removeAttribute("tabindex")}}),r.pipe(U(s),X("height")).subscribe(({height:a})=>{e.style.top=`${a+16}px`}),d(e,"click").subscribe(a=>{a.preventDefault(),window.scrollTo({top:0})}),Za(e,{viewport$:t,main$:o,target$:n}).pipe(y(a=>i.next(a)),_(()=>i.complete()),m(a=>F({ref:e},a)))}function li({document$:e}){e.pipe(b(()=>R(".md-ellipsis")),re(t=>yt(t).pipe(U(e.pipe(Le(1))),g(r=>r),m(()=>t),ye(1))),g(t=>t.offsetWidth{let r=t.innerText,o=t.closest("a")||t;return o.title=r,Ge(o).pipe(U(e.pipe(Le(1))),_(()=>o.removeAttribute("title")))})).subscribe(),e.pipe(b(()=>R(".md-status")),re(t=>Ge(t))).subscribe()}function mi({document$:e,tablet$:t}){e.pipe(b(()=>R(".md-toggle--indeterminate")),y(r=>{r.indeterminate=!0,r.checked=!1}),re(r=>d(r,"change").pipe(Fr(()=>r.classList.contains("md-toggle--indeterminate")),m(()=>r))),ae(t)).subscribe(([r,o])=>{r.classList.remove("md-toggle--indeterminate"),o&&(r.checked=!1)})}function es(){return/(iPad|iPhone|iPod)/.test(navigator.userAgent)}function fi({document$:e}){e.pipe(b(()=>R("[data-md-scrollfix]")),y(t=>t.removeAttribute("data-md-scrollfix")),g(es),re(t=>d(t,"touchstart").pipe(m(()=>t)))).subscribe(t=>{let r=t.scrollTop;r===0?t.scrollTop=1:r+t.offsetHeight===t.scrollHeight&&(t.scrollTop=r-1)})}function ui({viewport$:e,tablet$:t}){Q([We("search"),t]).pipe(m(([r,o])=>r&&!o),b(r=>$(r).pipe(Ye(r?400:100))),ae(e)).subscribe(([r,{offset:{y:o}}])=>{if(r)document.body.setAttribute("data-md-scrolllock",""),document.body.style.top=`-${o}px`;else{let n=-1*parseInt(document.body.style.top,10);document.body.removeAttribute("data-md-scrolllock"),document.body.style.top="",n&&window.scrollTo(0,n)}})}Object.entries||(Object.entries=function(e){let t=[];for(let r of Object.keys(e))t.push([r,e[r]]);return t});Object.values||(Object.values=function(e){let t=[];for(let r of Object.keys(e))t.push(e[r]);return t});typeof Element!="undefined"&&(Element.prototype.scrollTo||(Element.prototype.scrollTo=function(e,t){typeof e=="object"?(this.scrollLeft=e.left,this.scrollTop=e.top):(this.scrollLeft=e,this.scrollTop=t)}),Element.prototype.replaceWith||(Element.prototype.replaceWith=function(...e){let t=this.parentNode;if(t){e.length===0&&t.removeChild(this);for(let r=e.length-1;r>=0;r--){let o=e[r];typeof o=="string"?o=document.createTextNode(o):o.parentNode&&o.parentNode.removeChild(o),r?t.insertBefore(this.previousSibling,o):t.replaceChild(o,this)}}}));function ts(){return location.protocol==="file:"?gt(`${new URL("search/search_index.js",Yr.base)}`).pipe(m(()=>__index),B(1)):De(new URL("search/search_index.json",Yr.base))}document.documentElement.classList.remove("no-js");document.documentElement.classList.add("js");var rt=No(),Rt=Jo(),wt=en(Rt),Br=Go(),_e=pn(),ur=At("(min-width: 960px)"),hi=At("(min-width: 1220px)"),bi=tn(),Yr=we(),vi=document.forms.namedItem("search")?ts():qe,Gr=new v;Wn({alert$:Gr});var Jr=new v;G("navigation.instant")&&zn({location$:Rt,viewport$:_e,progress$:Jr}).subscribe(rt);var di;((di=Yr.version)==null?void 0:di.provider)==="mike"&&Gn({document$:rt});T(Rt,wt).pipe(Ye(125)).subscribe(()=>{Be("drawer",!1),Be("search",!1)});Br.pipe(g(({mode:e})=>e==="global")).subscribe(e=>{switch(e.type){case"p":case",":let t=me("link[rel=prev]");typeof t!="undefined"&&st(t);break;case"n":case".":let r=me("link[rel=next]");typeof r!="undefined"&&st(r);break;case"Enter":let o=Re();o instanceof HTMLLabelElement&&o.click()}});li({document$:rt});mi({document$:rt,tablet$:ur});fi({document$:rt});ui({viewport$:_e,tablet$:ur});var tt=Rn(Te("header"),{viewport$:_e}),$t=rt.pipe(m(()=>Te("main")),b(e=>Fn(e,{viewport$:_e,header$:tt})),B(1)),rs=T(...ne("consent").map(e=>fn(e,{target$:wt})),...ne("dialog").map(e=>$n(e,{alert$:Gr})),...ne("header").map(e=>Pn(e,{viewport$:_e,header$:tt,main$:$t})),...ne("palette").map(e=>jn(e)),...ne("progress").map(e=>Un(e,{progress$:Jr})),...ne("search").map(e=>ti(e,{index$:vi,keyboard$:Br})),...ne("source").map(e=>ai(e))),os=H(()=>T(...ne("announce").map(e=>mn(e)),...ne("content").map(e=>Hn(e,{viewport$:_e,target$:wt,print$:bi})),...ne("content").map(e=>G("search.highlight")?ri(e,{index$:vi,location$:Rt}):L),...ne("header-title").map(e=>In(e,{viewport$:_e,header$:tt})),...ne("sidebar").map(e=>e.getAttribute("data-md-type")==="navigation"?Ur(hi,()=>Qr(e,{viewport$:_e,header$:tt,main$:$t})):Ur(ur,()=>Qr(e,{viewport$:_e,header$:tt,main$:$t}))),...ne("tabs").map(e=>si(e,{viewport$:_e,header$:tt})),...ne("toc").map(e=>ci(e,{viewport$:_e,header$:tt,main$:$t,target$:wt})),...ne("top").map(e=>pi(e,{viewport$:_e,header$:tt,main$:$t,target$:wt})))),gi=rt.pipe(b(()=>os),$e(rs),B(1));gi.subscribe();window.document$=rt;window.location$=Rt;window.target$=wt;window.keyboard$=Br;window.viewport$=_e;window.tablet$=ur;window.screen$=hi;window.print$=bi;window.alert$=Gr;window.progress$=Jr;window.component$=gi;})(); +//# sourceMappingURL=bundle.c8d2eff1.min.js.map + diff --git a/1.3.0/assets/javascripts/bundle.c8d2eff1.min.js.map b/1.3.0/assets/javascripts/bundle.c8d2eff1.min.js.map new file mode 100644 index 0000000..fc522db --- /dev/null +++ b/1.3.0/assets/javascripts/bundle.c8d2eff1.min.js.map @@ -0,0 +1,7 @@ +{ + "version": 3, + "sources": ["node_modules/focus-visible/dist/focus-visible.js", "node_modules/clipboard/dist/clipboard.js", "node_modules/escape-html/index.js", "src/templates/assets/javascripts/bundle.ts", "node_modules/rxjs/node_modules/tslib/tslib.es6.js", "node_modules/rxjs/src/internal/util/isFunction.ts", "node_modules/rxjs/src/internal/util/createErrorClass.ts", "node_modules/rxjs/src/internal/util/UnsubscriptionError.ts", "node_modules/rxjs/src/internal/util/arrRemove.ts", "node_modules/rxjs/src/internal/Subscription.ts", "node_modules/rxjs/src/internal/config.ts", "node_modules/rxjs/src/internal/scheduler/timeoutProvider.ts", "node_modules/rxjs/src/internal/util/reportUnhandledError.ts", "node_modules/rxjs/src/internal/util/noop.ts", "node_modules/rxjs/src/internal/NotificationFactories.ts", "node_modules/rxjs/src/internal/util/errorContext.ts", "node_modules/rxjs/src/internal/Subscriber.ts", "node_modules/rxjs/src/internal/symbol/observable.ts", "node_modules/rxjs/src/internal/util/identity.ts", "node_modules/rxjs/src/internal/util/pipe.ts", "node_modules/rxjs/src/internal/Observable.ts", "node_modules/rxjs/src/internal/util/lift.ts", "node_modules/rxjs/src/internal/operators/OperatorSubscriber.ts", "node_modules/rxjs/src/internal/scheduler/animationFrameProvider.ts", "node_modules/rxjs/src/internal/util/ObjectUnsubscribedError.ts", "node_modules/rxjs/src/internal/Subject.ts", "node_modules/rxjs/src/internal/scheduler/dateTimestampProvider.ts", "node_modules/rxjs/src/internal/ReplaySubject.ts", "node_modules/rxjs/src/internal/scheduler/Action.ts", "node_modules/rxjs/src/internal/scheduler/intervalProvider.ts", "node_modules/rxjs/src/internal/scheduler/AsyncAction.ts", "node_modules/rxjs/src/internal/Scheduler.ts", "node_modules/rxjs/src/internal/scheduler/AsyncScheduler.ts", "node_modules/rxjs/src/internal/scheduler/async.ts", "node_modules/rxjs/src/internal/scheduler/AnimationFrameAction.ts", "node_modules/rxjs/src/internal/scheduler/AnimationFrameScheduler.ts", "node_modules/rxjs/src/internal/scheduler/animationFrame.ts", "node_modules/rxjs/src/internal/observable/empty.ts", "node_modules/rxjs/src/internal/util/isScheduler.ts", "node_modules/rxjs/src/internal/util/args.ts", "node_modules/rxjs/src/internal/util/isArrayLike.ts", "node_modules/rxjs/src/internal/util/isPromise.ts", "node_modules/rxjs/src/internal/util/isInteropObservable.ts", "node_modules/rxjs/src/internal/util/isAsyncIterable.ts", "node_modules/rxjs/src/internal/util/throwUnobservableError.ts", "node_modules/rxjs/src/internal/symbol/iterator.ts", "node_modules/rxjs/src/internal/util/isIterable.ts", "node_modules/rxjs/src/internal/util/isReadableStreamLike.ts", "node_modules/rxjs/src/internal/observable/innerFrom.ts", "node_modules/rxjs/src/internal/util/executeSchedule.ts", "node_modules/rxjs/src/internal/operators/observeOn.ts", "node_modules/rxjs/src/internal/operators/subscribeOn.ts", "node_modules/rxjs/src/internal/scheduled/scheduleObservable.ts", "node_modules/rxjs/src/internal/scheduled/schedulePromise.ts", "node_modules/rxjs/src/internal/scheduled/scheduleArray.ts", "node_modules/rxjs/src/internal/scheduled/scheduleIterable.ts", "node_modules/rxjs/src/internal/scheduled/scheduleAsyncIterable.ts", "node_modules/rxjs/src/internal/scheduled/scheduleReadableStreamLike.ts", "node_modules/rxjs/src/internal/scheduled/scheduled.ts", "node_modules/rxjs/src/internal/observable/from.ts", "node_modules/rxjs/src/internal/observable/of.ts", "node_modules/rxjs/src/internal/observable/throwError.ts", "node_modules/rxjs/src/internal/util/EmptyError.ts", "node_modules/rxjs/src/internal/util/isDate.ts", "node_modules/rxjs/src/internal/operators/map.ts", "node_modules/rxjs/src/internal/util/mapOneOrManyArgs.ts", "node_modules/rxjs/src/internal/util/argsArgArrayOrObject.ts", "node_modules/rxjs/src/internal/util/createObject.ts", "node_modules/rxjs/src/internal/observable/combineLatest.ts", "node_modules/rxjs/src/internal/operators/mergeInternals.ts", "node_modules/rxjs/src/internal/operators/mergeMap.ts", "node_modules/rxjs/src/internal/operators/mergeAll.ts", "node_modules/rxjs/src/internal/operators/concatAll.ts", "node_modules/rxjs/src/internal/observable/concat.ts", "node_modules/rxjs/src/internal/observable/defer.ts", "node_modules/rxjs/src/internal/observable/fromEvent.ts", "node_modules/rxjs/src/internal/observable/fromEventPattern.ts", "node_modules/rxjs/src/internal/observable/timer.ts", "node_modules/rxjs/src/internal/observable/merge.ts", "node_modules/rxjs/src/internal/observable/never.ts", "node_modules/rxjs/src/internal/util/argsOrArgArray.ts", "node_modules/rxjs/src/internal/operators/filter.ts", "node_modules/rxjs/src/internal/observable/zip.ts", "node_modules/rxjs/src/internal/operators/audit.ts", "node_modules/rxjs/src/internal/operators/auditTime.ts", "node_modules/rxjs/src/internal/operators/bufferCount.ts", "node_modules/rxjs/src/internal/operators/catchError.ts", "node_modules/rxjs/src/internal/operators/scanInternals.ts", "node_modules/rxjs/src/internal/operators/combineLatest.ts", "node_modules/rxjs/src/internal/operators/combineLatestWith.ts", "node_modules/rxjs/src/internal/operators/debounceTime.ts", "node_modules/rxjs/src/internal/operators/defaultIfEmpty.ts", "node_modules/rxjs/src/internal/operators/take.ts", "node_modules/rxjs/src/internal/operators/ignoreElements.ts", "node_modules/rxjs/src/internal/operators/mapTo.ts", "node_modules/rxjs/src/internal/operators/delayWhen.ts", "node_modules/rxjs/src/internal/operators/delay.ts", "node_modules/rxjs/src/internal/operators/distinctUntilChanged.ts", "node_modules/rxjs/src/internal/operators/distinctUntilKeyChanged.ts", "node_modules/rxjs/src/internal/operators/throwIfEmpty.ts", "node_modules/rxjs/src/internal/operators/endWith.ts", "node_modules/rxjs/src/internal/operators/finalize.ts", "node_modules/rxjs/src/internal/operators/first.ts", "node_modules/rxjs/src/internal/operators/takeLast.ts", "node_modules/rxjs/src/internal/operators/merge.ts", "node_modules/rxjs/src/internal/operators/mergeWith.ts", "node_modules/rxjs/src/internal/operators/repeat.ts", "node_modules/rxjs/src/internal/operators/scan.ts", "node_modules/rxjs/src/internal/operators/share.ts", "node_modules/rxjs/src/internal/operators/shareReplay.ts", "node_modules/rxjs/src/internal/operators/skip.ts", "node_modules/rxjs/src/internal/operators/skipUntil.ts", "node_modules/rxjs/src/internal/operators/startWith.ts", "node_modules/rxjs/src/internal/operators/switchMap.ts", "node_modules/rxjs/src/internal/operators/takeUntil.ts", "node_modules/rxjs/src/internal/operators/takeWhile.ts", "node_modules/rxjs/src/internal/operators/tap.ts", "node_modules/rxjs/src/internal/operators/throttle.ts", "node_modules/rxjs/src/internal/operators/throttleTime.ts", "node_modules/rxjs/src/internal/operators/withLatestFrom.ts", "node_modules/rxjs/src/internal/operators/zip.ts", "node_modules/rxjs/src/internal/operators/zipWith.ts", "src/templates/assets/javascripts/browser/document/index.ts", "src/templates/assets/javascripts/browser/element/_/index.ts", "src/templates/assets/javascripts/browser/element/focus/index.ts", "src/templates/assets/javascripts/browser/element/hover/index.ts", "src/templates/assets/javascripts/browser/element/offset/_/index.ts", "src/templates/assets/javascripts/browser/element/offset/content/index.ts", "src/templates/assets/javascripts/utilities/h/index.ts", "src/templates/assets/javascripts/utilities/round/index.ts", "src/templates/assets/javascripts/browser/script/index.ts", "src/templates/assets/javascripts/browser/element/size/_/index.ts", "src/templates/assets/javascripts/browser/element/size/content/index.ts", "src/templates/assets/javascripts/browser/element/visibility/index.ts", "src/templates/assets/javascripts/browser/toggle/index.ts", "src/templates/assets/javascripts/browser/keyboard/index.ts", "src/templates/assets/javascripts/browser/location/_/index.ts", "src/templates/assets/javascripts/browser/location/hash/index.ts", "src/templates/assets/javascripts/browser/media/index.ts", "src/templates/assets/javascripts/browser/request/index.ts", "src/templates/assets/javascripts/browser/viewport/offset/index.ts", "src/templates/assets/javascripts/browser/viewport/size/index.ts", "src/templates/assets/javascripts/browser/viewport/_/index.ts", "src/templates/assets/javascripts/browser/viewport/at/index.ts", "src/templates/assets/javascripts/browser/worker/index.ts", "src/templates/assets/javascripts/_/index.ts", "src/templates/assets/javascripts/components/_/index.ts", "src/templates/assets/javascripts/components/announce/index.ts", "src/templates/assets/javascripts/components/consent/index.ts", "src/templates/assets/javascripts/templates/tooltip/index.tsx", "src/templates/assets/javascripts/templates/annotation/index.tsx", "src/templates/assets/javascripts/templates/clipboard/index.tsx", "src/templates/assets/javascripts/templates/search/index.tsx", "src/templates/assets/javascripts/templates/source/index.tsx", "src/templates/assets/javascripts/templates/tabbed/index.tsx", "src/templates/assets/javascripts/templates/table/index.tsx", "src/templates/assets/javascripts/templates/version/index.tsx", "src/templates/assets/javascripts/components/tooltip/index.ts", "src/templates/assets/javascripts/components/content/annotation/_/index.ts", "src/templates/assets/javascripts/components/content/annotation/list/index.ts", "src/templates/assets/javascripts/components/content/annotation/block/index.ts", "src/templates/assets/javascripts/components/content/code/_/index.ts", "src/templates/assets/javascripts/components/content/details/index.ts", "src/templates/assets/javascripts/components/content/mermaid/index.css", "src/templates/assets/javascripts/components/content/mermaid/index.ts", "src/templates/assets/javascripts/components/content/table/index.ts", "src/templates/assets/javascripts/components/content/tabs/index.ts", "src/templates/assets/javascripts/components/content/_/index.ts", "src/templates/assets/javascripts/components/dialog/index.ts", "src/templates/assets/javascripts/components/header/_/index.ts", "src/templates/assets/javascripts/components/header/title/index.ts", "src/templates/assets/javascripts/components/main/index.ts", "src/templates/assets/javascripts/components/palette/index.ts", "src/templates/assets/javascripts/components/progress/index.ts", "src/templates/assets/javascripts/integrations/clipboard/index.ts", "src/templates/assets/javascripts/integrations/sitemap/index.ts", "src/templates/assets/javascripts/integrations/instant/index.ts", "src/templates/assets/javascripts/integrations/search/highlighter/index.ts", "src/templates/assets/javascripts/integrations/search/worker/message/index.ts", "src/templates/assets/javascripts/integrations/search/worker/_/index.ts", "src/templates/assets/javascripts/integrations/version/index.ts", "src/templates/assets/javascripts/components/search/query/index.ts", "src/templates/assets/javascripts/components/search/result/index.ts", "src/templates/assets/javascripts/components/search/share/index.ts", "src/templates/assets/javascripts/components/search/suggest/index.ts", "src/templates/assets/javascripts/components/search/_/index.ts", "src/templates/assets/javascripts/components/search/highlight/index.ts", "src/templates/assets/javascripts/components/sidebar/index.ts", "src/templates/assets/javascripts/components/source/facts/github/index.ts", "src/templates/assets/javascripts/components/source/facts/gitlab/index.ts", "src/templates/assets/javascripts/components/source/facts/_/index.ts", "src/templates/assets/javascripts/components/source/_/index.ts", "src/templates/assets/javascripts/components/tabs/index.ts", "src/templates/assets/javascripts/components/toc/index.ts", "src/templates/assets/javascripts/components/top/index.ts", "src/templates/assets/javascripts/patches/ellipsis/index.ts", "src/templates/assets/javascripts/patches/indeterminate/index.ts", "src/templates/assets/javascripts/patches/scrollfix/index.ts", "src/templates/assets/javascripts/patches/scrolllock/index.ts", "src/templates/assets/javascripts/polyfills/index.ts"], + "sourcesContent": ["(function (global, factory) {\n typeof exports === 'object' && typeof module !== 'undefined' ? factory() :\n typeof define === 'function' && define.amd ? define(factory) :\n (factory());\n}(this, (function () { 'use strict';\n\n /**\n * Applies the :focus-visible polyfill at the given scope.\n * A scope in this case is either the top-level Document or a Shadow Root.\n *\n * @param {(Document|ShadowRoot)} scope\n * @see https://github.com/WICG/focus-visible\n */\n function applyFocusVisiblePolyfill(scope) {\n var hadKeyboardEvent = true;\n var hadFocusVisibleRecently = false;\n var hadFocusVisibleRecentlyTimeout = null;\n\n var inputTypesAllowlist = {\n text: true,\n search: true,\n url: true,\n tel: true,\n email: true,\n password: true,\n number: true,\n date: true,\n month: true,\n week: true,\n time: true,\n datetime: true,\n 'datetime-local': true\n };\n\n /**\n * Helper function for legacy browsers and iframes which sometimes focus\n * elements like document, body, and non-interactive SVG.\n * @param {Element} el\n */\n function isValidFocusTarget(el) {\n if (\n el &&\n el !== document &&\n el.nodeName !== 'HTML' &&\n el.nodeName !== 'BODY' &&\n 'classList' in el &&\n 'contains' in el.classList\n ) {\n return true;\n }\n return false;\n }\n\n /**\n * Computes whether the given element should automatically trigger the\n * `focus-visible` class being added, i.e. whether it should always match\n * `:focus-visible` when focused.\n * @param {Element} el\n * @return {boolean}\n */\n function focusTriggersKeyboardModality(el) {\n var type = el.type;\n var tagName = el.tagName;\n\n if (tagName === 'INPUT' && inputTypesAllowlist[type] && !el.readOnly) {\n return true;\n }\n\n if (tagName === 'TEXTAREA' && !el.readOnly) {\n return true;\n }\n\n if (el.isContentEditable) {\n return true;\n }\n\n return false;\n }\n\n /**\n * Add the `focus-visible` class to the given element if it was not added by\n * the author.\n * @param {Element} el\n */\n function addFocusVisibleClass(el) {\n if (el.classList.contains('focus-visible')) {\n return;\n }\n el.classList.add('focus-visible');\n el.setAttribute('data-focus-visible-added', '');\n }\n\n /**\n * Remove the `focus-visible` class from the given element if it was not\n * originally added by the author.\n * @param {Element} el\n */\n function removeFocusVisibleClass(el) {\n if (!el.hasAttribute('data-focus-visible-added')) {\n return;\n }\n el.classList.remove('focus-visible');\n el.removeAttribute('data-focus-visible-added');\n }\n\n /**\n * If the most recent user interaction was via the keyboard;\n * and the key press did not include a meta, alt/option, or control key;\n * then the modality is keyboard. Otherwise, the modality is not keyboard.\n * Apply `focus-visible` to any current active element and keep track\n * of our keyboard modality state with `hadKeyboardEvent`.\n * @param {KeyboardEvent} e\n */\n function onKeyDown(e) {\n if (e.metaKey || e.altKey || e.ctrlKey) {\n return;\n }\n\n if (isValidFocusTarget(scope.activeElement)) {\n addFocusVisibleClass(scope.activeElement);\n }\n\n hadKeyboardEvent = true;\n }\n\n /**\n * If at any point a user clicks with a pointing device, ensure that we change\n * the modality away from keyboard.\n * This avoids the situation where a user presses a key on an already focused\n * element, and then clicks on a different element, focusing it with a\n * pointing device, while we still think we're in keyboard modality.\n * @param {Event} e\n */\n function onPointerDown(e) {\n hadKeyboardEvent = false;\n }\n\n /**\n * On `focus`, add the `focus-visible` class to the target if:\n * - the target received focus as a result of keyboard navigation, or\n * - the event target is an element that will likely require interaction\n * via the keyboard (e.g. a text box)\n * @param {Event} e\n */\n function onFocus(e) {\n // Prevent IE from focusing the document or HTML element.\n if (!isValidFocusTarget(e.target)) {\n return;\n }\n\n if (hadKeyboardEvent || focusTriggersKeyboardModality(e.target)) {\n addFocusVisibleClass(e.target);\n }\n }\n\n /**\n * On `blur`, remove the `focus-visible` class from the target.\n * @param {Event} e\n */\n function onBlur(e) {\n if (!isValidFocusTarget(e.target)) {\n return;\n }\n\n if (\n e.target.classList.contains('focus-visible') ||\n e.target.hasAttribute('data-focus-visible-added')\n ) {\n // To detect a tab/window switch, we look for a blur event followed\n // rapidly by a visibility change.\n // If we don't see a visibility change within 100ms, it's probably a\n // regular focus change.\n hadFocusVisibleRecently = true;\n window.clearTimeout(hadFocusVisibleRecentlyTimeout);\n hadFocusVisibleRecentlyTimeout = window.setTimeout(function() {\n hadFocusVisibleRecently = false;\n }, 100);\n removeFocusVisibleClass(e.target);\n }\n }\n\n /**\n * If the user changes tabs, keep track of whether or not the previously\n * focused element had .focus-visible.\n * @param {Event} e\n */\n function onVisibilityChange(e) {\n if (document.visibilityState === 'hidden') {\n // If the tab becomes active again, the browser will handle calling focus\n // on the element (Safari actually calls it twice).\n // If this tab change caused a blur on an element with focus-visible,\n // re-apply the class when the user switches back to the tab.\n if (hadFocusVisibleRecently) {\n hadKeyboardEvent = true;\n }\n addInitialPointerMoveListeners();\n }\n }\n\n /**\n * Add a group of listeners to detect usage of any pointing devices.\n * These listeners will be added when the polyfill first loads, and anytime\n * the window is blurred, so that they are active when the window regains\n * focus.\n */\n function addInitialPointerMoveListeners() {\n document.addEventListener('mousemove', onInitialPointerMove);\n document.addEventListener('mousedown', onInitialPointerMove);\n document.addEventListener('mouseup', onInitialPointerMove);\n document.addEventListener('pointermove', onInitialPointerMove);\n document.addEventListener('pointerdown', onInitialPointerMove);\n document.addEventListener('pointerup', onInitialPointerMove);\n document.addEventListener('touchmove', onInitialPointerMove);\n document.addEventListener('touchstart', onInitialPointerMove);\n document.addEventListener('touchend', onInitialPointerMove);\n }\n\n function removeInitialPointerMoveListeners() {\n document.removeEventListener('mousemove', onInitialPointerMove);\n document.removeEventListener('mousedown', onInitialPointerMove);\n document.removeEventListener('mouseup', onInitialPointerMove);\n document.removeEventListener('pointermove', onInitialPointerMove);\n document.removeEventListener('pointerdown', onInitialPointerMove);\n document.removeEventListener('pointerup', onInitialPointerMove);\n document.removeEventListener('touchmove', onInitialPointerMove);\n document.removeEventListener('touchstart', onInitialPointerMove);\n document.removeEventListener('touchend', onInitialPointerMove);\n }\n\n /**\n * When the polfyill first loads, assume the user is in keyboard modality.\n * If any event is received from a pointing device (e.g. mouse, pointer,\n * touch), turn off keyboard modality.\n * This accounts for situations where focus enters the page from the URL bar.\n * @param {Event} e\n */\n function onInitialPointerMove(e) {\n // Work around a Safari quirk that fires a mousemove on whenever the\n // window blurs, even if you're tabbing out of the page. \u00AF\\_(\u30C4)_/\u00AF\n if (e.target.nodeName && e.target.nodeName.toLowerCase() === 'html') {\n return;\n }\n\n hadKeyboardEvent = false;\n removeInitialPointerMoveListeners();\n }\n\n // For some kinds of state, we are interested in changes at the global scope\n // only. For example, global pointer input, global key presses and global\n // visibility change should affect the state at every scope:\n document.addEventListener('keydown', onKeyDown, true);\n document.addEventListener('mousedown', onPointerDown, true);\n document.addEventListener('pointerdown', onPointerDown, true);\n document.addEventListener('touchstart', onPointerDown, true);\n document.addEventListener('visibilitychange', onVisibilityChange, true);\n\n addInitialPointerMoveListeners();\n\n // For focus and blur, we specifically care about state changes in the local\n // scope. This is because focus / blur events that originate from within a\n // shadow root are not re-dispatched from the host element if it was already\n // the active element in its own scope:\n scope.addEventListener('focus', onFocus, true);\n scope.addEventListener('blur', onBlur, true);\n\n // We detect that a node is a ShadowRoot by ensuring that it is a\n // DocumentFragment and also has a host property. This check covers native\n // implementation and polyfill implementation transparently. If we only cared\n // about the native implementation, we could just check if the scope was\n // an instance of a ShadowRoot.\n if (scope.nodeType === Node.DOCUMENT_FRAGMENT_NODE && scope.host) {\n // Since a ShadowRoot is a special kind of DocumentFragment, it does not\n // have a root element to add a class to. So, we add this attribute to the\n // host element instead:\n scope.host.setAttribute('data-js-focus-visible', '');\n } else if (scope.nodeType === Node.DOCUMENT_NODE) {\n document.documentElement.classList.add('js-focus-visible');\n document.documentElement.setAttribute('data-js-focus-visible', '');\n }\n }\n\n // It is important to wrap all references to global window and document in\n // these checks to support server-side rendering use cases\n // @see https://github.com/WICG/focus-visible/issues/199\n if (typeof window !== 'undefined' && typeof document !== 'undefined') {\n // Make the polyfill helper globally available. This can be used as a signal\n // to interested libraries that wish to coordinate with the polyfill for e.g.,\n // applying the polyfill to a shadow root:\n window.applyFocusVisiblePolyfill = applyFocusVisiblePolyfill;\n\n // Notify interested libraries of the polyfill's presence, in case the\n // polyfill was loaded lazily:\n var event;\n\n try {\n event = new CustomEvent('focus-visible-polyfill-ready');\n } catch (error) {\n // IE11 does not support using CustomEvent as a constructor directly:\n event = document.createEvent('CustomEvent');\n event.initCustomEvent('focus-visible-polyfill-ready', false, false, {});\n }\n\n window.dispatchEvent(event);\n }\n\n if (typeof document !== 'undefined') {\n // Apply the polyfill to the global document, so that no JavaScript\n // coordination is required to use the polyfill in the top-level document:\n applyFocusVisiblePolyfill(document);\n }\n\n})));\n", "/*!\n * clipboard.js v2.0.11\n * https://clipboardjs.com/\n *\n * Licensed MIT \u00A9 Zeno Rocha\n */\n(function webpackUniversalModuleDefinition(root, factory) {\n\tif(typeof exports === 'object' && typeof module === 'object')\n\t\tmodule.exports = factory();\n\telse if(typeof define === 'function' && define.amd)\n\t\tdefine([], factory);\n\telse if(typeof exports === 'object')\n\t\texports[\"ClipboardJS\"] = factory();\n\telse\n\t\troot[\"ClipboardJS\"] = factory();\n})(this, function() {\nreturn /******/ (function() { // webpackBootstrap\n/******/ \tvar __webpack_modules__ = ({\n\n/***/ 686:\n/***/ (function(__unused_webpack_module, __webpack_exports__, __webpack_require__) {\n\n\"use strict\";\n\n// EXPORTS\n__webpack_require__.d(__webpack_exports__, {\n \"default\": function() { return /* binding */ clipboard; }\n});\n\n// EXTERNAL MODULE: ./node_modules/tiny-emitter/index.js\nvar tiny_emitter = __webpack_require__(279);\nvar tiny_emitter_default = /*#__PURE__*/__webpack_require__.n(tiny_emitter);\n// EXTERNAL MODULE: ./node_modules/good-listener/src/listen.js\nvar listen = __webpack_require__(370);\nvar listen_default = /*#__PURE__*/__webpack_require__.n(listen);\n// EXTERNAL MODULE: ./node_modules/select/src/select.js\nvar src_select = __webpack_require__(817);\nvar select_default = /*#__PURE__*/__webpack_require__.n(src_select);\n;// CONCATENATED MODULE: ./src/common/command.js\n/**\n * Executes a given operation type.\n * @param {String} type\n * @return {Boolean}\n */\nfunction command(type) {\n try {\n return document.execCommand(type);\n } catch (err) {\n return false;\n }\n}\n;// CONCATENATED MODULE: ./src/actions/cut.js\n\n\n/**\n * Cut action wrapper.\n * @param {String|HTMLElement} target\n * @return {String}\n */\n\nvar ClipboardActionCut = function ClipboardActionCut(target) {\n var selectedText = select_default()(target);\n command('cut');\n return selectedText;\n};\n\n/* harmony default export */ var actions_cut = (ClipboardActionCut);\n;// CONCATENATED MODULE: ./src/common/create-fake-element.js\n/**\n * Creates a fake textarea element with a value.\n * @param {String} value\n * @return {HTMLElement}\n */\nfunction createFakeElement(value) {\n var isRTL = document.documentElement.getAttribute('dir') === 'rtl';\n var fakeElement = document.createElement('textarea'); // Prevent zooming on iOS\n\n fakeElement.style.fontSize = '12pt'; // Reset box model\n\n fakeElement.style.border = '0';\n fakeElement.style.padding = '0';\n fakeElement.style.margin = '0'; // Move element out of screen horizontally\n\n fakeElement.style.position = 'absolute';\n fakeElement.style[isRTL ? 'right' : 'left'] = '-9999px'; // Move element to the same position vertically\n\n var yPosition = window.pageYOffset || document.documentElement.scrollTop;\n fakeElement.style.top = \"\".concat(yPosition, \"px\");\n fakeElement.setAttribute('readonly', '');\n fakeElement.value = value;\n return fakeElement;\n}\n;// CONCATENATED MODULE: ./src/actions/copy.js\n\n\n\n/**\n * Create fake copy action wrapper using a fake element.\n * @param {String} target\n * @param {Object} options\n * @return {String}\n */\n\nvar fakeCopyAction = function fakeCopyAction(value, options) {\n var fakeElement = createFakeElement(value);\n options.container.appendChild(fakeElement);\n var selectedText = select_default()(fakeElement);\n command('copy');\n fakeElement.remove();\n return selectedText;\n};\n/**\n * Copy action wrapper.\n * @param {String|HTMLElement} target\n * @param {Object} options\n * @return {String}\n */\n\n\nvar ClipboardActionCopy = function ClipboardActionCopy(target) {\n var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {\n container: document.body\n };\n var selectedText = '';\n\n if (typeof target === 'string') {\n selectedText = fakeCopyAction(target, options);\n } else if (target instanceof HTMLInputElement && !['text', 'search', 'url', 'tel', 'password'].includes(target === null || target === void 0 ? void 0 : target.type)) {\n // If input type doesn't support `setSelectionRange`. Simulate it. https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setSelectionRange\n selectedText = fakeCopyAction(target.value, options);\n } else {\n selectedText = select_default()(target);\n command('copy');\n }\n\n return selectedText;\n};\n\n/* harmony default export */ var actions_copy = (ClipboardActionCopy);\n;// CONCATENATED MODULE: ./src/actions/default.js\nfunction _typeof(obj) { \"@babel/helpers - typeof\"; if (typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\") { _typeof = function _typeof(obj) { return typeof obj; }; } else { _typeof = function _typeof(obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol && obj !== Symbol.prototype ? \"symbol\" : typeof obj; }; } return _typeof(obj); }\n\n\n\n/**\n * Inner function which performs selection from either `text` or `target`\n * properties and then executes copy or cut operations.\n * @param {Object} options\n */\n\nvar ClipboardActionDefault = function ClipboardActionDefault() {\n var options = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};\n // Defines base properties passed from constructor.\n var _options$action = options.action,\n action = _options$action === void 0 ? 'copy' : _options$action,\n container = options.container,\n target = options.target,\n text = options.text; // Sets the `action` to be performed which can be either 'copy' or 'cut'.\n\n if (action !== 'copy' && action !== 'cut') {\n throw new Error('Invalid \"action\" value, use either \"copy\" or \"cut\"');\n } // Sets the `target` property using an element that will be have its content copied.\n\n\n if (target !== undefined) {\n if (target && _typeof(target) === 'object' && target.nodeType === 1) {\n if (action === 'copy' && target.hasAttribute('disabled')) {\n throw new Error('Invalid \"target\" attribute. Please use \"readonly\" instead of \"disabled\" attribute');\n }\n\n if (action === 'cut' && (target.hasAttribute('readonly') || target.hasAttribute('disabled'))) {\n throw new Error('Invalid \"target\" attribute. You can\\'t cut text from elements with \"readonly\" or \"disabled\" attributes');\n }\n } else {\n throw new Error('Invalid \"target\" value, use a valid Element');\n }\n } // Define selection strategy based on `text` property.\n\n\n if (text) {\n return actions_copy(text, {\n container: container\n });\n } // Defines which selection strategy based on `target` property.\n\n\n if (target) {\n return action === 'cut' ? actions_cut(target) : actions_copy(target, {\n container: container\n });\n }\n};\n\n/* harmony default export */ var actions_default = (ClipboardActionDefault);\n;// CONCATENATED MODULE: ./src/clipboard.js\nfunction clipboard_typeof(obj) { \"@babel/helpers - typeof\"; if (typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\") { clipboard_typeof = function _typeof(obj) { return typeof obj; }; } else { clipboard_typeof = function _typeof(obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol && obj !== Symbol.prototype ? \"symbol\" : typeof obj; }; } return clipboard_typeof(obj); }\n\nfunction _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError(\"Cannot call a class as a function\"); } }\n\nfunction _defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if (\"value\" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } }\n\nfunction _createClass(Constructor, protoProps, staticProps) { if (protoProps) _defineProperties(Constructor.prototype, protoProps); if (staticProps) _defineProperties(Constructor, staticProps); return Constructor; }\n\nfunction _inherits(subClass, superClass) { if (typeof superClass !== \"function\" && superClass !== null) { throw new TypeError(\"Super expression must either be null or a function\"); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, writable: true, configurable: true } }); if (superClass) _setPrototypeOf(subClass, superClass); }\n\nfunction _setPrototypeOf(o, p) { _setPrototypeOf = Object.setPrototypeOf || function _setPrototypeOf(o, p) { o.__proto__ = p; return o; }; return _setPrototypeOf(o, p); }\n\nfunction _createSuper(Derived) { var hasNativeReflectConstruct = _isNativeReflectConstruct(); return function _createSuperInternal() { var Super = _getPrototypeOf(Derived), result; if (hasNativeReflectConstruct) { var NewTarget = _getPrototypeOf(this).constructor; result = Reflect.construct(Super, arguments, NewTarget); } else { result = Super.apply(this, arguments); } return _possibleConstructorReturn(this, result); }; }\n\nfunction _possibleConstructorReturn(self, call) { if (call && (clipboard_typeof(call) === \"object\" || typeof call === \"function\")) { return call; } return _assertThisInitialized(self); }\n\nfunction _assertThisInitialized(self) { if (self === void 0) { throw new ReferenceError(\"this hasn't been initialised - super() hasn't been called\"); } return self; }\n\nfunction _isNativeReflectConstruct() { if (typeof Reflect === \"undefined\" || !Reflect.construct) return false; if (Reflect.construct.sham) return false; if (typeof Proxy === \"function\") return true; try { Date.prototype.toString.call(Reflect.construct(Date, [], function () {})); return true; } catch (e) { return false; } }\n\nfunction _getPrototypeOf(o) { _getPrototypeOf = Object.setPrototypeOf ? Object.getPrototypeOf : function _getPrototypeOf(o) { return o.__proto__ || Object.getPrototypeOf(o); }; return _getPrototypeOf(o); }\n\n\n\n\n\n\n/**\n * Helper function to retrieve attribute value.\n * @param {String} suffix\n * @param {Element} element\n */\n\nfunction getAttributeValue(suffix, element) {\n var attribute = \"data-clipboard-\".concat(suffix);\n\n if (!element.hasAttribute(attribute)) {\n return;\n }\n\n return element.getAttribute(attribute);\n}\n/**\n * Base class which takes one or more elements, adds event listeners to them,\n * and instantiates a new `ClipboardAction` on each click.\n */\n\n\nvar Clipboard = /*#__PURE__*/function (_Emitter) {\n _inherits(Clipboard, _Emitter);\n\n var _super = _createSuper(Clipboard);\n\n /**\n * @param {String|HTMLElement|HTMLCollection|NodeList} trigger\n * @param {Object} options\n */\n function Clipboard(trigger, options) {\n var _this;\n\n _classCallCheck(this, Clipboard);\n\n _this = _super.call(this);\n\n _this.resolveOptions(options);\n\n _this.listenClick(trigger);\n\n return _this;\n }\n /**\n * Defines if attributes would be resolved using internal setter functions\n * or custom functions that were passed in the constructor.\n * @param {Object} options\n */\n\n\n _createClass(Clipboard, [{\n key: \"resolveOptions\",\n value: function resolveOptions() {\n var options = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};\n this.action = typeof options.action === 'function' ? options.action : this.defaultAction;\n this.target = typeof options.target === 'function' ? options.target : this.defaultTarget;\n this.text = typeof options.text === 'function' ? options.text : this.defaultText;\n this.container = clipboard_typeof(options.container) === 'object' ? options.container : document.body;\n }\n /**\n * Adds a click event listener to the passed trigger.\n * @param {String|HTMLElement|HTMLCollection|NodeList} trigger\n */\n\n }, {\n key: \"listenClick\",\n value: function listenClick(trigger) {\n var _this2 = this;\n\n this.listener = listen_default()(trigger, 'click', function (e) {\n return _this2.onClick(e);\n });\n }\n /**\n * Defines a new `ClipboardAction` on each click event.\n * @param {Event} e\n */\n\n }, {\n key: \"onClick\",\n value: function onClick(e) {\n var trigger = e.delegateTarget || e.currentTarget;\n var action = this.action(trigger) || 'copy';\n var text = actions_default({\n action: action,\n container: this.container,\n target: this.target(trigger),\n text: this.text(trigger)\n }); // Fires an event based on the copy operation result.\n\n this.emit(text ? 'success' : 'error', {\n action: action,\n text: text,\n trigger: trigger,\n clearSelection: function clearSelection() {\n if (trigger) {\n trigger.focus();\n }\n\n window.getSelection().removeAllRanges();\n }\n });\n }\n /**\n * Default `action` lookup function.\n * @param {Element} trigger\n */\n\n }, {\n key: \"defaultAction\",\n value: function defaultAction(trigger) {\n return getAttributeValue('action', trigger);\n }\n /**\n * Default `target` lookup function.\n * @param {Element} trigger\n */\n\n }, {\n key: \"defaultTarget\",\n value: function defaultTarget(trigger) {\n var selector = getAttributeValue('target', trigger);\n\n if (selector) {\n return document.querySelector(selector);\n }\n }\n /**\n * Allow fire programmatically a copy action\n * @param {String|HTMLElement} target\n * @param {Object} options\n * @returns Text copied.\n */\n\n }, {\n key: \"defaultText\",\n\n /**\n * Default `text` lookup function.\n * @param {Element} trigger\n */\n value: function defaultText(trigger) {\n return getAttributeValue('text', trigger);\n }\n /**\n * Destroy lifecycle.\n */\n\n }, {\n key: \"destroy\",\n value: function destroy() {\n this.listener.destroy();\n }\n }], [{\n key: \"copy\",\n value: function copy(target) {\n var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {\n container: document.body\n };\n return actions_copy(target, options);\n }\n /**\n * Allow fire programmatically a cut action\n * @param {String|HTMLElement} target\n * @returns Text cutted.\n */\n\n }, {\n key: \"cut\",\n value: function cut(target) {\n return actions_cut(target);\n }\n /**\n * Returns the support of the given action, or all actions if no action is\n * given.\n * @param {String} [action]\n */\n\n }, {\n key: \"isSupported\",\n value: function isSupported() {\n var action = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : ['copy', 'cut'];\n var actions = typeof action === 'string' ? [action] : action;\n var support = !!document.queryCommandSupported;\n actions.forEach(function (action) {\n support = support && !!document.queryCommandSupported(action);\n });\n return support;\n }\n }]);\n\n return Clipboard;\n}((tiny_emitter_default()));\n\n/* harmony default export */ var clipboard = (Clipboard);\n\n/***/ }),\n\n/***/ 828:\n/***/ (function(module) {\n\nvar DOCUMENT_NODE_TYPE = 9;\n\n/**\n * A polyfill for Element.matches()\n */\nif (typeof Element !== 'undefined' && !Element.prototype.matches) {\n var proto = Element.prototype;\n\n proto.matches = proto.matchesSelector ||\n proto.mozMatchesSelector ||\n proto.msMatchesSelector ||\n proto.oMatchesSelector ||\n proto.webkitMatchesSelector;\n}\n\n/**\n * Finds the closest parent that matches a selector.\n *\n * @param {Element} element\n * @param {String} selector\n * @return {Function}\n */\nfunction closest (element, selector) {\n while (element && element.nodeType !== DOCUMENT_NODE_TYPE) {\n if (typeof element.matches === 'function' &&\n element.matches(selector)) {\n return element;\n }\n element = element.parentNode;\n }\n}\n\nmodule.exports = closest;\n\n\n/***/ }),\n\n/***/ 438:\n/***/ (function(module, __unused_webpack_exports, __webpack_require__) {\n\nvar closest = __webpack_require__(828);\n\n/**\n * Delegates event to a selector.\n *\n * @param {Element} element\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @param {Boolean} useCapture\n * @return {Object}\n */\nfunction _delegate(element, selector, type, callback, useCapture) {\n var listenerFn = listener.apply(this, arguments);\n\n element.addEventListener(type, listenerFn, useCapture);\n\n return {\n destroy: function() {\n element.removeEventListener(type, listenerFn, useCapture);\n }\n }\n}\n\n/**\n * Delegates event to a selector.\n *\n * @param {Element|String|Array} [elements]\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @param {Boolean} useCapture\n * @return {Object}\n */\nfunction delegate(elements, selector, type, callback, useCapture) {\n // Handle the regular Element usage\n if (typeof elements.addEventListener === 'function') {\n return _delegate.apply(null, arguments);\n }\n\n // Handle Element-less usage, it defaults to global delegation\n if (typeof type === 'function') {\n // Use `document` as the first parameter, then apply arguments\n // This is a short way to .unshift `arguments` without running into deoptimizations\n return _delegate.bind(null, document).apply(null, arguments);\n }\n\n // Handle Selector-based usage\n if (typeof elements === 'string') {\n elements = document.querySelectorAll(elements);\n }\n\n // Handle Array-like based usage\n return Array.prototype.map.call(elements, function (element) {\n return _delegate(element, selector, type, callback, useCapture);\n });\n}\n\n/**\n * Finds closest match and invokes callback.\n *\n * @param {Element} element\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @return {Function}\n */\nfunction listener(element, selector, type, callback) {\n return function(e) {\n e.delegateTarget = closest(e.target, selector);\n\n if (e.delegateTarget) {\n callback.call(element, e);\n }\n }\n}\n\nmodule.exports = delegate;\n\n\n/***/ }),\n\n/***/ 879:\n/***/ (function(__unused_webpack_module, exports) {\n\n/**\n * Check if argument is a HTML element.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.node = function(value) {\n return value !== undefined\n && value instanceof HTMLElement\n && value.nodeType === 1;\n};\n\n/**\n * Check if argument is a list of HTML elements.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.nodeList = function(value) {\n var type = Object.prototype.toString.call(value);\n\n return value !== undefined\n && (type === '[object NodeList]' || type === '[object HTMLCollection]')\n && ('length' in value)\n && (value.length === 0 || exports.node(value[0]));\n};\n\n/**\n * Check if argument is a string.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.string = function(value) {\n return typeof value === 'string'\n || value instanceof String;\n};\n\n/**\n * Check if argument is a function.\n *\n * @param {Object} value\n * @return {Boolean}\n */\nexports.fn = function(value) {\n var type = Object.prototype.toString.call(value);\n\n return type === '[object Function]';\n};\n\n\n/***/ }),\n\n/***/ 370:\n/***/ (function(module, __unused_webpack_exports, __webpack_require__) {\n\nvar is = __webpack_require__(879);\nvar delegate = __webpack_require__(438);\n\n/**\n * Validates all params and calls the right\n * listener function based on its target type.\n *\n * @param {String|HTMLElement|HTMLCollection|NodeList} target\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listen(target, type, callback) {\n if (!target && !type && !callback) {\n throw new Error('Missing required arguments');\n }\n\n if (!is.string(type)) {\n throw new TypeError('Second argument must be a String');\n }\n\n if (!is.fn(callback)) {\n throw new TypeError('Third argument must be a Function');\n }\n\n if (is.node(target)) {\n return listenNode(target, type, callback);\n }\n else if (is.nodeList(target)) {\n return listenNodeList(target, type, callback);\n }\n else if (is.string(target)) {\n return listenSelector(target, type, callback);\n }\n else {\n throw new TypeError('First argument must be a String, HTMLElement, HTMLCollection, or NodeList');\n }\n}\n\n/**\n * Adds an event listener to a HTML element\n * and returns a remove listener function.\n *\n * @param {HTMLElement} node\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenNode(node, type, callback) {\n node.addEventListener(type, callback);\n\n return {\n destroy: function() {\n node.removeEventListener(type, callback);\n }\n }\n}\n\n/**\n * Add an event listener to a list of HTML elements\n * and returns a remove listener function.\n *\n * @param {NodeList|HTMLCollection} nodeList\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenNodeList(nodeList, type, callback) {\n Array.prototype.forEach.call(nodeList, function(node) {\n node.addEventListener(type, callback);\n });\n\n return {\n destroy: function() {\n Array.prototype.forEach.call(nodeList, function(node) {\n node.removeEventListener(type, callback);\n });\n }\n }\n}\n\n/**\n * Add an event listener to a selector\n * and returns a remove listener function.\n *\n * @param {String} selector\n * @param {String} type\n * @param {Function} callback\n * @return {Object}\n */\nfunction listenSelector(selector, type, callback) {\n return delegate(document.body, selector, type, callback);\n}\n\nmodule.exports = listen;\n\n\n/***/ }),\n\n/***/ 817:\n/***/ (function(module) {\n\nfunction select(element) {\n var selectedText;\n\n if (element.nodeName === 'SELECT') {\n element.focus();\n\n selectedText = element.value;\n }\n else if (element.nodeName === 'INPUT' || element.nodeName === 'TEXTAREA') {\n var isReadOnly = element.hasAttribute('readonly');\n\n if (!isReadOnly) {\n element.setAttribute('readonly', '');\n }\n\n element.select();\n element.setSelectionRange(0, element.value.length);\n\n if (!isReadOnly) {\n element.removeAttribute('readonly');\n }\n\n selectedText = element.value;\n }\n else {\n if (element.hasAttribute('contenteditable')) {\n element.focus();\n }\n\n var selection = window.getSelection();\n var range = document.createRange();\n\n range.selectNodeContents(element);\n selection.removeAllRanges();\n selection.addRange(range);\n\n selectedText = selection.toString();\n }\n\n return selectedText;\n}\n\nmodule.exports = select;\n\n\n/***/ }),\n\n/***/ 279:\n/***/ (function(module) {\n\nfunction E () {\n // Keep this empty so it's easier to inherit from\n // (via https://github.com/lipsmack from https://github.com/scottcorgan/tiny-emitter/issues/3)\n}\n\nE.prototype = {\n on: function (name, callback, ctx) {\n var e = this.e || (this.e = {});\n\n (e[name] || (e[name] = [])).push({\n fn: callback,\n ctx: ctx\n });\n\n return this;\n },\n\n once: function (name, callback, ctx) {\n var self = this;\n function listener () {\n self.off(name, listener);\n callback.apply(ctx, arguments);\n };\n\n listener._ = callback\n return this.on(name, listener, ctx);\n },\n\n emit: function (name) {\n var data = [].slice.call(arguments, 1);\n var evtArr = ((this.e || (this.e = {}))[name] || []).slice();\n var i = 0;\n var len = evtArr.length;\n\n for (i; i < len; i++) {\n evtArr[i].fn.apply(evtArr[i].ctx, data);\n }\n\n return this;\n },\n\n off: function (name, callback) {\n var e = this.e || (this.e = {});\n var evts = e[name];\n var liveEvents = [];\n\n if (evts && callback) {\n for (var i = 0, len = evts.length; i < len; i++) {\n if (evts[i].fn !== callback && evts[i].fn._ !== callback)\n liveEvents.push(evts[i]);\n }\n }\n\n // Remove event from queue to prevent memory leak\n // Suggested by https://github.com/lazd\n // Ref: https://github.com/scottcorgan/tiny-emitter/commit/c6ebfaa9bc973b33d110a84a307742b7cf94c953#commitcomment-5024910\n\n (liveEvents.length)\n ? e[name] = liveEvents\n : delete e[name];\n\n return this;\n }\n};\n\nmodule.exports = E;\nmodule.exports.TinyEmitter = E;\n\n\n/***/ })\n\n/******/ \t});\n/************************************************************************/\n/******/ \t// The module cache\n/******/ \tvar __webpack_module_cache__ = {};\n/******/ \t\n/******/ \t// The require function\n/******/ \tfunction __webpack_require__(moduleId) {\n/******/ \t\t// Check if module is in cache\n/******/ \t\tif(__webpack_module_cache__[moduleId]) {\n/******/ \t\t\treturn __webpack_module_cache__[moduleId].exports;\n/******/ \t\t}\n/******/ \t\t// Create a new module (and put it into the cache)\n/******/ \t\tvar module = __webpack_module_cache__[moduleId] = {\n/******/ \t\t\t// no module.id needed\n/******/ \t\t\t// no module.loaded needed\n/******/ \t\t\texports: {}\n/******/ \t\t};\n/******/ \t\n/******/ \t\t// Execute the module function\n/******/ \t\t__webpack_modules__[moduleId](module, module.exports, __webpack_require__);\n/******/ \t\n/******/ \t\t// Return the exports of the module\n/******/ \t\treturn module.exports;\n/******/ \t}\n/******/ \t\n/************************************************************************/\n/******/ \t/* webpack/runtime/compat get default export */\n/******/ \t!function() {\n/******/ \t\t// getDefaultExport function for compatibility with non-harmony modules\n/******/ \t\t__webpack_require__.n = function(module) {\n/******/ \t\t\tvar getter = module && module.__esModule ?\n/******/ \t\t\t\tfunction() { return module['default']; } :\n/******/ \t\t\t\tfunction() { return module; };\n/******/ \t\t\t__webpack_require__.d(getter, { a: getter });\n/******/ \t\t\treturn getter;\n/******/ \t\t};\n/******/ \t}();\n/******/ \t\n/******/ \t/* webpack/runtime/define property getters */\n/******/ \t!function() {\n/******/ \t\t// define getter functions for harmony exports\n/******/ \t\t__webpack_require__.d = function(exports, definition) {\n/******/ \t\t\tfor(var key in definition) {\n/******/ \t\t\t\tif(__webpack_require__.o(definition, key) && !__webpack_require__.o(exports, key)) {\n/******/ \t\t\t\t\tObject.defineProperty(exports, key, { enumerable: true, get: definition[key] });\n/******/ \t\t\t\t}\n/******/ \t\t\t}\n/******/ \t\t};\n/******/ \t}();\n/******/ \t\n/******/ \t/* webpack/runtime/hasOwnProperty shorthand */\n/******/ \t!function() {\n/******/ \t\t__webpack_require__.o = function(obj, prop) { return Object.prototype.hasOwnProperty.call(obj, prop); }\n/******/ \t}();\n/******/ \t\n/************************************************************************/\n/******/ \t// module exports must be returned from runtime so entry inlining is disabled\n/******/ \t// startup\n/******/ \t// Load entry module and return exports\n/******/ \treturn __webpack_require__(686);\n/******/ })()\n.default;\n});", "/*!\n * escape-html\n * Copyright(c) 2012-2013 TJ Holowaychuk\n * Copyright(c) 2015 Andreas Lubbe\n * Copyright(c) 2015 Tiancheng \"Timothy\" Gu\n * MIT Licensed\n */\n\n'use strict';\n\n/**\n * Module variables.\n * @private\n */\n\nvar matchHtmlRegExp = /[\"'&<>]/;\n\n/**\n * Module exports.\n * @public\n */\n\nmodule.exports = escapeHtml;\n\n/**\n * Escape special characters in the given string of html.\n *\n * @param {string} string The string to escape for inserting into HTML\n * @return {string}\n * @public\n */\n\nfunction escapeHtml(string) {\n var str = '' + string;\n var match = matchHtmlRegExp.exec(str);\n\n if (!match) {\n return str;\n }\n\n var escape;\n var html = '';\n var index = 0;\n var lastIndex = 0;\n\n for (index = match.index; index < str.length; index++) {\n switch (str.charCodeAt(index)) {\n case 34: // \"\n escape = '"';\n break;\n case 38: // &\n escape = '&';\n break;\n case 39: // '\n escape = ''';\n break;\n case 60: // <\n escape = '<';\n break;\n case 62: // >\n escape = '>';\n break;\n default:\n continue;\n }\n\n if (lastIndex !== index) {\n html += str.substring(lastIndex, index);\n }\n\n lastIndex = index + 1;\n html += escape;\n }\n\n return lastIndex !== index\n ? html + str.substring(lastIndex, index)\n : html;\n}\n", "/*\n * Copyright (c) 2016-2024 Martin Donath \n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \"Software\"), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\nimport \"focus-visible\"\n\nimport {\n EMPTY,\n NEVER,\n Observable,\n Subject,\n defer,\n delay,\n filter,\n map,\n merge,\n mergeWith,\n shareReplay,\n switchMap\n} from \"rxjs\"\n\nimport { configuration, feature } from \"./_\"\nimport {\n at,\n getActiveElement,\n getOptionalElement,\n requestJSON,\n setLocation,\n setToggle,\n watchDocument,\n watchKeyboard,\n watchLocation,\n watchLocationTarget,\n watchMedia,\n watchPrint,\n watchScript,\n watchViewport\n} from \"./browser\"\nimport {\n getComponentElement,\n getComponentElements,\n mountAnnounce,\n mountBackToTop,\n mountConsent,\n mountContent,\n mountDialog,\n mountHeader,\n mountHeaderTitle,\n mountPalette,\n mountProgress,\n mountSearch,\n mountSearchHiglight,\n mountSidebar,\n mountSource,\n mountTableOfContents,\n mountTabs,\n watchHeader,\n watchMain\n} from \"./components\"\nimport {\n SearchIndex,\n setupClipboardJS,\n setupInstantNavigation,\n setupVersionSelector\n} from \"./integrations\"\nimport {\n patchEllipsis,\n patchIndeterminate,\n patchScrollfix,\n patchScrolllock\n} from \"./patches\"\nimport \"./polyfills\"\n\n/* ----------------------------------------------------------------------------\n * Functions - @todo refactor\n * ------------------------------------------------------------------------- */\n\n/**\n * Fetch search index\n *\n * @returns Search index observable\n */\nfunction fetchSearchIndex(): Observable {\n if (location.protocol === \"file:\") {\n return watchScript(\n `${new URL(\"search/search_index.js\", config.base)}`\n )\n .pipe(\n // @ts-ignore - @todo fix typings\n map(() => __index),\n shareReplay(1)\n )\n } else {\n return requestJSON(\n new URL(\"search/search_index.json\", config.base)\n )\n }\n}\n\n/* ----------------------------------------------------------------------------\n * Application\n * ------------------------------------------------------------------------- */\n\n/* Yay, JavaScript is available */\ndocument.documentElement.classList.remove(\"no-js\")\ndocument.documentElement.classList.add(\"js\")\n\n/* Set up navigation observables and subjects */\nconst document$ = watchDocument()\nconst location$ = watchLocation()\nconst target$ = watchLocationTarget(location$)\nconst keyboard$ = watchKeyboard()\n\n/* Set up media observables */\nconst viewport$ = watchViewport()\nconst tablet$ = watchMedia(\"(min-width: 960px)\")\nconst screen$ = watchMedia(\"(min-width: 1220px)\")\nconst print$ = watchPrint()\n\n/* Retrieve search index, if search is enabled */\nconst config = configuration()\nconst index$ = document.forms.namedItem(\"search\")\n ? fetchSearchIndex()\n : NEVER\n\n/* Set up Clipboard.js integration */\nconst alert$ = new Subject()\nsetupClipboardJS({ alert$ })\n\n/* Set up progress indicator */\nconst progress$ = new Subject()\n\n/* Set up instant navigation, if enabled */\nif (feature(\"navigation.instant\"))\n setupInstantNavigation({ location$, viewport$, progress$ })\n .subscribe(document$)\n\n/* Set up version selector */\nif (config.version?.provider === \"mike\")\n setupVersionSelector({ document$ })\n\n/* Always close drawer and search on navigation */\nmerge(location$, target$)\n .pipe(\n delay(125)\n )\n .subscribe(() => {\n setToggle(\"drawer\", false)\n setToggle(\"search\", false)\n })\n\n/* Set up global keyboard handlers */\nkeyboard$\n .pipe(\n filter(({ mode }) => mode === \"global\")\n )\n .subscribe(key => {\n switch (key.type) {\n\n /* Go to previous page */\n case \"p\":\n case \",\":\n const prev = getOptionalElement(\"link[rel=prev]\")\n if (typeof prev !== \"undefined\")\n setLocation(prev)\n break\n\n /* Go to next page */\n case \"n\":\n case \".\":\n const next = getOptionalElement(\"link[rel=next]\")\n if (typeof next !== \"undefined\")\n setLocation(next)\n break\n\n /* Expand navigation, see https://bit.ly/3ZjG5io */\n case \"Enter\":\n const active = getActiveElement()\n if (active instanceof HTMLLabelElement)\n active.click()\n }\n })\n\n/* Set up patches */\npatchEllipsis({ document$ })\npatchIndeterminate({ document$, tablet$ })\npatchScrollfix({ document$ })\npatchScrolllock({ viewport$, tablet$ })\n\n/* Set up header and main area observable */\nconst header$ = watchHeader(getComponentElement(\"header\"), { viewport$ })\nconst main$ = document$\n .pipe(\n map(() => getComponentElement(\"main\")),\n switchMap(el => watchMain(el, { viewport$, header$ })),\n shareReplay(1)\n )\n\n/* Set up control component observables */\nconst control$ = merge(\n\n /* Consent */\n ...getComponentElements(\"consent\")\n .map(el => mountConsent(el, { target$ })),\n\n /* Dialog */\n ...getComponentElements(\"dialog\")\n .map(el => mountDialog(el, { alert$ })),\n\n /* Header */\n ...getComponentElements(\"header\")\n .map(el => mountHeader(el, { viewport$, header$, main$ })),\n\n /* Color palette */\n ...getComponentElements(\"palette\")\n .map(el => mountPalette(el)),\n\n /* Progress bar */\n ...getComponentElements(\"progress\")\n .map(el => mountProgress(el, { progress$ })),\n\n /* Search */\n ...getComponentElements(\"search\")\n .map(el => mountSearch(el, { index$, keyboard$ })),\n\n /* Repository information */\n ...getComponentElements(\"source\")\n .map(el => mountSource(el))\n)\n\n/* Set up content component observables */\nconst content$ = defer(() => merge(\n\n /* Announcement bar */\n ...getComponentElements(\"announce\")\n .map(el => mountAnnounce(el)),\n\n /* Content */\n ...getComponentElements(\"content\")\n .map(el => mountContent(el, { viewport$, target$, print$ })),\n\n /* Search highlighting */\n ...getComponentElements(\"content\")\n .map(el => feature(\"search.highlight\")\n ? mountSearchHiglight(el, { index$, location$ })\n : EMPTY\n ),\n\n /* Header title */\n ...getComponentElements(\"header-title\")\n .map(el => mountHeaderTitle(el, { viewport$, header$ })),\n\n /* Sidebar */\n ...getComponentElements(\"sidebar\")\n .map(el => el.getAttribute(\"data-md-type\") === \"navigation\"\n ? at(screen$, () => mountSidebar(el, { viewport$, header$, main$ }))\n : at(tablet$, () => mountSidebar(el, { viewport$, header$, main$ }))\n ),\n\n /* Navigation tabs */\n ...getComponentElements(\"tabs\")\n .map(el => mountTabs(el, { viewport$, header$ })),\n\n /* Table of contents */\n ...getComponentElements(\"toc\")\n .map(el => mountTableOfContents(el, {\n viewport$, header$, main$, target$\n })),\n\n /* Back-to-top button */\n ...getComponentElements(\"top\")\n .map(el => mountBackToTop(el, { viewport$, header$, main$, target$ }))\n))\n\n/* Set up component observables */\nconst component$ = document$\n .pipe(\n switchMap(() => content$),\n mergeWith(control$),\n shareReplay(1)\n )\n\n/* Subscribe to all components */\ncomponent$.subscribe()\n\n/* ----------------------------------------------------------------------------\n * Exports\n * ------------------------------------------------------------------------- */\n\nwindow.document$ = document$ /* Document observable */\nwindow.location$ = location$ /* Location subject */\nwindow.target$ = target$ /* Location target observable */\nwindow.keyboard$ = keyboard$ /* Keyboard observable */\nwindow.viewport$ = viewport$ /* Viewport observable */\nwindow.tablet$ = tablet$ /* Media tablet observable */\nwindow.screen$ = screen$ /* Media screen observable */\nwindow.print$ = print$ /* Media print observable */\nwindow.alert$ = alert$ /* Alert subject */\nwindow.progress$ = progress$ /* Progress indicator subject */\nwindow.component$ = component$ /* Component observable */\n", "/*! *****************************************************************************\r\nCopyright (c) Microsoft Corporation.\r\n\r\nPermission to use, copy, modify, and/or distribute this software for any\r\npurpose with or without fee is hereby granted.\r\n\r\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH\r\nREGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY\r\nAND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,\r\nINDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM\r\nLOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR\r\nOTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR\r\nPERFORMANCE OF THIS SOFTWARE.\r\n***************************************************************************** */\r\n/* global Reflect, Promise */\r\n\r\nvar extendStatics = function(d, b) {\r\n extendStatics = Object.setPrototypeOf ||\r\n ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||\r\n function (d, b) { for (var p in b) if (Object.prototype.hasOwnProperty.call(b, p)) d[p] = b[p]; };\r\n return extendStatics(d, b);\r\n};\r\n\r\nexport function __extends(d, b) {\r\n if (typeof b !== \"function\" && b !== null)\r\n throw new TypeError(\"Class extends value \" + String(b) + \" is not a constructor or null\");\r\n extendStatics(d, b);\r\n function __() { this.constructor = d; }\r\n d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());\r\n}\r\n\r\nexport var __assign = function() {\r\n __assign = Object.assign || function __assign(t) {\r\n for (var s, i = 1, n = arguments.length; i < n; i++) {\r\n s = arguments[i];\r\n for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p)) t[p] = s[p];\r\n }\r\n return t;\r\n }\r\n return __assign.apply(this, arguments);\r\n}\r\n\r\nexport function __rest(s, e) {\r\n var t = {};\r\n for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p) && e.indexOf(p) < 0)\r\n t[p] = s[p];\r\n if (s != null && typeof Object.getOwnPropertySymbols === \"function\")\r\n for (var i = 0, p = Object.getOwnPropertySymbols(s); i < p.length; i++) {\r\n if (e.indexOf(p[i]) < 0 && Object.prototype.propertyIsEnumerable.call(s, p[i]))\r\n t[p[i]] = s[p[i]];\r\n }\r\n return t;\r\n}\r\n\r\nexport function __decorate(decorators, target, key, desc) {\r\n var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;\r\n if (typeof Reflect === \"object\" && typeof Reflect.decorate === \"function\") r = Reflect.decorate(decorators, target, key, desc);\r\n else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;\r\n return c > 3 && r && Object.defineProperty(target, key, r), r;\r\n}\r\n\r\nexport function __param(paramIndex, decorator) {\r\n return function (target, key) { decorator(target, key, paramIndex); }\r\n}\r\n\r\nexport function __metadata(metadataKey, metadataValue) {\r\n if (typeof Reflect === \"object\" && typeof Reflect.metadata === \"function\") return Reflect.metadata(metadataKey, metadataValue);\r\n}\r\n\r\nexport function __awaiter(thisArg, _arguments, P, generator) {\r\n function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }\r\n return new (P || (P = Promise))(function (resolve, reject) {\r\n function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }\r\n function rejected(value) { try { step(generator[\"throw\"](value)); } catch (e) { reject(e); } }\r\n function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }\r\n step((generator = generator.apply(thisArg, _arguments || [])).next());\r\n });\r\n}\r\n\r\nexport function __generator(thisArg, body) {\r\n var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;\r\n return g = { next: verb(0), \"throw\": verb(1), \"return\": verb(2) }, typeof Symbol === \"function\" && (g[Symbol.iterator] = function() { return this; }), g;\r\n function verb(n) { return function (v) { return step([n, v]); }; }\r\n function step(op) {\r\n if (f) throw new TypeError(\"Generator is already executing.\");\r\n while (_) try {\r\n if (f = 1, y && (t = op[0] & 2 ? y[\"return\"] : op[0] ? y[\"throw\"] || ((t = y[\"return\"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;\r\n if (y = 0, t) op = [op[0] & 2, t.value];\r\n switch (op[0]) {\r\n case 0: case 1: t = op; break;\r\n case 4: _.label++; return { value: op[1], done: false };\r\n case 5: _.label++; y = op[1]; op = [0]; continue;\r\n case 7: op = _.ops.pop(); _.trys.pop(); continue;\r\n default:\r\n if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }\r\n if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }\r\n if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }\r\n if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }\r\n if (t[2]) _.ops.pop();\r\n _.trys.pop(); continue;\r\n }\r\n op = body.call(thisArg, _);\r\n } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }\r\n if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };\r\n }\r\n}\r\n\r\nexport var __createBinding = Object.create ? (function(o, m, k, k2) {\r\n if (k2 === undefined) k2 = k;\r\n Object.defineProperty(o, k2, { enumerable: true, get: function() { return m[k]; } });\r\n}) : (function(o, m, k, k2) {\r\n if (k2 === undefined) k2 = k;\r\n o[k2] = m[k];\r\n});\r\n\r\nexport function __exportStar(m, o) {\r\n for (var p in m) if (p !== \"default\" && !Object.prototype.hasOwnProperty.call(o, p)) __createBinding(o, m, p);\r\n}\r\n\r\nexport function __values(o) {\r\n var s = typeof Symbol === \"function\" && Symbol.iterator, m = s && o[s], i = 0;\r\n if (m) return m.call(o);\r\n if (o && typeof o.length === \"number\") return {\r\n next: function () {\r\n if (o && i >= o.length) o = void 0;\r\n return { value: o && o[i++], done: !o };\r\n }\r\n };\r\n throw new TypeError(s ? \"Object is not iterable.\" : \"Symbol.iterator is not defined.\");\r\n}\r\n\r\nexport function __read(o, n) {\r\n var m = typeof Symbol === \"function\" && o[Symbol.iterator];\r\n if (!m) return o;\r\n var i = m.call(o), r, ar = [], e;\r\n try {\r\n while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);\r\n }\r\n catch (error) { e = { error: error }; }\r\n finally {\r\n try {\r\n if (r && !r.done && (m = i[\"return\"])) m.call(i);\r\n }\r\n finally { if (e) throw e.error; }\r\n }\r\n return ar;\r\n}\r\n\r\n/** @deprecated */\r\nexport function __spread() {\r\n for (var ar = [], i = 0; i < arguments.length; i++)\r\n ar = ar.concat(__read(arguments[i]));\r\n return ar;\r\n}\r\n\r\n/** @deprecated */\r\nexport function __spreadArrays() {\r\n for (var s = 0, i = 0, il = arguments.length; i < il; i++) s += arguments[i].length;\r\n for (var r = Array(s), k = 0, i = 0; i < il; i++)\r\n for (var a = arguments[i], j = 0, jl = a.length; j < jl; j++, k++)\r\n r[k] = a[j];\r\n return r;\r\n}\r\n\r\nexport function __spreadArray(to, from, pack) {\r\n if (pack || arguments.length === 2) for (var i = 0, l = from.length, ar; i < l; i++) {\r\n if (ar || !(i in from)) {\r\n if (!ar) ar = Array.prototype.slice.call(from, 0, i);\r\n ar[i] = from[i];\r\n }\r\n }\r\n return to.concat(ar || Array.prototype.slice.call(from));\r\n}\r\n\r\nexport function __await(v) {\r\n return this instanceof __await ? (this.v = v, this) : new __await(v);\r\n}\r\n\r\nexport function __asyncGenerator(thisArg, _arguments, generator) {\r\n if (!Symbol.asyncIterator) throw new TypeError(\"Symbol.asyncIterator is not defined.\");\r\n var g = generator.apply(thisArg, _arguments || []), i, q = [];\r\n return i = {}, verb(\"next\"), verb(\"throw\"), verb(\"return\"), i[Symbol.asyncIterator] = function () { return this; }, i;\r\n function verb(n) { if (g[n]) i[n] = function (v) { return new Promise(function (a, b) { q.push([n, v, a, b]) > 1 || resume(n, v); }); }; }\r\n function resume(n, v) { try { step(g[n](v)); } catch (e) { settle(q[0][3], e); } }\r\n function step(r) { r.value instanceof __await ? Promise.resolve(r.value.v).then(fulfill, reject) : settle(q[0][2], r); }\r\n function fulfill(value) { resume(\"next\", value); }\r\n function reject(value) { resume(\"throw\", value); }\r\n function settle(f, v) { if (f(v), q.shift(), q.length) resume(q[0][0], q[0][1]); }\r\n}\r\n\r\nexport function __asyncDelegator(o) {\r\n var i, p;\r\n return i = {}, verb(\"next\"), verb(\"throw\", function (e) { throw e; }), verb(\"return\"), i[Symbol.iterator] = function () { return this; }, i;\r\n function verb(n, f) { i[n] = o[n] ? function (v) { return (p = !p) ? { value: __await(o[n](v)), done: n === \"return\" } : f ? f(v) : v; } : f; }\r\n}\r\n\r\nexport function __asyncValues(o) {\r\n if (!Symbol.asyncIterator) throw new TypeError(\"Symbol.asyncIterator is not defined.\");\r\n var m = o[Symbol.asyncIterator], i;\r\n return m ? m.call(o) : (o = typeof __values === \"function\" ? __values(o) : o[Symbol.iterator](), i = {}, verb(\"next\"), verb(\"throw\"), verb(\"return\"), i[Symbol.asyncIterator] = function () { return this; }, i);\r\n function verb(n) { i[n] = o[n] && function (v) { return new Promise(function (resolve, reject) { v = o[n](v), settle(resolve, reject, v.done, v.value); }); }; }\r\n function settle(resolve, reject, d, v) { Promise.resolve(v).then(function(v) { resolve({ value: v, done: d }); }, reject); }\r\n}\r\n\r\nexport function __makeTemplateObject(cooked, raw) {\r\n if (Object.defineProperty) { Object.defineProperty(cooked, \"raw\", { value: raw }); } else { cooked.raw = raw; }\r\n return cooked;\r\n};\r\n\r\nvar __setModuleDefault = Object.create ? (function(o, v) {\r\n Object.defineProperty(o, \"default\", { enumerable: true, value: v });\r\n}) : function(o, v) {\r\n o[\"default\"] = v;\r\n};\r\n\r\nexport function __importStar(mod) {\r\n if (mod && mod.__esModule) return mod;\r\n var result = {};\r\n if (mod != null) for (var k in mod) if (k !== \"default\" && Object.prototype.hasOwnProperty.call(mod, k)) __createBinding(result, mod, k);\r\n __setModuleDefault(result, mod);\r\n return result;\r\n}\r\n\r\nexport function __importDefault(mod) {\r\n return (mod && mod.__esModule) ? mod : { default: mod };\r\n}\r\n\r\nexport function __classPrivateFieldGet(receiver, state, kind, f) {\r\n if (kind === \"a\" && !f) throw new TypeError(\"Private accessor was defined without a getter\");\r\n if (typeof state === \"function\" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError(\"Cannot read private member from an object whose class did not declare it\");\r\n return kind === \"m\" ? f : kind === \"a\" ? f.call(receiver) : f ? f.value : state.get(receiver);\r\n}\r\n\r\nexport function __classPrivateFieldSet(receiver, state, value, kind, f) {\r\n if (kind === \"m\") throw new TypeError(\"Private method is not writable\");\r\n if (kind === \"a\" && !f) throw new TypeError(\"Private accessor was defined without a setter\");\r\n if (typeof state === \"function\" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError(\"Cannot write private member to an object whose class did not declare it\");\r\n return (kind === \"a\" ? f.call(receiver, value) : f ? f.value = value : state.set(receiver, value)), value;\r\n}\r\n", "/**\n * Returns true if the object is a function.\n * @param value The value to check\n */\nexport function isFunction(value: any): value is (...args: any[]) => any {\n return typeof value === 'function';\n}\n", "/**\n * Used to create Error subclasses until the community moves away from ES5.\n *\n * This is because compiling from TypeScript down to ES5 has issues with subclassing Errors\n * as well as other built-in types: https://github.com/Microsoft/TypeScript/issues/12123\n *\n * @param createImpl A factory function to create the actual constructor implementation. The returned\n * function should be a named function that calls `_super` internally.\n */\nexport function createErrorClass(createImpl: (_super: any) => any): T {\n const _super = (instance: any) => {\n Error.call(instance);\n instance.stack = new Error().stack;\n };\n\n const ctorFunc = createImpl(_super);\n ctorFunc.prototype = Object.create(Error.prototype);\n ctorFunc.prototype.constructor = ctorFunc;\n return ctorFunc;\n}\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface UnsubscriptionError extends Error {\n readonly errors: any[];\n}\n\nexport interface UnsubscriptionErrorCtor {\n /**\n * @deprecated Internal implementation detail. Do not construct error instances.\n * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n */\n new (errors: any[]): UnsubscriptionError;\n}\n\n/**\n * An error thrown when one or more errors have occurred during the\n * `unsubscribe` of a {@link Subscription}.\n */\nexport const UnsubscriptionError: UnsubscriptionErrorCtor = createErrorClass(\n (_super) =>\n function UnsubscriptionErrorImpl(this: any, errors: (Error | string)[]) {\n _super(this);\n this.message = errors\n ? `${errors.length} errors occurred during unsubscription:\n${errors.map((err, i) => `${i + 1}) ${err.toString()}`).join('\\n ')}`\n : '';\n this.name = 'UnsubscriptionError';\n this.errors = errors;\n }\n);\n", "/**\n * Removes an item from an array, mutating it.\n * @param arr The array to remove the item from\n * @param item The item to remove\n */\nexport function arrRemove(arr: T[] | undefined | null, item: T) {\n if (arr) {\n const index = arr.indexOf(item);\n 0 <= index && arr.splice(index, 1);\n }\n}\n", "import { isFunction } from './util/isFunction';\nimport { UnsubscriptionError } from './util/UnsubscriptionError';\nimport { SubscriptionLike, TeardownLogic, Unsubscribable } from './types';\nimport { arrRemove } from './util/arrRemove';\n\n/**\n * Represents a disposable resource, such as the execution of an Observable. A\n * Subscription has one important method, `unsubscribe`, that takes no argument\n * and just disposes the resource held by the subscription.\n *\n * Additionally, subscriptions may be grouped together through the `add()`\n * method, which will attach a child Subscription to the current Subscription.\n * When a Subscription is unsubscribed, all its children (and its grandchildren)\n * will be unsubscribed as well.\n *\n * @class Subscription\n */\nexport class Subscription implements SubscriptionLike {\n /** @nocollapse */\n public static EMPTY = (() => {\n const empty = new Subscription();\n empty.closed = true;\n return empty;\n })();\n\n /**\n * A flag to indicate whether this Subscription has already been unsubscribed.\n */\n public closed = false;\n\n private _parentage: Subscription[] | Subscription | null = null;\n\n /**\n * The list of registered finalizers to execute upon unsubscription. Adding and removing from this\n * list occurs in the {@link #add} and {@link #remove} methods.\n */\n private _finalizers: Exclude[] | null = null;\n\n /**\n * @param initialTeardown A function executed first as part of the finalization\n * process that is kicked off when {@link #unsubscribe} is called.\n */\n constructor(private initialTeardown?: () => void) {}\n\n /**\n * Disposes the resources held by the subscription. May, for instance, cancel\n * an ongoing Observable execution or cancel any other type of work that\n * started when the Subscription was created.\n * @return {void}\n */\n unsubscribe(): void {\n let errors: any[] | undefined;\n\n if (!this.closed) {\n this.closed = true;\n\n // Remove this from it's parents.\n const { _parentage } = this;\n if (_parentage) {\n this._parentage = null;\n if (Array.isArray(_parentage)) {\n for (const parent of _parentage) {\n parent.remove(this);\n }\n } else {\n _parentage.remove(this);\n }\n }\n\n const { initialTeardown: initialFinalizer } = this;\n if (isFunction(initialFinalizer)) {\n try {\n initialFinalizer();\n } catch (e) {\n errors = e instanceof UnsubscriptionError ? e.errors : [e];\n }\n }\n\n const { _finalizers } = this;\n if (_finalizers) {\n this._finalizers = null;\n for (const finalizer of _finalizers) {\n try {\n execFinalizer(finalizer);\n } catch (err) {\n errors = errors ?? [];\n if (err instanceof UnsubscriptionError) {\n errors = [...errors, ...err.errors];\n } else {\n errors.push(err);\n }\n }\n }\n }\n\n if (errors) {\n throw new UnsubscriptionError(errors);\n }\n }\n }\n\n /**\n * Adds a finalizer to this subscription, so that finalization will be unsubscribed/called\n * when this subscription is unsubscribed. If this subscription is already {@link #closed},\n * because it has already been unsubscribed, then whatever finalizer is passed to it\n * will automatically be executed (unless the finalizer itself is also a closed subscription).\n *\n * Closed Subscriptions cannot be added as finalizers to any subscription. Adding a closed\n * subscription to a any subscription will result in no operation. (A noop).\n *\n * Adding a subscription to itself, or adding `null` or `undefined` will not perform any\n * operation at all. (A noop).\n *\n * `Subscription` instances that are added to this instance will automatically remove themselves\n * if they are unsubscribed. Functions and {@link Unsubscribable} objects that you wish to remove\n * will need to be removed manually with {@link #remove}\n *\n * @param teardown The finalization logic to add to this subscription.\n */\n add(teardown: TeardownLogic): void {\n // Only add the finalizer if it's not undefined\n // and don't add a subscription to itself.\n if (teardown && teardown !== this) {\n if (this.closed) {\n // If this subscription is already closed,\n // execute whatever finalizer is handed to it automatically.\n execFinalizer(teardown);\n } else {\n if (teardown instanceof Subscription) {\n // We don't add closed subscriptions, and we don't add the same subscription\n // twice. Subscription unsubscribe is idempotent.\n if (teardown.closed || teardown._hasParent(this)) {\n return;\n }\n teardown._addParent(this);\n }\n (this._finalizers = this._finalizers ?? []).push(teardown);\n }\n }\n }\n\n /**\n * Checks to see if a this subscription already has a particular parent.\n * This will signal that this subscription has already been added to the parent in question.\n * @param parent the parent to check for\n */\n private _hasParent(parent: Subscription) {\n const { _parentage } = this;\n return _parentage === parent || (Array.isArray(_parentage) && _parentage.includes(parent));\n }\n\n /**\n * Adds a parent to this subscription so it can be removed from the parent if it\n * unsubscribes on it's own.\n *\n * NOTE: THIS ASSUMES THAT {@link _hasParent} HAS ALREADY BEEN CHECKED.\n * @param parent The parent subscription to add\n */\n private _addParent(parent: Subscription) {\n const { _parentage } = this;\n this._parentage = Array.isArray(_parentage) ? (_parentage.push(parent), _parentage) : _parentage ? [_parentage, parent] : parent;\n }\n\n /**\n * Called on a child when it is removed via {@link #remove}.\n * @param parent The parent to remove\n */\n private _removeParent(parent: Subscription) {\n const { _parentage } = this;\n if (_parentage === parent) {\n this._parentage = null;\n } else if (Array.isArray(_parentage)) {\n arrRemove(_parentage, parent);\n }\n }\n\n /**\n * Removes a finalizer from this subscription that was previously added with the {@link #add} method.\n *\n * Note that `Subscription` instances, when unsubscribed, will automatically remove themselves\n * from every other `Subscription` they have been added to. This means that using the `remove` method\n * is not a common thing and should be used thoughtfully.\n *\n * If you add the same finalizer instance of a function or an unsubscribable object to a `Subscription` instance\n * more than once, you will need to call `remove` the same number of times to remove all instances.\n *\n * All finalizer instances are removed to free up memory upon unsubscription.\n *\n * @param teardown The finalizer to remove from this subscription\n */\n remove(teardown: Exclude): void {\n const { _finalizers } = this;\n _finalizers && arrRemove(_finalizers, teardown);\n\n if (teardown instanceof Subscription) {\n teardown._removeParent(this);\n }\n }\n}\n\nexport const EMPTY_SUBSCRIPTION = Subscription.EMPTY;\n\nexport function isSubscription(value: any): value is Subscription {\n return (\n value instanceof Subscription ||\n (value && 'closed' in value && isFunction(value.remove) && isFunction(value.add) && isFunction(value.unsubscribe))\n );\n}\n\nfunction execFinalizer(finalizer: Unsubscribable | (() => void)) {\n if (isFunction(finalizer)) {\n finalizer();\n } else {\n finalizer.unsubscribe();\n }\n}\n", "import { Subscriber } from './Subscriber';\nimport { ObservableNotification } from './types';\n\n/**\n * The {@link GlobalConfig} object for RxJS. It is used to configure things\n * like how to react on unhandled errors.\n */\nexport const config: GlobalConfig = {\n onUnhandledError: null,\n onStoppedNotification: null,\n Promise: undefined,\n useDeprecatedSynchronousErrorHandling: false,\n useDeprecatedNextContext: false,\n};\n\n/**\n * The global configuration object for RxJS, used to configure things\n * like how to react on unhandled errors. Accessible via {@link config}\n * object.\n */\nexport interface GlobalConfig {\n /**\n * A registration point for unhandled errors from RxJS. These are errors that\n * cannot were not handled by consuming code in the usual subscription path. For\n * example, if you have this configured, and you subscribe to an observable without\n * providing an error handler, errors from that subscription will end up here. This\n * will _always_ be called asynchronously on another job in the runtime. This is because\n * we do not want errors thrown in this user-configured handler to interfere with the\n * behavior of the library.\n */\n onUnhandledError: ((err: any) => void) | null;\n\n /**\n * A registration point for notifications that cannot be sent to subscribers because they\n * have completed, errored or have been explicitly unsubscribed. By default, next, complete\n * and error notifications sent to stopped subscribers are noops. However, sometimes callers\n * might want a different behavior. For example, with sources that attempt to report errors\n * to stopped subscribers, a caller can configure RxJS to throw an unhandled error instead.\n * This will _always_ be called asynchronously on another job in the runtime. This is because\n * we do not want errors thrown in this user-configured handler to interfere with the\n * behavior of the library.\n */\n onStoppedNotification: ((notification: ObservableNotification, subscriber: Subscriber) => void) | null;\n\n /**\n * The promise constructor used by default for {@link Observable#toPromise toPromise} and {@link Observable#forEach forEach}\n * methods.\n *\n * @deprecated As of version 8, RxJS will no longer support this sort of injection of a\n * Promise constructor. If you need a Promise implementation other than native promises,\n * please polyfill/patch Promise as you see appropriate. Will be removed in v8.\n */\n Promise?: PromiseConstructorLike;\n\n /**\n * If true, turns on synchronous error rethrowing, which is a deprecated behavior\n * in v6 and higher. This behavior enables bad patterns like wrapping a subscribe\n * call in a try/catch block. It also enables producer interference, a nasty bug\n * where a multicast can be broken for all observers by a downstream consumer with\n * an unhandled error. DO NOT USE THIS FLAG UNLESS IT'S NEEDED TO BUY TIME\n * FOR MIGRATION REASONS.\n *\n * @deprecated As of version 8, RxJS will no longer support synchronous throwing\n * of unhandled errors. All errors will be thrown on a separate call stack to prevent bad\n * behaviors described above. Will be removed in v8.\n */\n useDeprecatedSynchronousErrorHandling: boolean;\n\n /**\n * If true, enables an as-of-yet undocumented feature from v5: The ability to access\n * `unsubscribe()` via `this` context in `next` functions created in observers passed\n * to `subscribe`.\n *\n * This is being removed because the performance was severely problematic, and it could also cause\n * issues when types other than POJOs are passed to subscribe as subscribers, as they will likely have\n * their `this` context overwritten.\n *\n * @deprecated As of version 8, RxJS will no longer support altering the\n * context of next functions provided as part of an observer to Subscribe. Instead,\n * you will have access to a subscription or a signal or token that will allow you to do things like\n * unsubscribe and test closed status. Will be removed in v8.\n */\n useDeprecatedNextContext: boolean;\n}\n", "import type { TimerHandle } from './timerHandle';\ntype SetTimeoutFunction = (handler: () => void, timeout?: number, ...args: any[]) => TimerHandle;\ntype ClearTimeoutFunction = (handle: TimerHandle) => void;\n\ninterface TimeoutProvider {\n setTimeout: SetTimeoutFunction;\n clearTimeout: ClearTimeoutFunction;\n delegate:\n | {\n setTimeout: SetTimeoutFunction;\n clearTimeout: ClearTimeoutFunction;\n }\n | undefined;\n}\n\nexport const timeoutProvider: TimeoutProvider = {\n // When accessing the delegate, use the variable rather than `this` so that\n // the functions can be called without being bound to the provider.\n setTimeout(handler: () => void, timeout?: number, ...args) {\n const { delegate } = timeoutProvider;\n if (delegate?.setTimeout) {\n return delegate.setTimeout(handler, timeout, ...args);\n }\n return setTimeout(handler, timeout, ...args);\n },\n clearTimeout(handle) {\n const { delegate } = timeoutProvider;\n return (delegate?.clearTimeout || clearTimeout)(handle as any);\n },\n delegate: undefined,\n};\n", "import { config } from '../config';\nimport { timeoutProvider } from '../scheduler/timeoutProvider';\n\n/**\n * Handles an error on another job either with the user-configured {@link onUnhandledError},\n * or by throwing it on that new job so it can be picked up by `window.onerror`, `process.on('error')`, etc.\n *\n * This should be called whenever there is an error that is out-of-band with the subscription\n * or when an error hits a terminal boundary of the subscription and no error handler was provided.\n *\n * @param err the error to report\n */\nexport function reportUnhandledError(err: any) {\n timeoutProvider.setTimeout(() => {\n const { onUnhandledError } = config;\n if (onUnhandledError) {\n // Execute the user-configured error handler.\n onUnhandledError(err);\n } else {\n // Throw so it is picked up by the runtime's uncaught error mechanism.\n throw err;\n }\n });\n}\n", "/* tslint:disable:no-empty */\nexport function noop() { }\n", "import { CompleteNotification, NextNotification, ErrorNotification } from './types';\n\n/**\n * A completion object optimized for memory use and created to be the\n * same \"shape\" as other notifications in v8.\n * @internal\n */\nexport const COMPLETE_NOTIFICATION = (() => createNotification('C', undefined, undefined) as CompleteNotification)();\n\n/**\n * Internal use only. Creates an optimized error notification that is the same \"shape\"\n * as other notifications.\n * @internal\n */\nexport function errorNotification(error: any): ErrorNotification {\n return createNotification('E', undefined, error) as any;\n}\n\n/**\n * Internal use only. Creates an optimized next notification that is the same \"shape\"\n * as other notifications.\n * @internal\n */\nexport function nextNotification(value: T) {\n return createNotification('N', value, undefined) as NextNotification;\n}\n\n/**\n * Ensures that all notifications created internally have the same \"shape\" in v8.\n *\n * TODO: This is only exported to support a crazy legacy test in `groupBy`.\n * @internal\n */\nexport function createNotification(kind: 'N' | 'E' | 'C', value: any, error: any) {\n return {\n kind,\n value,\n error,\n };\n}\n", "import { config } from '../config';\n\nlet context: { errorThrown: boolean; error: any } | null = null;\n\n/**\n * Handles dealing with errors for super-gross mode. Creates a context, in which\n * any synchronously thrown errors will be passed to {@link captureError}. Which\n * will record the error such that it will be rethrown after the call back is complete.\n * TODO: Remove in v8\n * @param cb An immediately executed function.\n */\nexport function errorContext(cb: () => void) {\n if (config.useDeprecatedSynchronousErrorHandling) {\n const isRoot = !context;\n if (isRoot) {\n context = { errorThrown: false, error: null };\n }\n cb();\n if (isRoot) {\n const { errorThrown, error } = context!;\n context = null;\n if (errorThrown) {\n throw error;\n }\n }\n } else {\n // This is the general non-deprecated path for everyone that\n // isn't crazy enough to use super-gross mode (useDeprecatedSynchronousErrorHandling)\n cb();\n }\n}\n\n/**\n * Captures errors only in super-gross mode.\n * @param err the error to capture\n */\nexport function captureError(err: any) {\n if (config.useDeprecatedSynchronousErrorHandling && context) {\n context.errorThrown = true;\n context.error = err;\n }\n}\n", "import { isFunction } from './util/isFunction';\nimport { Observer, ObservableNotification } from './types';\nimport { isSubscription, Subscription } from './Subscription';\nimport { config } from './config';\nimport { reportUnhandledError } from './util/reportUnhandledError';\nimport { noop } from './util/noop';\nimport { nextNotification, errorNotification, COMPLETE_NOTIFICATION } from './NotificationFactories';\nimport { timeoutProvider } from './scheduler/timeoutProvider';\nimport { captureError } from './util/errorContext';\n\n/**\n * Implements the {@link Observer} interface and extends the\n * {@link Subscription} class. While the {@link Observer} is the public API for\n * consuming the values of an {@link Observable}, all Observers get converted to\n * a Subscriber, in order to provide Subscription-like capabilities such as\n * `unsubscribe`. Subscriber is a common type in RxJS, and crucial for\n * implementing operators, but it is rarely used as a public API.\n *\n * @class Subscriber\n */\nexport class Subscriber extends Subscription implements Observer {\n /**\n * A static factory for a Subscriber, given a (potentially partial) definition\n * of an Observer.\n * @param next The `next` callback of an Observer.\n * @param error The `error` callback of an\n * Observer.\n * @param complete The `complete` callback of an\n * Observer.\n * @return A Subscriber wrapping the (partially defined)\n * Observer represented by the given arguments.\n * @nocollapse\n * @deprecated Do not use. Will be removed in v8. There is no replacement for this\n * method, and there is no reason to be creating instances of `Subscriber` directly.\n * If you have a specific use case, please file an issue.\n */\n static create(next?: (x?: T) => void, error?: (e?: any) => void, complete?: () => void): Subscriber {\n return new SafeSubscriber(next, error, complete);\n }\n\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n protected isStopped: boolean = false;\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n protected destination: Subscriber | Observer; // this `any` is the escape hatch to erase extra type param (e.g. R)\n\n /**\n * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n * There is no reason to directly create an instance of Subscriber. This type is exported for typings reasons.\n */\n constructor(destination?: Subscriber | Observer) {\n super();\n if (destination) {\n this.destination = destination;\n // Automatically chain subscriptions together here.\n // if destination is a Subscription, then it is a Subscriber.\n if (isSubscription(destination)) {\n destination.add(this);\n }\n } else {\n this.destination = EMPTY_OBSERVER;\n }\n }\n\n /**\n * The {@link Observer} callback to receive notifications of type `next` from\n * the Observable, with a value. The Observable may call this method 0 or more\n * times.\n * @param {T} [value] The `next` value.\n * @return {void}\n */\n next(value?: T): void {\n if (this.isStopped) {\n handleStoppedNotification(nextNotification(value), this);\n } else {\n this._next(value!);\n }\n }\n\n /**\n * The {@link Observer} callback to receive notifications of type `error` from\n * the Observable, with an attached `Error`. Notifies the Observer that\n * the Observable has experienced an error condition.\n * @param {any} [err] The `error` exception.\n * @return {void}\n */\n error(err?: any): void {\n if (this.isStopped) {\n handleStoppedNotification(errorNotification(err), this);\n } else {\n this.isStopped = true;\n this._error(err);\n }\n }\n\n /**\n * The {@link Observer} callback to receive a valueless notification of type\n * `complete` from the Observable. Notifies the Observer that the Observable\n * has finished sending push-based notifications.\n * @return {void}\n */\n complete(): void {\n if (this.isStopped) {\n handleStoppedNotification(COMPLETE_NOTIFICATION, this);\n } else {\n this.isStopped = true;\n this._complete();\n }\n }\n\n unsubscribe(): void {\n if (!this.closed) {\n this.isStopped = true;\n super.unsubscribe();\n this.destination = null!;\n }\n }\n\n protected _next(value: T): void {\n this.destination.next(value);\n }\n\n protected _error(err: any): void {\n try {\n this.destination.error(err);\n } finally {\n this.unsubscribe();\n }\n }\n\n protected _complete(): void {\n try {\n this.destination.complete();\n } finally {\n this.unsubscribe();\n }\n }\n}\n\n/**\n * This bind is captured here because we want to be able to have\n * compatibility with monoid libraries that tend to use a method named\n * `bind`. In particular, a library called Monio requires this.\n */\nconst _bind = Function.prototype.bind;\n\nfunction bind any>(fn: Fn, thisArg: any): Fn {\n return _bind.call(fn, thisArg);\n}\n\n/**\n * Internal optimization only, DO NOT EXPOSE.\n * @internal\n */\nclass ConsumerObserver implements Observer {\n constructor(private partialObserver: Partial>) {}\n\n next(value: T): void {\n const { partialObserver } = this;\n if (partialObserver.next) {\n try {\n partialObserver.next(value);\n } catch (error) {\n handleUnhandledError(error);\n }\n }\n }\n\n error(err: any): void {\n const { partialObserver } = this;\n if (partialObserver.error) {\n try {\n partialObserver.error(err);\n } catch (error) {\n handleUnhandledError(error);\n }\n } else {\n handleUnhandledError(err);\n }\n }\n\n complete(): void {\n const { partialObserver } = this;\n if (partialObserver.complete) {\n try {\n partialObserver.complete();\n } catch (error) {\n handleUnhandledError(error);\n }\n }\n }\n}\n\nexport class SafeSubscriber extends Subscriber {\n constructor(\n observerOrNext?: Partial> | ((value: T) => void) | null,\n error?: ((e?: any) => void) | null,\n complete?: (() => void) | null\n ) {\n super();\n\n let partialObserver: Partial>;\n if (isFunction(observerOrNext) || !observerOrNext) {\n // The first argument is a function, not an observer. The next\n // two arguments *could* be observers, or they could be empty.\n partialObserver = {\n next: (observerOrNext ?? undefined) as (((value: T) => void) | undefined),\n error: error ?? undefined,\n complete: complete ?? undefined,\n };\n } else {\n // The first argument is a partial observer.\n let context: any;\n if (this && config.useDeprecatedNextContext) {\n // This is a deprecated path that made `this.unsubscribe()` available in\n // next handler functions passed to subscribe. This only exists behind a flag\n // now, as it is *very* slow.\n context = Object.create(observerOrNext);\n context.unsubscribe = () => this.unsubscribe();\n partialObserver = {\n next: observerOrNext.next && bind(observerOrNext.next, context),\n error: observerOrNext.error && bind(observerOrNext.error, context),\n complete: observerOrNext.complete && bind(observerOrNext.complete, context),\n };\n } else {\n // The \"normal\" path. Just use the partial observer directly.\n partialObserver = observerOrNext;\n }\n }\n\n // Wrap the partial observer to ensure it's a full observer, and\n // make sure proper error handling is accounted for.\n this.destination = new ConsumerObserver(partialObserver);\n }\n}\n\nfunction handleUnhandledError(error: any) {\n if (config.useDeprecatedSynchronousErrorHandling) {\n captureError(error);\n } else {\n // Ideal path, we report this as an unhandled error,\n // which is thrown on a new call stack.\n reportUnhandledError(error);\n }\n}\n\n/**\n * An error handler used when no error handler was supplied\n * to the SafeSubscriber -- meaning no error handler was supplied\n * do the `subscribe` call on our observable.\n * @param err The error to handle\n */\nfunction defaultErrorHandler(err: any) {\n throw err;\n}\n\n/**\n * A handler for notifications that cannot be sent to a stopped subscriber.\n * @param notification The notification being sent\n * @param subscriber The stopped subscriber\n */\nfunction handleStoppedNotification(notification: ObservableNotification, subscriber: Subscriber) {\n const { onStoppedNotification } = config;\n onStoppedNotification && timeoutProvider.setTimeout(() => onStoppedNotification(notification, subscriber));\n}\n\n/**\n * The observer used as a stub for subscriptions where the user did not\n * pass any arguments to `subscribe`. Comes with the default error handling\n * behavior.\n */\nexport const EMPTY_OBSERVER: Readonly> & { closed: true } = {\n closed: true,\n next: noop,\n error: defaultErrorHandler,\n complete: noop,\n};\n", "/**\n * Symbol.observable or a string \"@@observable\". Used for interop\n *\n * @deprecated We will no longer be exporting this symbol in upcoming versions of RxJS.\n * Instead polyfill and use Symbol.observable directly *or* use https://www.npmjs.com/package/symbol-observable\n */\nexport const observable: string | symbol = (() => (typeof Symbol === 'function' && Symbol.observable) || '@@observable')();\n", "/**\n * This function takes one parameter and just returns it. Simply put,\n * this is like `(x: T): T => x`.\n *\n * ## Examples\n *\n * This is useful in some cases when using things like `mergeMap`\n *\n * ```ts\n * import { interval, take, map, range, mergeMap, identity } from 'rxjs';\n *\n * const source$ = interval(1000).pipe(take(5));\n *\n * const result$ = source$.pipe(\n * map(i => range(i)),\n * mergeMap(identity) // same as mergeMap(x => x)\n * );\n *\n * result$.subscribe({\n * next: console.log\n * });\n * ```\n *\n * Or when you want to selectively apply an operator\n *\n * ```ts\n * import { interval, take, identity } from 'rxjs';\n *\n * const shouldLimit = () => Math.random() < 0.5;\n *\n * const source$ = interval(1000);\n *\n * const result$ = source$.pipe(shouldLimit() ? take(5) : identity);\n *\n * result$.subscribe({\n * next: console.log\n * });\n * ```\n *\n * @param x Any value that is returned by this function\n * @returns The value passed as the first parameter to this function\n */\nexport function identity(x: T): T {\n return x;\n}\n", "import { identity } from './identity';\nimport { UnaryFunction } from '../types';\n\nexport function pipe(): typeof identity;\nexport function pipe(fn1: UnaryFunction): UnaryFunction;\nexport function pipe(fn1: UnaryFunction, fn2: UnaryFunction): UnaryFunction;\nexport function pipe(fn1: UnaryFunction, fn2: UnaryFunction, fn3: UnaryFunction): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction\n): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction,\n fn5: UnaryFunction\n): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction,\n fn5: UnaryFunction,\n fn6: UnaryFunction\n): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction,\n fn5: UnaryFunction,\n fn6: UnaryFunction,\n fn7: UnaryFunction\n): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction,\n fn5: UnaryFunction,\n fn6: UnaryFunction,\n fn7: UnaryFunction,\n fn8: UnaryFunction\n): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction,\n fn5: UnaryFunction,\n fn6: UnaryFunction,\n fn7: UnaryFunction,\n fn8: UnaryFunction,\n fn9: UnaryFunction\n): UnaryFunction;\nexport function pipe(\n fn1: UnaryFunction,\n fn2: UnaryFunction,\n fn3: UnaryFunction,\n fn4: UnaryFunction,\n fn5: UnaryFunction,\n fn6: UnaryFunction,\n fn7: UnaryFunction,\n fn8: UnaryFunction,\n fn9: UnaryFunction,\n ...fns: UnaryFunction[]\n): UnaryFunction;\n\n/**\n * pipe() can be called on one or more functions, each of which can take one argument (\"UnaryFunction\")\n * and uses it to return a value.\n * It returns a function that takes one argument, passes it to the first UnaryFunction, and then\n * passes the result to the next one, passes that result to the next one, and so on. \n */\nexport function pipe(...fns: Array>): UnaryFunction {\n return pipeFromArray(fns);\n}\n\n/** @internal */\nexport function pipeFromArray(fns: Array>): UnaryFunction {\n if (fns.length === 0) {\n return identity as UnaryFunction;\n }\n\n if (fns.length === 1) {\n return fns[0];\n }\n\n return function piped(input: T): R {\n return fns.reduce((prev: any, fn: UnaryFunction) => fn(prev), input as any);\n };\n}\n", "import { Operator } from './Operator';\nimport { SafeSubscriber, Subscriber } from './Subscriber';\nimport { isSubscription, Subscription } from './Subscription';\nimport { TeardownLogic, OperatorFunction, Subscribable, Observer } from './types';\nimport { observable as Symbol_observable } from './symbol/observable';\nimport { pipeFromArray } from './util/pipe';\nimport { config } from './config';\nimport { isFunction } from './util/isFunction';\nimport { errorContext } from './util/errorContext';\n\n/**\n * A representation of any set of values over any amount of time. This is the most basic building block\n * of RxJS.\n *\n * @class Observable\n */\nexport class Observable implements Subscribable {\n /**\n * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n */\n source: Observable | undefined;\n\n /**\n * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n */\n operator: Operator | undefined;\n\n /**\n * @constructor\n * @param {Function} subscribe the function that is called when the Observable is\n * initially subscribed to. This function is given a Subscriber, to which new values\n * can be `next`ed, or an `error` method can be called to raise an error, or\n * `complete` can be called to notify of a successful completion.\n */\n constructor(subscribe?: (this: Observable, subscriber: Subscriber) => TeardownLogic) {\n if (subscribe) {\n this._subscribe = subscribe;\n }\n }\n\n // HACK: Since TypeScript inherits static properties too, we have to\n // fight against TypeScript here so Subject can have a different static create signature\n /**\n * Creates a new Observable by calling the Observable constructor\n * @owner Observable\n * @method create\n * @param {Function} subscribe? the subscriber function to be passed to the Observable constructor\n * @return {Observable} a new observable\n * @nocollapse\n * @deprecated Use `new Observable()` instead. Will be removed in v8.\n */\n static create: (...args: any[]) => any = (subscribe?: (subscriber: Subscriber) => TeardownLogic) => {\n return new Observable(subscribe);\n };\n\n /**\n * Creates a new Observable, with this Observable instance as the source, and the passed\n * operator defined as the new observable's operator.\n * @method lift\n * @param operator the operator defining the operation to take on the observable\n * @return a new observable with the Operator applied\n * @deprecated Internal implementation detail, do not use directly. Will be made internal in v8.\n * If you have implemented an operator using `lift`, it is recommended that you create an\n * operator by simply returning `new Observable()` directly. See \"Creating new operators from\n * scratch\" section here: https://rxjs.dev/guide/operators\n */\n lift(operator?: Operator): Observable {\n const observable = new Observable();\n observable.source = this;\n observable.operator = operator;\n return observable;\n }\n\n subscribe(observerOrNext?: Partial> | ((value: T) => void)): Subscription;\n /** @deprecated Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments */\n subscribe(next?: ((value: T) => void) | null, error?: ((error: any) => void) | null, complete?: (() => void) | null): Subscription;\n /**\n * Invokes an execution of an Observable and registers Observer handlers for notifications it will emit.\n *\n * Use it when you have all these Observables, but still nothing is happening.\n *\n * `subscribe` is not a regular operator, but a method that calls Observable's internal `subscribe` function. It\n * might be for example a function that you passed to Observable's constructor, but most of the time it is\n * a library implementation, which defines what will be emitted by an Observable, and when it be will emitted. This means\n * that calling `subscribe` is actually the moment when Observable starts its work, not when it is created, as it is often\n * the thought.\n *\n * Apart from starting the execution of an Observable, this method allows you to listen for values\n * that an Observable emits, as well as for when it completes or errors. You can achieve this in two\n * of the following ways.\n *\n * The first way is creating an object that implements {@link Observer} interface. It should have methods\n * defined by that interface, but note that it should be just a regular JavaScript object, which you can create\n * yourself in any way you want (ES6 class, classic function constructor, object literal etc.). In particular, do\n * not attempt to use any RxJS implementation details to create Observers - you don't need them. Remember also\n * that your object does not have to implement all methods. If you find yourself creating a method that doesn't\n * do anything, you can simply omit it. Note however, if the `error` method is not provided and an error happens,\n * it will be thrown asynchronously. Errors thrown asynchronously cannot be caught using `try`/`catch`. Instead,\n * use the {@link onUnhandledError} configuration option or use a runtime handler (like `window.onerror` or\n * `process.on('error)`) to be notified of unhandled errors. Because of this, it's recommended that you provide\n * an `error` method to avoid missing thrown errors.\n *\n * The second way is to give up on Observer object altogether and simply provide callback functions in place of its methods.\n * This means you can provide three functions as arguments to `subscribe`, where the first function is equivalent\n * of a `next` method, the second of an `error` method and the third of a `complete` method. Just as in case of an Observer,\n * if you do not need to listen for something, you can omit a function by passing `undefined` or `null`,\n * since `subscribe` recognizes these functions by where they were placed in function call. When it comes\n * to the `error` function, as with an Observer, if not provided, errors emitted by an Observable will be thrown asynchronously.\n *\n * You can, however, subscribe with no parameters at all. This may be the case where you're not interested in terminal events\n * and you also handled emissions internally by using operators (e.g. using `tap`).\n *\n * Whichever style of calling `subscribe` you use, in both cases it returns a Subscription object.\n * This object allows you to call `unsubscribe` on it, which in turn will stop the work that an Observable does and will clean\n * up all resources that an Observable used. Note that cancelling a subscription will not call `complete` callback\n * provided to `subscribe` function, which is reserved for a regular completion signal that comes from an Observable.\n *\n * Remember that callbacks provided to `subscribe` are not guaranteed to be called asynchronously.\n * It is an Observable itself that decides when these functions will be called. For example {@link of}\n * by default emits all its values synchronously. Always check documentation for how given Observable\n * will behave when subscribed and if its default behavior can be modified with a `scheduler`.\n *\n * #### Examples\n *\n * Subscribe with an {@link guide/observer Observer}\n *\n * ```ts\n * import { of } from 'rxjs';\n *\n * const sumObserver = {\n * sum: 0,\n * next(value) {\n * console.log('Adding: ' + value);\n * this.sum = this.sum + value;\n * },\n * error() {\n * // We actually could just remove this method,\n * // since we do not really care about errors right now.\n * },\n * complete() {\n * console.log('Sum equals: ' + this.sum);\n * }\n * };\n *\n * of(1, 2, 3) // Synchronously emits 1, 2, 3 and then completes.\n * .subscribe(sumObserver);\n *\n * // Logs:\n * // 'Adding: 1'\n * // 'Adding: 2'\n * // 'Adding: 3'\n * // 'Sum equals: 6'\n * ```\n *\n * Subscribe with functions ({@link deprecations/subscribe-arguments deprecated})\n *\n * ```ts\n * import { of } from 'rxjs'\n *\n * let sum = 0;\n *\n * of(1, 2, 3).subscribe(\n * value => {\n * console.log('Adding: ' + value);\n * sum = sum + value;\n * },\n * undefined,\n * () => console.log('Sum equals: ' + sum)\n * );\n *\n * // Logs:\n * // 'Adding: 1'\n * // 'Adding: 2'\n * // 'Adding: 3'\n * // 'Sum equals: 6'\n * ```\n *\n * Cancel a subscription\n *\n * ```ts\n * import { interval } from 'rxjs';\n *\n * const subscription = interval(1000).subscribe({\n * next(num) {\n * console.log(num)\n * },\n * complete() {\n * // Will not be called, even when cancelling subscription.\n * console.log('completed!');\n * }\n * });\n *\n * setTimeout(() => {\n * subscription.unsubscribe();\n * console.log('unsubscribed!');\n * }, 2500);\n *\n * // Logs:\n * // 0 after 1s\n * // 1 after 2s\n * // 'unsubscribed!' after 2.5s\n * ```\n *\n * @param {Observer|Function} observerOrNext (optional) Either an observer with methods to be called,\n * or the first of three possible handlers, which is the handler for each value emitted from the subscribed\n * Observable.\n * @param {Function} error (optional) A handler for a terminal event resulting from an error. If no error handler is provided,\n * the error will be thrown asynchronously as unhandled.\n * @param {Function} complete (optional) A handler for a terminal event resulting from successful completion.\n * @return {Subscription} a subscription reference to the registered handlers\n * @method subscribe\n */\n subscribe(\n observerOrNext?: Partial> | ((value: T) => void) | null,\n error?: ((error: any) => void) | null,\n complete?: (() => void) | null\n ): Subscription {\n const subscriber = isSubscriber(observerOrNext) ? observerOrNext : new SafeSubscriber(observerOrNext, error, complete);\n\n errorContext(() => {\n const { operator, source } = this;\n subscriber.add(\n operator\n ? // We're dealing with a subscription in the\n // operator chain to one of our lifted operators.\n operator.call(subscriber, source)\n : source\n ? // If `source` has a value, but `operator` does not, something that\n // had intimate knowledge of our API, like our `Subject`, must have\n // set it. We're going to just call `_subscribe` directly.\n this._subscribe(subscriber)\n : // In all other cases, we're likely wrapping a user-provided initializer\n // function, so we need to catch errors and handle them appropriately.\n this._trySubscribe(subscriber)\n );\n });\n\n return subscriber;\n }\n\n /** @internal */\n protected _trySubscribe(sink: Subscriber): TeardownLogic {\n try {\n return this._subscribe(sink);\n } catch (err) {\n // We don't need to return anything in this case,\n // because it's just going to try to `add()` to a subscription\n // above.\n sink.error(err);\n }\n }\n\n /**\n * Used as a NON-CANCELLABLE means of subscribing to an observable, for use with\n * APIs that expect promises, like `async/await`. You cannot unsubscribe from this.\n *\n * **WARNING**: Only use this with observables you *know* will complete. If the source\n * observable does not complete, you will end up with a promise that is hung up, and\n * potentially all of the state of an async function hanging out in memory. To avoid\n * this situation, look into adding something like {@link timeout}, {@link take},\n * {@link takeWhile}, or {@link takeUntil} amongst others.\n *\n * #### Example\n *\n * ```ts\n * import { interval, take } from 'rxjs';\n *\n * const source$ = interval(1000).pipe(take(4));\n *\n * async function getTotal() {\n * let total = 0;\n *\n * await source$.forEach(value => {\n * total += value;\n * console.log('observable -> ' + value);\n * });\n *\n * return total;\n * }\n *\n * getTotal().then(\n * total => console.log('Total: ' + total)\n * );\n *\n * // Expected:\n * // 'observable -> 0'\n * // 'observable -> 1'\n * // 'observable -> 2'\n * // 'observable -> 3'\n * // 'Total: 6'\n * ```\n *\n * @param next a handler for each value emitted by the observable\n * @return a promise that either resolves on observable completion or\n * rejects with the handled error\n */\n forEach(next: (value: T) => void): Promise;\n\n /**\n * @param next a handler for each value emitted by the observable\n * @param promiseCtor a constructor function used to instantiate the Promise\n * @return a promise that either resolves on observable completion or\n * rejects with the handled error\n * @deprecated Passing a Promise constructor will no longer be available\n * in upcoming versions of RxJS. This is because it adds weight to the library, for very\n * little benefit. If you need this functionality, it is recommended that you either\n * polyfill Promise, or you create an adapter to convert the returned native promise\n * to whatever promise implementation you wanted. Will be removed in v8.\n */\n forEach(next: (value: T) => void, promiseCtor: PromiseConstructorLike): Promise;\n\n forEach(next: (value: T) => void, promiseCtor?: PromiseConstructorLike): Promise {\n promiseCtor = getPromiseCtor(promiseCtor);\n\n return new promiseCtor((resolve, reject) => {\n const subscriber = new SafeSubscriber({\n next: (value) => {\n try {\n next(value);\n } catch (err) {\n reject(err);\n subscriber.unsubscribe();\n }\n },\n error: reject,\n complete: resolve,\n });\n this.subscribe(subscriber);\n }) as Promise;\n }\n\n /** @internal */\n protected _subscribe(subscriber: Subscriber): TeardownLogic {\n return this.source?.subscribe(subscriber);\n }\n\n /**\n * An interop point defined by the es7-observable spec https://github.com/zenparsing/es-observable\n * @method Symbol.observable\n * @return {Observable} this instance of the observable\n */\n [Symbol_observable]() {\n return this;\n }\n\n /* tslint:disable:max-line-length */\n pipe(): Observable;\n pipe(op1: OperatorFunction): Observable;\n pipe(op1: OperatorFunction, op2: OperatorFunction): Observable;\n pipe(op1: OperatorFunction, op2: OperatorFunction, op3: OperatorFunction): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction\n ): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction,\n op5: OperatorFunction\n ): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction,\n op5: OperatorFunction,\n op6: OperatorFunction\n ): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction,\n op5: OperatorFunction,\n op6: OperatorFunction,\n op7: OperatorFunction\n ): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction,\n op5: OperatorFunction,\n op6: OperatorFunction,\n op7: OperatorFunction,\n op8: OperatorFunction\n ): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction,\n op5: OperatorFunction,\n op6: OperatorFunction,\n op7: OperatorFunction,\n op8: OperatorFunction,\n op9: OperatorFunction\n ): Observable;\n pipe(\n op1: OperatorFunction,\n op2: OperatorFunction,\n op3: OperatorFunction,\n op4: OperatorFunction,\n op5: OperatorFunction,\n op6: OperatorFunction,\n op7: OperatorFunction,\n op8: OperatorFunction,\n op9: OperatorFunction,\n ...operations: OperatorFunction[]\n ): Observable;\n /* tslint:enable:max-line-length */\n\n /**\n * Used to stitch together functional operators into a chain.\n * @method pipe\n * @return {Observable} the Observable result of all of the operators having\n * been called in the order they were passed in.\n *\n * ## Example\n *\n * ```ts\n * import { interval, filter, map, scan } from 'rxjs';\n *\n * interval(1000)\n * .pipe(\n * filter(x => x % 2 === 0),\n * map(x => x + x),\n * scan((acc, x) => acc + x)\n * )\n * .subscribe(x => console.log(x));\n * ```\n */\n pipe(...operations: OperatorFunction[]): Observable {\n return pipeFromArray(operations)(this);\n }\n\n /* tslint:disable:max-line-length */\n /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n toPromise(): Promise;\n /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n toPromise(PromiseCtor: typeof Promise): Promise;\n /** @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise */\n toPromise(PromiseCtor: PromiseConstructorLike): Promise;\n /* tslint:enable:max-line-length */\n\n /**\n * Subscribe to this Observable and get a Promise resolving on\n * `complete` with the last emission (if any).\n *\n * **WARNING**: Only use this with observables you *know* will complete. If the source\n * observable does not complete, you will end up with a promise that is hung up, and\n * potentially all of the state of an async function hanging out in memory. To avoid\n * this situation, look into adding something like {@link timeout}, {@link take},\n * {@link takeWhile}, or {@link takeUntil} amongst others.\n *\n * @method toPromise\n * @param [promiseCtor] a constructor function used to instantiate\n * the Promise\n * @return A Promise that resolves with the last value emit, or\n * rejects on an error. If there were no emissions, Promise\n * resolves with undefined.\n * @deprecated Replaced with {@link firstValueFrom} and {@link lastValueFrom}. Will be removed in v8. Details: https://rxjs.dev/deprecations/to-promise\n */\n toPromise(promiseCtor?: PromiseConstructorLike): Promise {\n promiseCtor = getPromiseCtor(promiseCtor);\n\n return new promiseCtor((resolve, reject) => {\n let value: T | undefined;\n this.subscribe(\n (x: T) => (value = x),\n (err: any) => reject(err),\n () => resolve(value)\n );\n }) as Promise;\n }\n}\n\n/**\n * Decides between a passed promise constructor from consuming code,\n * A default configured promise constructor, and the native promise\n * constructor and returns it. If nothing can be found, it will throw\n * an error.\n * @param promiseCtor The optional promise constructor to passed by consuming code\n */\nfunction getPromiseCtor(promiseCtor: PromiseConstructorLike | undefined) {\n return promiseCtor ?? config.Promise ?? Promise;\n}\n\nfunction isObserver(value: any): value is Observer {\n return value && isFunction(value.next) && isFunction(value.error) && isFunction(value.complete);\n}\n\nfunction isSubscriber(value: any): value is Subscriber {\n return (value && value instanceof Subscriber) || (isObserver(value) && isSubscription(value));\n}\n", "import { Observable } from '../Observable';\nimport { Subscriber } from '../Subscriber';\nimport { OperatorFunction } from '../types';\nimport { isFunction } from './isFunction';\n\n/**\n * Used to determine if an object is an Observable with a lift function.\n */\nexport function hasLift(source: any): source is { lift: InstanceType['lift'] } {\n return isFunction(source?.lift);\n}\n\n/**\n * Creates an `OperatorFunction`. Used to define operators throughout the library in a concise way.\n * @param init The logic to connect the liftedSource to the subscriber at the moment of subscription.\n */\nexport function operate(\n init: (liftedSource: Observable, subscriber: Subscriber) => (() => void) | void\n): OperatorFunction {\n return (source: Observable) => {\n if (hasLift(source)) {\n return source.lift(function (this: Subscriber, liftedSource: Observable) {\n try {\n return init(liftedSource, this);\n } catch (err) {\n this.error(err);\n }\n });\n }\n throw new TypeError('Unable to lift unknown Observable type');\n };\n}\n", "import { Subscriber } from '../Subscriber';\n\n/**\n * Creates an instance of an `OperatorSubscriber`.\n * @param destination The downstream subscriber.\n * @param onNext Handles next values, only called if this subscriber is not stopped or closed. Any\n * error that occurs in this function is caught and sent to the `error` method of this subscriber.\n * @param onError Handles errors from the subscription, any errors that occur in this handler are caught\n * and send to the `destination` error handler.\n * @param onComplete Handles completion notification from the subscription. Any errors that occur in\n * this handler are sent to the `destination` error handler.\n * @param onFinalize Additional teardown logic here. This will only be called on teardown if the\n * subscriber itself is not already closed. This is called after all other teardown logic is executed.\n */\nexport function createOperatorSubscriber(\n destination: Subscriber,\n onNext?: (value: T) => void,\n onComplete?: () => void,\n onError?: (err: any) => void,\n onFinalize?: () => void\n): Subscriber {\n return new OperatorSubscriber(destination, onNext, onComplete, onError, onFinalize);\n}\n\n/**\n * A generic helper for allowing operators to be created with a Subscriber and\n * use closures to capture necessary state from the operator function itself.\n */\nexport class OperatorSubscriber extends Subscriber {\n /**\n * Creates an instance of an `OperatorSubscriber`.\n * @param destination The downstream subscriber.\n * @param onNext Handles next values, only called if this subscriber is not stopped or closed. Any\n * error that occurs in this function is caught and sent to the `error` method of this subscriber.\n * @param onError Handles errors from the subscription, any errors that occur in this handler are caught\n * and send to the `destination` error handler.\n * @param onComplete Handles completion notification from the subscription. Any errors that occur in\n * this handler are sent to the `destination` error handler.\n * @param onFinalize Additional finalization logic here. This will only be called on finalization if the\n * subscriber itself is not already closed. This is called after all other finalization logic is executed.\n * @param shouldUnsubscribe An optional check to see if an unsubscribe call should truly unsubscribe.\n * NOTE: This currently **ONLY** exists to support the strange behavior of {@link groupBy}, where unsubscription\n * to the resulting observable does not actually disconnect from the source if there are active subscriptions\n * to any grouped observable. (DO NOT EXPOSE OR USE EXTERNALLY!!!)\n */\n constructor(\n destination: Subscriber,\n onNext?: (value: T) => void,\n onComplete?: () => void,\n onError?: (err: any) => void,\n private onFinalize?: () => void,\n private shouldUnsubscribe?: () => boolean\n ) {\n // It's important - for performance reasons - that all of this class's\n // members are initialized and that they are always initialized in the same\n // order. This will ensure that all OperatorSubscriber instances have the\n // same hidden class in V8. This, in turn, will help keep the number of\n // hidden classes involved in property accesses within the base class as\n // low as possible. If the number of hidden classes involved exceeds four,\n // the property accesses will become megamorphic and performance penalties\n // will be incurred - i.e. inline caches won't be used.\n //\n // The reasons for ensuring all instances have the same hidden class are\n // further discussed in this blog post from Benedikt Meurer:\n // https://benediktmeurer.de/2018/03/23/impact-of-polymorphism-on-component-based-frameworks-like-react/\n super(destination);\n this._next = onNext\n ? function (this: OperatorSubscriber, value: T) {\n try {\n onNext(value);\n } catch (err) {\n destination.error(err);\n }\n }\n : super._next;\n this._error = onError\n ? function (this: OperatorSubscriber, err: any) {\n try {\n onError(err);\n } catch (err) {\n // Send any errors that occur down stream.\n destination.error(err);\n } finally {\n // Ensure finalization.\n this.unsubscribe();\n }\n }\n : super._error;\n this._complete = onComplete\n ? function (this: OperatorSubscriber) {\n try {\n onComplete();\n } catch (err) {\n // Send any errors that occur down stream.\n destination.error(err);\n } finally {\n // Ensure finalization.\n this.unsubscribe();\n }\n }\n : super._complete;\n }\n\n unsubscribe() {\n if (!this.shouldUnsubscribe || this.shouldUnsubscribe()) {\n const { closed } = this;\n super.unsubscribe();\n // Execute additional teardown if we have any and we didn't already do so.\n !closed && this.onFinalize?.();\n }\n }\n}\n", "import { Subscription } from '../Subscription';\n\ninterface AnimationFrameProvider {\n schedule(callback: FrameRequestCallback): Subscription;\n requestAnimationFrame: typeof requestAnimationFrame;\n cancelAnimationFrame: typeof cancelAnimationFrame;\n delegate:\n | {\n requestAnimationFrame: typeof requestAnimationFrame;\n cancelAnimationFrame: typeof cancelAnimationFrame;\n }\n | undefined;\n}\n\nexport const animationFrameProvider: AnimationFrameProvider = {\n // When accessing the delegate, use the variable rather than `this` so that\n // the functions can be called without being bound to the provider.\n schedule(callback) {\n let request = requestAnimationFrame;\n let cancel: typeof cancelAnimationFrame | undefined = cancelAnimationFrame;\n const { delegate } = animationFrameProvider;\n if (delegate) {\n request = delegate.requestAnimationFrame;\n cancel = delegate.cancelAnimationFrame;\n }\n const handle = request((timestamp) => {\n // Clear the cancel function. The request has been fulfilled, so\n // attempting to cancel the request upon unsubscription would be\n // pointless.\n cancel = undefined;\n callback(timestamp);\n });\n return new Subscription(() => cancel?.(handle));\n },\n requestAnimationFrame(...args) {\n const { delegate } = animationFrameProvider;\n return (delegate?.requestAnimationFrame || requestAnimationFrame)(...args);\n },\n cancelAnimationFrame(...args) {\n const { delegate } = animationFrameProvider;\n return (delegate?.cancelAnimationFrame || cancelAnimationFrame)(...args);\n },\n delegate: undefined,\n};\n", "import { createErrorClass } from './createErrorClass';\n\nexport interface ObjectUnsubscribedError extends Error {}\n\nexport interface ObjectUnsubscribedErrorCtor {\n /**\n * @deprecated Internal implementation detail. Do not construct error instances.\n * Cannot be tagged as internal: https://github.com/ReactiveX/rxjs/issues/6269\n */\n new (): ObjectUnsubscribedError;\n}\n\n/**\n * An error thrown when an action is invalid because the object has been\n * unsubscribed.\n *\n * @see {@link Subject}\n * @see {@link BehaviorSubject}\n *\n * @class ObjectUnsubscribedError\n */\nexport const ObjectUnsubscribedError: ObjectUnsubscribedErrorCtor = createErrorClass(\n (_super) =>\n function ObjectUnsubscribedErrorImpl(this: any) {\n _super(this);\n this.name = 'ObjectUnsubscribedError';\n this.message = 'object unsubscribed';\n }\n);\n", "import { Operator } from './Operator';\nimport { Observable } from './Observable';\nimport { Subscriber } from './Subscriber';\nimport { Subscription, EMPTY_SUBSCRIPTION } from './Subscription';\nimport { Observer, SubscriptionLike, TeardownLogic } from './types';\nimport { ObjectUnsubscribedError } from './util/ObjectUnsubscribedError';\nimport { arrRemove } from './util/arrRemove';\nimport { errorContext } from './util/errorContext';\n\n/**\n * A Subject is a special type of Observable that allows values to be\n * multicasted to many Observers. Subjects are like EventEmitters.\n *\n * Every Subject is an Observable and an Observer. You can subscribe to a\n * Subject, and you can call next to feed values as well as error and complete.\n */\nexport class Subject extends Observable implements SubscriptionLike {\n closed = false;\n\n private currentObservers: Observer[] | null = null;\n\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n observers: Observer[] = [];\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n isStopped = false;\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n hasError = false;\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n thrownError: any = null;\n\n /**\n * Creates a \"subject\" by basically gluing an observer to an observable.\n *\n * @nocollapse\n * @deprecated Recommended you do not use. Will be removed at some point in the future. Plans for replacement still under discussion.\n */\n static create: (...args: any[]) => any = (destination: Observer, source: Observable): AnonymousSubject => {\n return new AnonymousSubject(destination, source);\n };\n\n constructor() {\n // NOTE: This must be here to obscure Observable's constructor.\n super();\n }\n\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n lift(operator: Operator): Observable {\n const subject = new AnonymousSubject(this, this);\n subject.operator = operator as any;\n return subject as any;\n }\n\n /** @internal */\n protected _throwIfClosed() {\n if (this.closed) {\n throw new ObjectUnsubscribedError();\n }\n }\n\n next(value: T) {\n errorContext(() => {\n this._throwIfClosed();\n if (!this.isStopped) {\n if (!this.currentObservers) {\n this.currentObservers = Array.from(this.observers);\n }\n for (const observer of this.currentObservers) {\n observer.next(value);\n }\n }\n });\n }\n\n error(err: any) {\n errorContext(() => {\n this._throwIfClosed();\n if (!this.isStopped) {\n this.hasError = this.isStopped = true;\n this.thrownError = err;\n const { observers } = this;\n while (observers.length) {\n observers.shift()!.error(err);\n }\n }\n });\n }\n\n complete() {\n errorContext(() => {\n this._throwIfClosed();\n if (!this.isStopped) {\n this.isStopped = true;\n const { observers } = this;\n while (observers.length) {\n observers.shift()!.complete();\n }\n }\n });\n }\n\n unsubscribe() {\n this.isStopped = this.closed = true;\n this.observers = this.currentObservers = null!;\n }\n\n get observed() {\n return this.observers?.length > 0;\n }\n\n /** @internal */\n protected _trySubscribe(subscriber: Subscriber): TeardownLogic {\n this._throwIfClosed();\n return super._trySubscribe(subscriber);\n }\n\n /** @internal */\n protected _subscribe(subscriber: Subscriber): Subscription {\n this._throwIfClosed();\n this._checkFinalizedStatuses(subscriber);\n return this._innerSubscribe(subscriber);\n }\n\n /** @internal */\n protected _innerSubscribe(subscriber: Subscriber) {\n const { hasError, isStopped, observers } = this;\n if (hasError || isStopped) {\n return EMPTY_SUBSCRIPTION;\n }\n this.currentObservers = null;\n observers.push(subscriber);\n return new Subscription(() => {\n this.currentObservers = null;\n arrRemove(observers, subscriber);\n });\n }\n\n /** @internal */\n protected _checkFinalizedStatuses(subscriber: Subscriber) {\n const { hasError, thrownError, isStopped } = this;\n if (hasError) {\n subscriber.error(thrownError);\n } else if (isStopped) {\n subscriber.complete();\n }\n }\n\n /**\n * Creates a new Observable with this Subject as the source. You can do this\n * to create custom Observer-side logic of the Subject and conceal it from\n * code that uses the Observable.\n * @return {Observable} Observable that the Subject casts to\n */\n asObservable(): Observable {\n const observable: any = new Observable();\n observable.source = this;\n return observable;\n }\n}\n\n/**\n * @class AnonymousSubject\n */\nexport class AnonymousSubject extends Subject {\n constructor(\n /** @deprecated Internal implementation detail, do not use directly. Will be made internal in v8. */\n public destination?: Observer,\n source?: Observable\n ) {\n super();\n this.source = source;\n }\n\n next(value: T) {\n this.destination?.next?.(value);\n }\n\n error(err: any) {\n this.destination?.error?.(err);\n }\n\n complete() {\n this.destination?.complete?.();\n }\n\n /** @internal */\n protected _subscribe(subscriber: Subscriber): Subscription {\n return this.source?.subscribe(subscriber) ?? EMPTY_SUBSCRIPTION;\n }\n}\n", "import { TimestampProvider } from '../types';\n\ninterface DateTimestampProvider extends TimestampProvider {\n delegate: TimestampProvider | undefined;\n}\n\nexport const dateTimestampProvider: DateTimestampProvider = {\n now() {\n // Use the variable rather than `this` so that the function can be called\n // without being bound to the provider.\n return (dateTimestampProvider.delegate || Date).now();\n },\n delegate: undefined,\n};\n", "import { Subject } from './Subject';\nimport { TimestampProvider } from './types';\nimport { Subscriber } from './Subscriber';\nimport { Subscription } from './Subscription';\nimport { dateTimestampProvider } from './scheduler/dateTimestampProvider';\n\n/**\n * A variant of {@link Subject} that \"replays\" old values to new subscribers by emitting them when they first subscribe.\n *\n * `ReplaySubject` has an internal buffer that will store a specified number of values that it has observed. Like `Subject`,\n * `ReplaySubject` \"observes\" values by having them passed to its `next` method. When it observes a value, it will store that\n * value for a time determined by the configuration of the `ReplaySubject`, as passed to its constructor.\n *\n * When a new subscriber subscribes to the `ReplaySubject` instance, it will synchronously emit all values in its buffer in\n * a First-In-First-Out (FIFO) manner. The `ReplaySubject` will also complete, if it has observed completion; and it will\n * error if it has observed an error.\n *\n * There are two main configuration items to be concerned with:\n *\n * 1. `bufferSize` - This will determine how many items are stored in the buffer, defaults to infinite.\n * 2. `windowTime` - The amount of time to hold a value in the buffer before removing it from the buffer.\n *\n * Both configurations may exist simultaneously. So if you would like to buffer a maximum of 3 values, as long as the values\n * are less than 2 seconds old, you could do so with a `new ReplaySubject(3, 2000)`.\n *\n * ### Differences with BehaviorSubject\n *\n * `BehaviorSubject` is similar to `new ReplaySubject(1)`, with a couple of exceptions:\n *\n * 1. `BehaviorSubject` comes \"primed\" with a single value upon construction.\n * 2. `ReplaySubject` will replay values, even after observing an error, where `BehaviorSubject` will not.\n *\n * @see {@link Subject}\n * @see {@link BehaviorSubject}\n * @see {@link shareReplay}\n */\nexport class ReplaySubject extends Subject {\n private _buffer: (T | number)[] = [];\n private _infiniteTimeWindow = true;\n\n /**\n * @param bufferSize The size of the buffer to replay on subscription\n * @param windowTime The amount of time the buffered items will stay buffered\n * @param timestampProvider An object with a `now()` method that provides the current timestamp. This is used to\n * calculate the amount of time something has been buffered.\n */\n constructor(\n private _bufferSize = Infinity,\n private _windowTime = Infinity,\n private _timestampProvider: TimestampProvider = dateTimestampProvider\n ) {\n super();\n this._infiniteTimeWindow = _windowTime === Infinity;\n this._bufferSize = Math.max(1, _bufferSize);\n this._windowTime = Math.max(1, _windowTime);\n }\n\n next(value: T): void {\n const { isStopped, _buffer, _infiniteTimeWindow, _timestampProvider, _windowTime } = this;\n if (!isStopped) {\n _buffer.push(value);\n !_infiniteTimeWindow && _buffer.push(_timestampProvider.now() + _windowTime);\n }\n this._trimBuffer();\n super.next(value);\n }\n\n /** @internal */\n protected _subscribe(subscriber: Subscriber): Subscription {\n this._throwIfClosed();\n this._trimBuffer();\n\n const subscription = this._innerSubscribe(subscriber);\n\n const { _infiniteTimeWindow, _buffer } = this;\n // We use a copy here, so reentrant code does not mutate our array while we're\n // emitting it to a new subscriber.\n const copy = _buffer.slice();\n for (let i = 0; i < copy.length && !subscriber.closed; i += _infiniteTimeWindow ? 1 : 2) {\n subscriber.next(copy[i] as T);\n }\n\n this._checkFinalizedStatuses(subscriber);\n\n return subscription;\n }\n\n private _trimBuffer() {\n const { _bufferSize, _timestampProvider, _buffer, _infiniteTimeWindow } = this;\n // If we don't have an infinite buffer size, and we're over the length,\n // use splice to truncate the old buffer values off. Note that we have to\n // double the size for instances where we're not using an infinite time window\n // because we're storing the values and the timestamps in the same array.\n const adjustedBufferSize = (_infiniteTimeWindow ? 1 : 2) * _bufferSize;\n _bufferSize < Infinity && adjustedBufferSize < _buffer.length && _buffer.splice(0, _buffer.length - adjustedBufferSize);\n\n // Now, if we're not in an infinite time window, remove all values where the time is\n // older than what is allowed.\n if (!_infiniteTimeWindow) {\n const now = _timestampProvider.now();\n let last = 0;\n // Search the array for the first timestamp that isn't expired and\n // truncate the buffer up to that point.\n for (let i = 1; i < _buffer.length && (_buffer[i] as number) <= now; i += 2) {\n last = i;\n }\n last && _buffer.splice(0, last + 1);\n }\n }\n}\n", "import { Scheduler } from '../Scheduler';\nimport { Subscription } from '../Subscription';\nimport { SchedulerAction } from '../types';\n\n/**\n * A unit of work to be executed in a `scheduler`. An action is typically\n * created from within a {@link SchedulerLike} and an RxJS user does not need to concern\n * themselves about creating and manipulating an Action.\n *\n * ```ts\n * class Action extends Subscription {\n * new (scheduler: Scheduler, work: (state?: T) => void);\n * schedule(state?: T, delay: number = 0): Subscription;\n * }\n * ```\n *\n * @class Action\n */\nexport class Action extends Subscription {\n constructor(scheduler: Scheduler, work: (this: SchedulerAction, state?: T) => void) {\n super();\n }\n /**\n * Schedules this action on its parent {@link SchedulerLike} for execution. May be passed\n * some context object, `state`. May happen at some point in the future,\n * according to the `delay` parameter, if specified.\n * @param {T} [state] Some contextual data that the `work` function uses when\n * called by the Scheduler.\n * @param {number} [delay] Time to wait before executing the work, where the\n * time unit is implicit and defined by the Scheduler.\n * @return {void}\n */\n public schedule(state?: T, delay: number = 0): Subscription {\n return this;\n }\n}\n", "import type { TimerHandle } from './timerHandle';\ntype SetIntervalFunction = (handler: () => void, timeout?: number, ...args: any[]) => TimerHandle;\ntype ClearIntervalFunction = (handle: TimerHandle) => void;\n\ninterface IntervalProvider {\n setInterval: SetIntervalFunction;\n clearInterval: ClearIntervalFunction;\n delegate:\n | {\n setInterval: SetIntervalFunction;\n clearInterval: ClearIntervalFunction;\n }\n | undefined;\n}\n\nexport const intervalProvider: IntervalProvider = {\n // When accessing the delegate, use the variable rather than `this` so that\n // the functions can be called without being bound to the provider.\n setInterval(handler: () => void, timeout?: number, ...args) {\n const { delegate } = intervalProvider;\n if (delegate?.setInterval) {\n return delegate.setInterval(handler, timeout, ...args);\n }\n return setInterval(handler, timeout, ...args);\n },\n clearInterval(handle) {\n const { delegate } = intervalProvider;\n return (delegate?.clearInterval || clearInterval)(handle as any);\n },\n delegate: undefined,\n};\n", "import { Action } from './Action';\nimport { SchedulerAction } from '../types';\nimport { Subscription } from '../Subscription';\nimport { AsyncScheduler } from './AsyncScheduler';\nimport { intervalProvider } from './intervalProvider';\nimport { arrRemove } from '../util/arrRemove';\nimport { TimerHandle } from './timerHandle';\n\nexport class AsyncAction extends Action {\n public id: TimerHandle | undefined;\n public state?: T;\n // @ts-ignore: Property has no initializer and is not definitely assigned\n public delay: number;\n protected pending: boolean = false;\n\n constructor(protected scheduler: AsyncScheduler, protected work: (this: SchedulerAction, state?: T) => void) {\n super(scheduler, work);\n }\n\n public schedule(state?: T, delay: number = 0): Subscription {\n if (this.closed) {\n return this;\n }\n\n // Always replace the current state with the new state.\n this.state = state;\n\n const id = this.id;\n const scheduler = this.scheduler;\n\n //\n // Important implementation note:\n //\n // Actions only execute once by default, unless rescheduled from within the\n // scheduled callback. This allows us to implement single and repeat\n // actions via the same code path, without adding API surface area, as well\n // as mimic traditional recursion but across asynchronous boundaries.\n //\n // However, JS runtimes and timers distinguish between intervals achieved by\n // serial `setTimeout` calls vs. a single `setInterval` call. An interval of\n // serial `setTimeout` calls can be individually delayed, which delays\n // scheduling the next `setTimeout`, and so on. `setInterval` attempts to\n // guarantee the interval callback will be invoked more precisely to the\n // interval period, regardless of load.\n //\n // Therefore, we use `setInterval` to schedule single and repeat actions.\n // If the action reschedules itself with the same delay, the interval is not\n // canceled. If the action doesn't reschedule, or reschedules with a\n // different delay, the interval will be canceled after scheduled callback\n // execution.\n //\n if (id != null) {\n this.id = this.recycleAsyncId(scheduler, id, delay);\n }\n\n // Set the pending flag indicating that this action has been scheduled, or\n // has recursively rescheduled itself.\n this.pending = true;\n\n this.delay = delay;\n // If this action has already an async Id, don't request a new one.\n this.id = this.id ?? this.requestAsyncId(scheduler, this.id, delay);\n\n return this;\n }\n\n protected requestAsyncId(scheduler: AsyncScheduler, _id?: TimerHandle, delay: number = 0): TimerHandle {\n return intervalProvider.setInterval(scheduler.flush.bind(scheduler, this), delay);\n }\n\n protected recycleAsyncId(_scheduler: AsyncScheduler, id?: TimerHandle, delay: number | null = 0): TimerHandle | undefined {\n // If this action is rescheduled with the same delay time, don't clear the interval id.\n if (delay != null && this.delay === delay && this.pending === false) {\n return id;\n }\n // Otherwise, if the action's delay time is different from the current delay,\n // or the action has been rescheduled before it's executed, clear the interval id\n if (id != null) {\n intervalProvider.clearInterval(id);\n }\n\n return undefined;\n }\n\n /**\n * Immediately executes this action and the `work` it contains.\n * @return {any}\n */\n public execute(state: T, delay: number): any {\n if (this.closed) {\n return new Error('executing a cancelled action');\n }\n\n this.pending = false;\n const error = this._execute(state, delay);\n if (error) {\n return error;\n } else if (this.pending === false && this.id != null) {\n // Dequeue if the action didn't reschedule itself. Don't call\n // unsubscribe(), because the action could reschedule later.\n // For example:\n // ```\n // scheduler.schedule(function doWork(counter) {\n // /* ... I'm a busy worker bee ... */\n // var originalAction = this;\n // /* wait 100ms before rescheduling the action */\n // setTimeout(function () {\n // originalAction.schedule(counter + 1);\n // }, 100);\n // }, 1000);\n // ```\n this.id = this.recycleAsyncId(this.scheduler, this.id, null);\n }\n }\n\n protected _execute(state: T, _delay: number): any {\n let errored: boolean = false;\n let errorValue: any;\n try {\n this.work(state);\n } catch (e) {\n errored = true;\n // HACK: Since code elsewhere is relying on the \"truthiness\" of the\n // return here, we can't have it return \"\" or 0 or false.\n // TODO: Clean this up when we refactor schedulers mid-version-8 or so.\n errorValue = e ? e : new Error('Scheduled action threw falsy error');\n }\n if (errored) {\n this.unsubscribe();\n return errorValue;\n }\n }\n\n unsubscribe() {\n if (!this.closed) {\n const { id, scheduler } = this;\n const { actions } = scheduler;\n\n this.work = this.state = this.scheduler = null!;\n this.pending = false;\n\n arrRemove(actions, this);\n if (id != null) {\n this.id = this.recycleAsyncId(scheduler, id, null);\n }\n\n this.delay = null!;\n super.unsubscribe();\n }\n }\n}\n", "import { Action } from './scheduler/Action';\nimport { Subscription } from './Subscription';\nimport { SchedulerLike, SchedulerAction } from './types';\nimport { dateTimestampProvider } from './scheduler/dateTimestampProvider';\n\n/**\n * An execution context and a data structure to order tasks and schedule their\n * execution. Provides a notion of (potentially virtual) time, through the\n * `now()` getter method.\n *\n * Each unit of work in a Scheduler is called an `Action`.\n *\n * ```ts\n * class Scheduler {\n * now(): number;\n * schedule(work, delay?, state?): Subscription;\n * }\n * ```\n *\n * @class Scheduler\n * @deprecated Scheduler is an internal implementation detail of RxJS, and\n * should not be used directly. Rather, create your own class and implement\n * {@link SchedulerLike}. Will be made internal in v8.\n */\nexport class Scheduler implements SchedulerLike {\n public static now: () => number = dateTimestampProvider.now;\n\n constructor(private schedulerActionCtor: typeof Action, now: () => number = Scheduler.now) {\n this.now = now;\n }\n\n /**\n * A getter method that returns a number representing the current time\n * (at the time this function was called) according to the scheduler's own\n * internal clock.\n * @return {number} A number that represents the current time. May or may not\n * have a relation to wall-clock time. May or may not refer to a time unit\n * (e.g. milliseconds).\n */\n public now: () => number;\n\n /**\n * Schedules a function, `work`, for execution. May happen at some point in\n * the future, according to the `delay` parameter, if specified. May be passed\n * some context object, `state`, which will be passed to the `work` function.\n *\n * The given arguments will be processed an stored as an Action object in a\n * queue of actions.\n *\n * @param {function(state: ?T): ?Subscription} work A function representing a\n * task, or some unit of work to be executed by the Scheduler.\n * @param {number} [delay] Time to wait before executing the work, where the\n * time unit is implicit and defined by the Scheduler itself.\n * @param {T} [state] Some contextual data that the `work` function uses when\n * called by the Scheduler.\n * @return {Subscription} A subscription in order to be able to unsubscribe\n * the scheduled work.\n */\n public schedule(work: (this: SchedulerAction, state?: T) => void, delay: number = 0, state?: T): Subscription {\n return new this.schedulerActionCtor(this, work).schedule(state, delay);\n }\n}\n", "import { Scheduler } from '../Scheduler';\nimport { Action } from './Action';\nimport { AsyncAction } from './AsyncAction';\nimport { TimerHandle } from './timerHandle';\n\nexport class AsyncScheduler extends Scheduler {\n public actions: Array> = [];\n /**\n * A flag to indicate whether the Scheduler is currently executing a batch of\n * queued actions.\n * @type {boolean}\n * @internal\n */\n public _active: boolean = false;\n /**\n * An internal ID used to track the latest asynchronous task such as those\n * coming from `setTimeout`, `setInterval`, `requestAnimationFrame`, and\n * others.\n * @type {any}\n * @internal\n */\n public _scheduled: TimerHandle | undefined;\n\n constructor(SchedulerAction: typeof Action, now: () => number = Scheduler.now) {\n super(SchedulerAction, now);\n }\n\n public flush(action: AsyncAction): void {\n const { actions } = this;\n\n if (this._active) {\n actions.push(action);\n return;\n }\n\n let error: any;\n this._active = true;\n\n do {\n if ((error = action.execute(action.state, action.delay))) {\n break;\n }\n } while ((action = actions.shift()!)); // exhaust the scheduler queue\n\n this._active = false;\n\n if (error) {\n while ((action = actions.shift()!)) {\n action.unsubscribe();\n }\n throw error;\n }\n }\n}\n", "import { AsyncAction } from './AsyncAction';\nimport { AsyncScheduler } from './AsyncScheduler';\n\n/**\n *\n * Async Scheduler\n *\n * Schedule task as if you used setTimeout(task, duration)\n *\n * `async` scheduler schedules tasks asynchronously, by putting them on the JavaScript\n * event loop queue. It is best used to delay tasks in time or to schedule tasks repeating\n * in intervals.\n *\n * If you just want to \"defer\" task, that is to perform it right after currently\n * executing synchronous code ends (commonly achieved by `setTimeout(deferredTask, 0)`),\n * better choice will be the {@link asapScheduler} scheduler.\n *\n * ## Examples\n * Use async scheduler to delay task\n * ```ts\n * import { asyncScheduler } from 'rxjs';\n *\n * const task = () => console.log('it works!');\n *\n * asyncScheduler.schedule(task, 2000);\n *\n * // After 2 seconds logs:\n * // \"it works!\"\n * ```\n *\n * Use async scheduler to repeat task in intervals\n * ```ts\n * import { asyncScheduler } from 'rxjs';\n *\n * function task(state) {\n * console.log(state);\n * this.schedule(state + 1, 1000); // `this` references currently executing Action,\n * // which we reschedule with new state and delay\n * }\n *\n * asyncScheduler.schedule(task, 3000, 0);\n *\n * // Logs:\n * // 0 after 3s\n * // 1 after 4s\n * // 2 after 5s\n * // 3 after 6s\n * ```\n */\n\nexport const asyncScheduler = new AsyncScheduler(AsyncAction);\n\n/**\n * @deprecated Renamed to {@link asyncScheduler}. Will be removed in v8.\n */\nexport const async = asyncScheduler;\n", "import { AsyncAction } from './AsyncAction';\nimport { AnimationFrameScheduler } from './AnimationFrameScheduler';\nimport { SchedulerAction } from '../types';\nimport { animationFrameProvider } from './animationFrameProvider';\nimport { TimerHandle } from './timerHandle';\n\nexport class AnimationFrameAction extends AsyncAction {\n constructor(protected scheduler: AnimationFrameScheduler, protected work: (this: SchedulerAction, state?: T) => void) {\n super(scheduler, work);\n }\n\n protected requestAsyncId(scheduler: AnimationFrameScheduler, id?: TimerHandle, delay: number = 0): TimerHandle {\n // If delay is greater than 0, request as an async action.\n if (delay !== null && delay > 0) {\n return super.requestAsyncId(scheduler, id, delay);\n }\n // Push the action to the end of the scheduler queue.\n scheduler.actions.push(this);\n // If an animation frame has already been requested, don't request another\n // one. If an animation frame hasn't been requested yet, request one. Return\n // the current animation frame request id.\n return scheduler._scheduled || (scheduler._scheduled = animationFrameProvider.requestAnimationFrame(() => scheduler.flush(undefined)));\n }\n\n protected recycleAsyncId(scheduler: AnimationFrameScheduler, id?: TimerHandle, delay: number = 0): TimerHandle | undefined {\n // If delay exists and is greater than 0, or if the delay is null (the\n // action wasn't rescheduled) but was originally scheduled as an async\n // action, then recycle as an async action.\n if (delay != null ? delay > 0 : this.delay > 0) {\n return super.recycleAsyncId(scheduler, id, delay);\n }\n // If the scheduler queue has no remaining actions with the same async id,\n // cancel the requested animation frame and set the scheduled flag to\n // undefined so the next AnimationFrameAction will request its own.\n const { actions } = scheduler;\n if (id != null && actions[actions.length - 1]?.id !== id) {\n animationFrameProvider.cancelAnimationFrame(id as number);\n scheduler._scheduled = undefined;\n }\n // Return undefined so the action knows to request a new async id if it's rescheduled.\n return undefined;\n }\n}\n", "import { AsyncAction } from './AsyncAction';\nimport { AsyncScheduler } from './AsyncScheduler';\n\nexport class AnimationFrameScheduler extends AsyncScheduler {\n public flush(action?: AsyncAction): void {\n this._active = true;\n // The async id that effects a call to flush is stored in _scheduled.\n // Before executing an action, it's necessary to check the action's async\n // id to determine whether it's supposed to be executed in the current\n // flush.\n // Previous implementations of this method used a count to determine this,\n // but that was unsound, as actions that are unsubscribed - i.e. cancelled -\n // are removed from the actions array and that can shift actions that are\n // scheduled to be executed in a subsequent flush into positions at which\n // they are executed within the current flush.\n const flushId = this._scheduled;\n this._scheduled = undefined;\n\n const { actions } = this;\n let error: any;\n action = action || actions.shift()!;\n\n do {\n if ((error = action.execute(action.state, action.delay))) {\n break;\n }\n } while ((action = actions[0]) && action.id === flushId && actions.shift());\n\n this._active = false;\n\n if (error) {\n while ((action = actions[0]) && action.id === flushId && actions.shift()) {\n action.unsubscribe();\n }\n throw error;\n }\n }\n}\n", "import { AnimationFrameAction } from './AnimationFrameAction';\nimport { AnimationFrameScheduler } from './AnimationFrameScheduler';\n\n/**\n *\n * Animation Frame Scheduler\n *\n * Perform task when `window.requestAnimationFrame` would fire\n *\n * When `animationFrame` scheduler is used with delay, it will fall back to {@link asyncScheduler} scheduler\n * behaviour.\n *\n * Without delay, `animationFrame` scheduler can be used to create smooth browser animations.\n * It makes sure scheduled task will happen just before next browser content repaint,\n * thus performing animations as efficiently as possible.\n *\n * ## Example\n * Schedule div height animation\n * ```ts\n * // html:
\n * import { animationFrameScheduler } from 'rxjs';\n *\n * const div = document.querySelector('div');\n *\n * animationFrameScheduler.schedule(function(height) {\n * div.style.height = height + \"px\";\n *\n * this.schedule(height + 1); // `this` references currently executing Action,\n * // which we reschedule with new state\n * }, 0, 0);\n *\n * // You will see a div element growing in height\n * ```\n */\n\nexport const animationFrameScheduler = new AnimationFrameScheduler(AnimationFrameAction);\n\n/**\n * @deprecated Renamed to {@link animationFrameScheduler}. Will be removed in v8.\n */\nexport const animationFrame = animationFrameScheduler;\n", "import { Observable } from '../Observable';\nimport { SchedulerLike } from '../types';\n\n/**\n * A simple Observable that emits no items to the Observer and immediately\n * emits a complete notification.\n *\n * Just emits 'complete', and nothing else.\n *\n * ![](empty.png)\n *\n * A simple Observable that only emits the complete notification. It can be used\n * for composing with other Observables, such as in a {@link mergeMap}.\n *\n * ## Examples\n *\n * Log complete notification\n *\n * ```ts\n * import { EMPTY } from 'rxjs';\n *\n * EMPTY.subscribe({\n * next: () => console.log('Next'),\n * complete: () => console.log('Complete!')\n * });\n *\n * // Outputs\n * // Complete!\n * ```\n *\n * Emit the number 7, then complete\n *\n * ```ts\n * import { EMPTY, startWith } from 'rxjs';\n *\n * const result = EMPTY.pipe(startWith(7));\n * result.subscribe(x => console.log(x));\n *\n * // Outputs\n * // 7\n * ```\n *\n * Map and flatten only odd numbers to the sequence `'a'`, `'b'`, `'c'`\n *\n * ```ts\n * import { interval, mergeMap, of, EMPTY } from 'rxjs';\n *\n * const interval$ = interval(1000);\n * const result = interval$.pipe(\n * mergeMap(x => x % 2 === 1 ? of('a', 'b', 'c') : EMPTY),\n * );\n * result.subscribe(x => console.log(x));\n *\n * // Results in the following to the console:\n * // x is equal to the count on the interval, e.g. (0, 1, 2, 3, ...)\n * // x will occur every 1000ms\n * // if x % 2 is equal to 1, print a, b, c (each on its own)\n * // if x % 2 is not equal to 1, nothing will be output\n * ```\n *\n * @see {@link Observable}\n * @see {@link NEVER}\n * @see {@link of}\n * @see {@link throwError}\n */\nexport const EMPTY = new Observable((subscriber) => subscriber.complete());\n\n/**\n * @param scheduler A {@link SchedulerLike} to use for scheduling\n * the emission of the complete notification.\n * @deprecated Replaced with the {@link EMPTY} constant or {@link scheduled} (e.g. `scheduled([], scheduler)`). Will be removed in v8.\n */\nexport function empty(scheduler?: SchedulerLike) {\n return scheduler ? emptyScheduled(scheduler) : EMPTY;\n}\n\nfunction emptyScheduled(scheduler: SchedulerLike) {\n return new Observable((subscriber) => scheduler.schedule(() => subscriber.complete()));\n}\n", "import { SchedulerLike } from '../types';\nimport { isFunction } from './isFunction';\n\nexport function isScheduler(value: any): value is SchedulerLike {\n return value && isFunction(value.schedule);\n}\n", "import { SchedulerLike } from '../types';\nimport { isFunction } from './isFunction';\nimport { isScheduler } from './isScheduler';\n\nfunction last(arr: T[]): T | undefined {\n return arr[arr.length - 1];\n}\n\nexport function popResultSelector(args: any[]): ((...args: unknown[]) => unknown) | undefined {\n return isFunction(last(args)) ? args.pop() : undefined;\n}\n\nexport function popScheduler(args: any[]): SchedulerLike | undefined {\n return isScheduler(last(args)) ? args.pop() : undefined;\n}\n\nexport function popNumber(args: any[], defaultValue: number): number {\n return typeof last(args) === 'number' ? args.pop()! : defaultValue;\n}\n", "export const isArrayLike = ((x: any): x is ArrayLike => x && typeof x.length === 'number' && typeof x !== 'function');", "import { isFunction } from \"./isFunction\";\n\n/**\n * Tests to see if the object is \"thennable\".\n * @param value the object to test\n */\nexport function isPromise(value: any): value is PromiseLike {\n return isFunction(value?.then);\n}\n", "import { InteropObservable } from '../types';\nimport { observable as Symbol_observable } from '../symbol/observable';\nimport { isFunction } from './isFunction';\n\n/** Identifies an input as being Observable (but not necessary an Rx Observable) */\nexport function isInteropObservable(input: any): input is InteropObservable {\n return isFunction(input[Symbol_observable]);\n}\n", "import { isFunction } from './isFunction';\n\nexport function isAsyncIterable(obj: any): obj is AsyncIterable {\n return Symbol.asyncIterator && isFunction(obj?.[Symbol.asyncIterator]);\n}\n", "/**\n * Creates the TypeError to throw if an invalid object is passed to `from` or `scheduled`.\n * @param input The object that was passed.\n */\nexport function createInvalidObservableTypeError(input: any) {\n // TODO: We should create error codes that can be looked up, so this can be less verbose.\n return new TypeError(\n `You provided ${\n input !== null && typeof input === 'object' ? 'an invalid object' : `'${input}'`\n } where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.`\n );\n}\n", "export function getSymbolIterator(): symbol {\n if (typeof Symbol !== 'function' || !Symbol.iterator) {\n return '@@iterator' as any;\n }\n\n return Symbol.iterator;\n}\n\nexport const iterator = getSymbolIterator();\n", "import { iterator as Symbol_iterator } from '../symbol/iterator';\nimport { isFunction } from './isFunction';\n\n/** Identifies an input as being an Iterable */\nexport function isIterable(input: any): input is Iterable {\n return isFunction(input?.[Symbol_iterator]);\n}\n", "import { ReadableStreamLike } from '../types';\nimport { isFunction } from './isFunction';\n\nexport async function* readableStreamLikeToAsyncGenerator(readableStream: ReadableStreamLike): AsyncGenerator {\n const reader = readableStream.getReader();\n try {\n while (true) {\n const { value, done } = await reader.read();\n if (done) {\n return;\n }\n yield value!;\n }\n } finally {\n reader.releaseLock();\n }\n}\n\nexport function isReadableStreamLike(obj: any): obj is ReadableStreamLike {\n // We don't want to use instanceof checks because they would return\n // false for instances from another Realm, like an