Hierarchical Deterministic Keys

1.1. Conventions and definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following notation is used throughout the document.¶

• byte: A sequence of eight bits.¶

• I2OSP(n, w): Convert non-negative integer n to a w-length, big-endian byte string, as described in [RFC8017].¶

2.1. Introductory examples

                          +----+ +--+
Confidential static data: |seed| |pk|
                          +-+--+ +--+
                            v
                          +----+ +----+
Level 0 HDKeys:           |hdk0| |hdk1|
                          +-+--+ +----+
                            v
                          +-----+ +-----+ +-----+
Level 1 HDKeys:           |hdk00| |hdk01| |hdk02|
                          +-----+ ++---++ +-----+
                                   v   v
                             +------+ +------+
Level 2 HDKeys at hdk01:     |hdk000| |hdk001| ...
                             +------+ +------+

+------------------+ +--------+
|       +--+ +---+ | |        |
| Unit  |sk| |hdk| | | Reader |
|       +--+ +---+ | |        |
+---+--------------+ +----+---+
    |                     |
    |                     |
    |  1. Request and     |
    |     reader_data     |
    | <------------------ |
    |                     |
+---+-------------+       |
| 2. authenticate |       |
+---+-------------+       |
    |                     |
    |  3. Proof with      |
    |     device_data     |
    | ------------------> |
    |                     |
    |    +-----------+    |
    |    | Document  |    |
    |    |           |    |
    |    | +---+     |    |
    |    | |pk'|     |    |
    |    | +---+     |    |
    |    |           |    |
         +-----------+

2.2. Instantiation parameters

The parameters of an HDK instantiation are:¶

• Ns: The amount of bytes of a salt value with sufficient entropy.¶

• H: A cryptographic hash function.¶

  • H(msg): Outputs Ns bytes.¶

• BL: A key blinding scheme [Wilson2023] with opaque blinding factors and algebraic properties, consisting of the functions:¶

  • DeriveBlindKey(ikm): Outputs a blind key bk based on input keying material ikm.¶

  • DeriveBlindingFactor(bk, ctx): Outputs a blinding factor bf based on a blind key bk and an application context byte string ctx.¶

  • BlindPublicKey(pk, bk, ctx): Outputs the result public key pk' of blinding public key pk with blind key bk and application context byte string ctx.¶

  • BlindPrivateKey(sk, bf): Outputs the result private key sk' of blinding private key sk with blinding factor bf. This result sk' is such that if bf = DeriveBlindingFactor(bk, ctx) for some bk and ctx, (sk', pk') forms a key pair for pk' = BlindPublicKey(pk, bk, ctx).¶

  • Combine(bf1, bf2): Outputs a blinding factor bf such that for all key pairs (sk, pk):¶

    BlindPrivateKey(sk, bf) ==
        BlindPrivateKey(BlindPrivateKey(sk, bf1), bf2)
    

    ¶

• KEM: A key encapsulation mechanism [RFC9180], consisting of the functions:¶

  • DeriveKeyPair(ikm): Outputs a key encapsulation key pair (sk, pk).¶

  • Encap(pk): Outputs (k, c) consisting of a shared secret k and a ciphertext c, taking key encapsulation public key pk.¶

  • Decap(c, sk): Outputs shared secret k, taking ciphertext c and key encapsulation private key sk.¶

An HDK instantiation MUST specify the instantiation of each of the above functions and values.¶

Note that by design of BL, when a document is issued using HDK, the reader does not need to know that HDK was applied: the public key will look like any other public key used for proofs of possession.¶

An HDK implementation MAY leave BlindPrivateKey implicit in cases where the blinding method is constructed in a distributed way. In those cases, the secure cryptographic device holding the private key does not need to support key blinding, and the value of the blinded private key is never available during computation.¶

2.3. The HDK context

A local unit or remote party creates an HDK context from an index.¶

Inputs:
- index, an integer between 0 and 2^32-1 (inclusive).

Outputs:
- ctx, an application context byte string.

def CreateContext(index):
    ctx = ID || I2OSP(index, 4)
    return ctx

This context byte string is used as input for DeriveBlindingFactor, BlindPublicKey, and DeriveSalt (Section 2.4).¶

2.4. The HDK salt

A local unit or remote party derives a next-level HDK salt from within an HDK context.¶

Inputs:
- salt, a string of Ns bytes.
- ctx, an HDK context byte string.

Outputs:
- salt', the next salt for HDK derivation.

def DeriveSalt(salt, ctx):
    salt' = H(salt || ctx)
    return salt'

Salt values are used as input for DeriveBlindKey, DeriveKeyPair, and DeriveSalt.¶

Salt values, including the original seed value, MUST NOT be reused outside of HDK.¶

2.5. The HDK function

A local unit or a remote party deterministically computes an HDK from an index, a parent public key, a salt, and an optional parent blinding factor. The salt can be an initial seed value of Ns bytes or it can be taken from another parent HDK. The secure generation of the seed is out of scope for this specification.¶

Inputs:
- index, an integer between 0 and 2^32-1 (inclusive).
- pk, a public key to be blinded.
- salt, a string of Ns bytes.
- bf, a blinding factor to combine with, Nil otherwise.

Outputs:
- pk', the blinded public key at the provided index.
- salt', the salt for HDK derivation at the provided index.
- bf', the blinding factor at the provided index.

def HDK(index, pk, salt, bf = Nil):
    ctx   = CreateContext(index)
    salt' = DeriveSalt(salt, ctx)

    bk  = DeriveBlindKey(salt)
    pk' = BlindPublicKey(bk, ctx)
    bf' = if bf == Nil:
        DeriveBlindingFactor(bk, ctx)
    else:
        Combine(bf, DeriveBlindingFactor(bk, ctx))

    return (pk', salt', bf')

A unit MUST NOT persist a blinded private key. Instead, if persistence is needed, a unit can persist either the blinding factor of each HDK, or a path consisting of the seed salt, indices and key handles. In both cases, the application of Combine in the HDK function enables reconstruction of the blinding factor with respect to the original private key, enabling application of for example BlindPrivateKey.¶

If the unit uses the blinded private key directly, the unit MUST use it within the secure cryptographic device protecting the device private key.¶

If the unit uses the blinded private key directly, the unit MUST ensure the secure cryptographic device deletes it securely from memory after usage.¶

When presenting multiple documents, a reader can require a proof that multiple keys are associated to a single device. Several protocols for a cryptographic proof of association are possible, such as [Verheul2024]. For example, a unit could prove in a zero-knowledge protocol knowledge of the association between two elliptic curve keys B1 = [bf1]D and B2 = [bf2]D, where bf1 and bf2 are multiplicative blinding factors for a common blinding public key D. In this protocol, the association is known by the discrete logarithm of B2 = [bf2/bf1]B1 with respect to generator B1. The unit can apply Combine to obtain values to compute this association.¶

2.6. The local HDK procedure

This is a procedure executed locally by a unit.¶

To begin, the unit securely generates a seed salt of Ns bytes and a device key pair:¶

seed = random(Ns) # specification of random out of scope
(skD, pkD) = GenerateKeyPair()

The unit MUST generate skD within a secure cryptographic device.¶

Whenever the unit requires the HDK with some index at level 0, the unit computes:¶

(pk, salt, bf) = HDK(index, pkD, seed)

sk = BlindPrivateKey(skD, bf) # optional

Now the unit can use the blinded key pair (sk, pk) or derive child HDKeys.¶

Whenever the unit requires the HDK with some index at level n > 0 based on a parent HDK hdk = (pk, salt, bf) with blinded key pair (sk, pk) at level n, the unit computes:¶

(pk', salt', bf') = HDK(index, pk, salt)

sk' = BlindPrivateKey(sk, bf') # optional

Now the unit can use the blinded key pair (sk', pk') or derive child HDKeys.¶

2.7. The remote HDK protocol

This is a protocol between a local unit and a remote issuer.¶

As a prerequisite, the unit possesses a salt of Ns bytes associated with a parent key pair (sk, pk) generated using the local HDK procedure.¶

# 1. Unit computes:
(skR, pkR) = DeriveKeyPair(salt)

# 2. Unit shares with issuer: (pk, pkR)

# 3. Issuer computes:
(salt_kem, kh) = Encap(pkR)

# 4. Issuer shares with unit: kh

# Subsequently, for any index known to both parties:

# 5. Issuer computes:
(pk', salt', bf') = HDK(index, pk, salt_kem)

# 6. Issuer shares with unit: pk'

# 7. Unit verifies integrity:
salt_kem = Decap(kh, skR)
(pk_expected', salt', bf') = HDK(index, pk, salt_kem)
pk' == pk_expected'

# 8. Unit computes:
sk' = BlindPrivateKey(sk, bf) # optional

After step 7, the unit can use the value of salt' to derive next-level HDKeys.¶

Step 4 MAY be postponed to be combined with step 6. Steps 5 to 8 MAY be combined in concurrent execution for multiple indices.¶

3.1. Using digital signatures

Instantiations of HDK using digital signatures require:¶

• DSA: A digital signature algorithm, consisting of the functions:¶

  • GenerateKeyPair(): Outputs a new key pair (sk, pk) consisting of private key sk and public key pk.¶

  • Sign(sk, msg): Outputs the signature created using private signing key sk over byte string msg.¶

  • Verify(signature, pk, msg): Outputs whether signature is a signature over msg using public verification key pk.¶

Using these constructs, an example proof of possession protocol is:¶

# 1. Unit shares with reader: pk

# 2. Reader computes:
nonce = generate_random_nonce() # out of scope for this spec

# 3. Reader shares with unit: nonce

# 4. Unit computes:
msg = create_message(pk, nonce) # out of scope for this spec
signature = Sign(sk, msg)

# 5. Reader computes:
msg = create_message(pk, nonce) # out of scope for this spec
Verify(signature, pk, msg)

Instantiations of HDK using digital signatures provide:¶

• BL: A cryptographic construct that extends DSA as specified in [I-D.draft-irtf-cfrg-signature-key-blinding-07], implementing the interface from Instantiation parameters (Section 2.2).¶

While [I-D.draft-irtf-cfrg-signature-key-blinding-07] does not expose blinding factors, it provides public algorithms to compute these. In HDK, the computed blinding factors are applied in BL as follows:¶

def BlindSign(sk, bf, msg):
    sk' = BlindPrivateKey(sk, bf)
    signature = Sign(sk', msg)
    return signature

By design of BL, the same proof of possession protocol can be used with blinded key pairs and BlindSign, in such a way that the reader does not recognise that key blinding was used.¶

In the default implementation, BlindSign requires support from the secure cryptographic device protecting sk. In some cases, BlindSign can be implemented in an alternative, distributed way. An example will be provided below.¶

Applications MUST bind the message to be signed to the blinded public key. This mitigates attacks based on signature malleability. Several proof of possession protocols require including document data in the message, which includes the blinded public key indeed.¶

3.2. Using prime-order groups

Instantiations of HDK using prime-order groups require:¶

• G: A prime-order group as defined in [RFC9497] with elements of type Element and scalars of type Scalar, consisting of the functions:¶

  • RandomScalar(): Outputs a random Scalar k.¶

  • Add(A, B): Outputs the sum between Elements A and B.¶

  • ScalarMult(A, k): Outputs the scalar multiplication between Element A and Scalar k.¶

  • ScalarBaseMult(k): Outputs the scalar multiplication between the base Element and Scalar k.¶

  • Order(): Outputs the order of the base Element.¶

  • SerializeElement(A): Outputs a byte string representing Element A.¶

  • SerializeScalar(k): Outputs a byte string representing Scalar k.`¶

  • HashToScalar(msg): Outputs the result of deterministically mapping a byte string msg to an element in the scalar field of the prime order subgroup of G, using the hash_to_field function from a hash-to-curve suite [RFC9380].¶

Instantiations of HDK using prime-order groups provide:¶

def GenerateKeyPair():
    sk = GenerateRandomScalar()
    pk = ScalarBaseMult(sk)
    return (sk, pk)

def DeriveBlindKey(ikm):
    bk_scalar = HashToScalar(ikm)
    bk = SerializeScalar(bk_scalar)
    return bk

def DeriveBlindingFactor(bk, ctx):
    msg = bk || 0x00 || ctx
    bf = HashToScalar(msg)
    return bf

Note that DeriveBlindingFactor is compatible with the definitions in [I-D.draft-irtf-cfrg-signature-key-blinding-07]. The function is almost compatible with the definitions in [I-D.draft-bradleylundberg-cfrg-arkg-02]: only in AKRG, the context string needs to be prefixed with 0x00.¶

def BlindPublicKey(pk, bk, ctx):
    bf = DeriveBlindingFactor(bk, ctx)
    pk' = Add(pk, ScalarBaseMult(bf))
    return pk

def BlindPrivateKey(sk, bf):
    sk' = sk + bf mod Order()
    return sk

def Combine(bf1, bf2):
    bf = bf1 + bf2 mod Order()
    return bf

def BlindPublicKey(pk, bk, ctx):
    bf = DeriveBlindingFactor(bk, ctx)
    pk' = ScalarMult(pk, bf)
    return pk

def BlindPrivateKey(sk, bf):
    sk' = sk * bf mod Order()
    return sk

def Combine(bf1, bf2):
    bf = bf1 * bf2 mod Order()
    return bf

3.3. Using elliptic curves

Instantiations of HDK using elliptic curves use:¶

• prime-order groups (Section 3.2)¶

Instantiations of HDK using elliptic curves require:¶

• DST: A domain separation tag for use with HashToScalar.¶

• H2C: A hash-to-curve suite [RFC9380].¶

Instantiations of HDK using elliptic curves provide:¶

• H: H from H2C.¶

• Ns: The output size of H.¶

def HashToScalar(msg):
    scalar = hash_to_field(msg, 1) with the parameters:
        DST: DST
        F: GF(Order()), the scalar field
            of the prime order subgroup of EC
        p: Order()
        m: 1
        L: as defined in H2C
        expand_message: as defined in H2C
    return scalar

# 1. Unit shares with reader: pk

# 2. Reader computes:
(skR, pkR) = GenerateKeyPair()

# 3. Reader shares with unit: pkR

# 4. Unit computes:
Z_AB = CreateSharedSecret(sk, pkR)

# 5. Reader computes:
Z_AB = CreateSharedSecret(skR, pk)

sk' = BlindPrivateKey(sk, bf)
    = sk * bf mod Order()
pk' = ScalarMult(pk, bf)

# 4. Unit computes:
Z_AB = CreateSharedSecret(sk', pkR)
     = CreateSharedSecret(sk * bf mod Order(), pkR)
     = CreateSharedSecret(sk, ScalarMult(pkR, bf))

def BlindSign(sk, bf, msg):
    # Compute signature within the secure cryptographic device.
    (c, s) = Sign(sk, msg)

    # Post-process the signature outside of this device.
    s' = s + c * bf mod Order()

    signature = (c, s')
    return signature

4.1. HDK-ECDH-P256

The HDK-ECDH-P256 instantiation of HDK uses:¶

• P-256 (Section 3.3.3)¶

• ECDH shared secrets (Section 3.3.1)¶

The HDK-ECDH-P256 instantiation defines:¶

• DST: "ECDH Key Blind"¶

4.2. HDK-ECDSA-P256add

The HDK-ECDSA-P256add instantiation of HDK uses:¶

• digital signatures (Section 3.1)¶

• P-256 (Section 3.3.3)¶

• additive blinding (Section 3.2.1)¶

The HDK-ECDSA-P256add instantiation of HDK defines:¶

• DST: "ARKG-BL-EC.ARKG-P256ADD-ECDH" for interoperability with [I-D.draft-bradleylundberg-cfrg-arkg-02].¶

• DSA: ECDSA [TR03111] with curve G.¶

4.3. HDK-ECDSA-P256mul

The HDK-ECDSA-P256mul instantiation of HDK uses:¶

• digital signatures (Section 3.1)¶

• P-256 (Section 3.3.3)¶

• multiplicative blinding (Section 3.2.2)¶

The HDK-ECDSA-P256mul instantiation of HDK defines:¶

• DST: "ECDSA Key Blind" for interoperability with [I-D.draft-irtf-cfrg-signature-key-blinding-07].¶

• DSA: ECDSA [TR03111] with curve G.¶

4.4. HDK-ECSDSA-P256

The HDK-ECSDSA-P256 instantiation of HDK uses:¶

• EC-SDSA signatures (Section 3.3.2)¶

• P-256 (Section 3.3.3)¶

The HDK-ECSDSA-P256 instantiation of HDK defines:¶

• DST: "EC-SDSA Key Blind"¶

5.1. Secure cryptographic device

The HDK approach assumes that the holder controls a secure cryptographic device that protects the device key pair (sk_device, pk_device). The device key is under sole control of the holder.¶

In the context of [EU2024-1183], this device is typically called a Wallet Secure Cryptographic Device (WSCD), running a personalised Wallet Secure Cryptographic Application (WSCA) that exposes a Secure Cryptographic Interface (SCI) to a Wallet Instance (WI) running on a User Device (UD). The WSCD is certified to protect access to the device private key with high attack potential resistance to achieve high level of assurance authentication as per [EU2015-1502]. This typically means that the key is associated with a strong possession factor and with a rate-limited Personal Identification Number (PIN) check as a knowledge factor, and the verification of both factors actively involve the WSCD.¶

An example deployment of HDK in this context is illustrated below.¶

+---------------------+          +----------------------+
|Issuer infrastructure|          |User Device (UD)      |
|                     |          |                      |
|+-------------------+|OpenID4VCI|+--------------------+|
||Issuer service     |<----------++Wallet Instance (WI)||
||                   ||          |++-------------------+|
||Optionally an      ||          +-+--------------------+
||ARKG subordinate   ||            |Secure
||party              ||            |Cryptographic
|+-------------------+|            |Interface (SCI)
+---------------------+           +v-------------------+
                                  |Wallet Secure       |
                                  |Cryptographic       |
          Internal     Manages    |Application (WSCA)  |
          registry    <-----------+                    |
                                  |Optionally an       |
                                  |ARKG delegating     |
                                  |party               |
                                  ++-------------------+
                                   |Uses
                                  +v-------------------+
                       Protects   |Wallet secure       |
          Device keys <-----------+cryptographic       |
                                  |device (WSCD)       |
                                  +--------------------+

The WSCA could be a single program or could be deployed in a distributed architecture, as illustrated below.¶

+--------------+
|User device   |
|+------------+|
||WI          ||
|++-----------+|
| |SCI         |
|+v-----------+|
||WSCA agent  ||
|++-----------+|
+-+------------+
  |WSCA protocol
 +v-----------+
 |WSCA service|
 +------------+

In the case of a distributed WSCA, the UD contains a local component, here called WSCA agent, accessing an external and possibly remote WSCA service from one or more components over a WSCA protocol. For example, the WSCA agent may be a local web API client and the WSCA service may be provided at a remote web API server. In such cases, typically the WSCA service receives a high-assurance security evaluation, while the WSCA agent is assessed to not be able to compromise the system's security guarantees.¶

The internal registry can be managed by the WSCA agent, by the WSCA service, or by the combination. When the user device is a natural person’s mobile phone, WSCA agent management could provide better confidentiality protection against compromised WSCA service providers. When the user device is a cloud server used by a legal person, and the legal person deploys its own WSCD, WSCA service management could provide better confidentiality protection against compromised Wallet Instance cloud providers.¶

In a distributed WSCA architecture, the WSCA could internally apply distributed key generation. A description of this is out of scope for the current document.¶

The solution proposal discussed herein works in all any WSCD architecture that supports the required cryptographic primitives:¶

• In the case of HDK-ECDH-P256 (see Section 4.1):¶

  • P-256 ECDH key pair generation¶

  • P-256 ECDH key agreement¶

• In the case of HDK-ECDSA-P256mul (see Section 4.3):¶

  • P-256 ECDSA blinding key pair generation¶

  • P-256 ECDSA blinded signature creation¶

• In the case of HDK-ECSDSA-P256 (see Section 4.4):¶

  • P-256 EC-SDSA key pair generation¶

  • P-256 EC-SDSA signature creation¶

The other HDK operations can be performed in a WSCA or WSCA agent running on any UD, including hostile ones with limited sandboxing capabilities, such as in a smartphone's rich execution environment or in a personal computer web browser.¶

5.2. Trust evidence

Some issuers could require evidence from a solution provider of the security of the holder's cryptographic device. This evidence can in the context of [EU2024-1183] be divided into initial "Wallet Trust Evidence" and related "Issuer Trust Evidence". Each is a protected document that contains a trust evidence public key associated with a private key that is protected in the secure cryptographic device. With HDK, these public keys are specified as follows.¶

5.3. Applying HDK in OpenID for Verifiable Credential Issuance

In [draft-OpenID4VCI], the following terminology applies:¶

HDK enables unit and issuers cooperatively to establish the cryptographic key material that issued documents will be bound to.¶

For the remote HDK protocol, HDK proposes an update to the OpenID4VCI endpoints. This proposal is under discussion in openid/OpenID4VCI#359. In the update, the unit shares a key encapsulation public key with the issuer, and the issuer returns a key handle. Then documents can be re-issued, potentially in batches, using synchronised indices. Alternatively, re-issued documents can have their own key handles.¶

6.1. Confidentiality of key handles

The key handles MUST be considered confidential, since they provide knowledge about the blinding factors. Compromise of this knowledge could introduce undesired linkability. In HDK, both the holder and the issuer know the key handle during issuance.¶

In an alternative to HDK, the holder independently generates blinded key pairs and proofs of association, providing the issuer with zero knowledge about the blinding factors. However, this moves the problem: the proofs of association would now need to be considered confidential.¶

7.1. Normative References

[FIPS180-4]

National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, June 2012, <https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.

[ISO18013-5]

ISO/IEC, "Personal identification - ISO-compliant driving licence - Part 5: Mobile driving licence (mDL) application", ISO/IEC 18013-5:2021, September 2019, <https://www.iso.org/standard/69084.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8017]

Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/rfc/rfc8017>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

[RFC9380]

Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10.17487/RFC9380, August 2023, <https://www.rfc-editor.org/rfc/rfc9380>.

[RFC9497]

Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497, December 2023, <https://www.rfc-editor.org/rfc/rfc9497>.

[SEC2]

Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0", SEC 2 Version 2.0, January 2010, <https://www.secg.org/sec2-v2.pdf>.

[TR03111]

Federal Office for Information Security (BSI), "Elliptic Curve Cryptography", BSI TR-03111 Version 2.10, June 2018, <https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03111/tr-03111.html>.

7.2. Informative References

[BIP32]

Wuille, P., "Hierarchical Deterministic Wallets", BIP 32, February 2021, <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>.

[draft-OpenID4VCI]

Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for Verifiable Credential Issuance, draft 13", 8 February 2024, <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html>.

[EU2015-1502]

European Commission, "Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means", (EU) 2015/1502, September 2025, <https://eur-lex.europa.eu/legal-content/TXT/?uri=CELEX%3A32015R1502>.

[EU2024-1183]

The European Parliament and the Council of the European Union, "Amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework", (EU) 2024/1183, April 2024, <https://data.europa.eu/eli/reg/2024/1183/oj>.

[I-D.draft-bradleylundberg-cfrg-arkg-02]

Lundberg, E. and J. Bradley, "The Asynchronous Remote Key Generation (ARKG) algorithm", Work in Progress, Internet-Draft, draft-bradleylundberg-cfrg-arkg-02, 27 May 2024, <https://datatracker.ietf.org/doc/html/draft-bradleylundberg-cfrg-arkg-02>.

[I-D.draft-irtf-cfrg-signature-key-blinding-07]

Denis, F., Eaton, E., Lepoint, T., and C. A. Wood, "Key Blinding for Signature Schemes", Work in Progress, Internet-Draft, draft-irtf-cfrg-signature-key-blinding-07, 23 September 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-signature-key-blinding-07>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8235]

Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, <https://www.rfc-editor.org/rfc/rfc8235>.

[Verheul2024]

Verheul, E., "Attestation Proof of Association – provability that attestation keys are bound to the same hardware and person", 18 September 2024, <https://eprint.iacr.org/2024/1444>.

[Wilson2023]

Wilson, S. M., "Post-Quantum Account Recovery for Passwordless Authentication. Master’s thesis", 24 April 2023, <https://hdl.handle.net/10012/19316>.