Crypto Forum                                         S. Q. Dijkhuis, Ed.
Internet-Draft                                                Cleverbase
Intended status: Informational                           20 January 2025
Expires: 24 July 2025


                    Hierarchical Deterministic Keys
                     draft-dijkhuis-cfrg-hdkeys-06

Abstract

   Hierarchical Deterministic Keys enables managing large sets of keys
   bound to a secure cryptographic device that protects a single key.
   This enables the development of secure digital identity wallets
   providing many one-time-use public keys.  Some instantiations can be
   implemented in such a way that the secure cryptographic device does
   not need to support key blinding, enabling the use of devices that
   already are widely deployed.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-dijkhuis-cfrg-hdkeys/.

   Source for this draft and an issue tracker can be found at
   https://github.com/sander/hierarchical-deterministic-keys.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 July 2025.






Dijkhuis                  Expires 24 July 2025                  [Page 1]

Internet-Draft                     HDK                      January 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and definitions . . . . . . . . . . . . . . .   4
   2.  The Hierarchical Deterministic Key function . . . . . . . . .   4
     2.1.  Introductory examples . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Local deterministic key derivation  . . . . . . . . .   4
       2.1.2.  Remote deterministic key derivation . . . . . . . . .   5
       2.1.3.  Blinded proof of possession . . . . . . . . . . . . .   6
     2.2.  Instantiation parameters  . . . . . . . . . . . . . . . .   8
     2.3.  The HDK context . . . . . . . . . . . . . . . . . . . . .   9
     2.4.  The HDK salt  . . . . . . . . . . . . . . . . . . . . . .   9
     2.5.  The HDK function  . . . . . . . . . . . . . . . . . . . .  10
     2.6.  The local HDK procedure . . . . . . . . . . . . . . . . .  11
     2.7.  The remote HDK protocol . . . . . . . . . . . . . . . . .  12
     2.8.  The HDK key alias format  . . . . . . . . . . . . . . . .  12
   3.  Generic HDK instantiations  . . . . . . . . . . . . . . . . .  14
     3.1.  Using digital signatures  . . . . . . . . . . . . . . . .  14
     3.2.  Using prime-order groups  . . . . . . . . . . . . . . . .  15
       3.2.1.  Using additive blinding . . . . . . . . . . . . . . .  16
       3.2.2.  Using multiplicative blinding . . . . . . . . . . . .  17
     3.3.  Using elliptic curves . . . . . . . . . . . . . . . . . .  17
       3.3.1.  Using ECDH shared secrets . . . . . . . . . . . . . .  18
       3.3.2.  Using EC-SDSA signatures  . . . . . . . . . . . . . .  19
       3.3.3.  Using P-256 . . . . . . . . . . . . . . . . . . . . .  20
   4.  Concrete HDK instantiations . . . . . . . . . . . . . . . . .  20
     4.1.  HDK-ECDH-P256 . . . . . . . . . . . . . . . . . . . . . .  21
     4.2.  HDK-ECDSA-P256add . . . . . . . . . . . . . . . . . . . .  21
     4.3.  HDK-ECDSA-P256mul . . . . . . . . . . . . . . . . . . . .  21
     4.4.  HDK-ECSDSA-P256 . . . . . . . . . . . . . . . . . . . . .  22
   5.  Application considerations  . . . . . . . . . . . . . . . . .  22
     5.1.  Secure cryptographic device . . . . . . . . . . . . . . .  22
     5.2.  Trust evidence  . . . . . . . . . . . . . . . . . . . . .  25
       5.2.1.  Wallet Trust Evidence . . . . . . . . . . . . . . . .  25
       5.2.2.  Issuer Trust Evidence . . . . . . . . . . . . . . . .  25
     5.3.  Applying HDK in OpenID for Verifiable Credential
           Issuance  . . . . . . . . . . . . . . . . . . . . . . . .  25



Dijkhuis                  Expires 24 July 2025                  [Page 2]

Internet-Draft                     HDK                      January 2025


   6.  Security considerations . . . . . . . . . . . . . . . . . . .  26
     6.1.  Confidentiality of key handles  . . . . . . . . . . . . .  26
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  26
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  28
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   This document specifies the algorithms to apply Hierarchical
   Deterministic Keys (HDKeys).  The purpose of an HDK architecture is
   to manage large sets of keys bound to a secure cryptographic device
   that protects a single key.  This enables the development of secure
   digital identity wallets providing many one-time-use public keys.

   The core idea has been introduced in [BIP32] to create multiple
   cryptocurrency addresses in a manageable way.  The present document
   extends the idea towards devices commonly used for digital wallets,
   and towards common interaction patterns for document issuance and
   authentication.

   To store many HDKeys, only a seed string needs to be stored
   confidentially, associated with a device private key.  Each HDK is
   then deterministically defined by a path of indices, optionally
   alternated by key handles provided by another party.  Such a path can
   efficiently be stored and requires less confidentiality than the
   seed.

   To prove possession of many HDKeys, the secure cryptographic device
   only needs to perform common cryptographic operations on a single
   private key.  The HDK acts as a blinding factor that enables blinding
   the device public key.  In several instantiations, such as those
   using ECDH shared secrets (Section 3.3.1) and those using EC-SDSA
   signatures (Section 3.3.2), the secure cryptographic device does not
   need to support key blinding natively, and the application can pre-
   process the input or post-process the output from the device to
   compute the blinded device authentication data.  This enables the
   application of HDK on devices that are already deployed without
   native support for HDK.

   This document provides a specification of the generic HDK function,
   generic HDK instantiations, and fully specified concrete HDK
   instantiations.






Dijkhuis                  Expires 24 July 2025                  [Page 3]

Internet-Draft                     HDK                      January 2025


   An HDK instantiation is expected to be applied in a solution deployed
   as (wallet) units.  One unit can have multiple HDK instantiations,
   for example to manage multiple identities or multiple cryptographic
   algorithms or key protection mechanisms.

   This document represents the consensus of the authors, based on
   working group input and feedback.  It is not a standard.  It does not
   include security or privacy proofs.

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.  The Hierarchical Deterministic Key function

   An HDK instantiation enables local key derivation to create many key
   pairs from a single seed value.  It enables remote parties to
   generate key handles from which both parties can derive more key
   pairs asynchronously.  Additionally, an HDK instantiation enables
   securely proving possession of the private keys, such as required in
   [RFC7800], either in a centralised or in a distributed manner.

   Solutions MAY omit application of the remote functionality.  In this
   case, a unit can only derive keys locally.

2.1.  Introductory examples

2.1.1.  Local deterministic key derivation

   The following example illustrates the use of local key derivation.
   An HDK tree is associated with a device key pair and initiated using
   confidential static data: a seed value, which is a byte array
   containing sufficient entropy.  Now tree nodes are constructed as
   follows.






Dijkhuis                  Expires 24 July 2025                  [Page 4]

Internet-Draft                     HDK                      January 2025


                             +----+ +--+
   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| ...
                                +------+ +------+

   The unit computes a Level 0 HDK at the root node using a
   deterministic function, taking the device public key pk and the seed
   as input: (pk0, salt0, bf0) = hdk0 = HDK(0, pk, seed).  The HDK
   consists of a first blinded public key pk0, a first byte string salt0
   to derive next-level keys, and a first blinding factor bf0.  Using
   bf0 and the device key pair, the unit can compute blinded private
   keys and proofs of possession.

   The unit computes any Level n > 0 HDK from any other HDK (pk, salt,
   bf) using the same deterministic function: (pk', salt', bf') = hdk' =
   HDK(index, pk, salt, bf).  The function takes as input the index
   starting at 0, an the previous-level HDK.  The function returns a new
   HDK as output, which can be used in the same way as the root HDK.

2.1.2.  Remote deterministic key derivation

   Instead of local derivation, an HDK salt can also be derived using a
   key handle that is generated remotely.  Using the derived salt, the
   local and remote parties can derive the same new HDKeys.  The remote
   party can use these to derive public keys.  The local party can use
   these to derive associated private keys for proof of possession.

   This approach is similar to Asynchronous Remote Key Generation (ARKG)
   [I-D.draft-bradleylundberg-cfrg-arkg-02] when considered at a single
   level.  However, ARKG does not enable distributed proof of possession
   with deterministic hierarchies.  Such hierarchies can be used for
   example to enable remote parties to derive keys from previously
   derived keys.  Secure cryptographic devices that support ARKG may
   therefore not support all features of HDK.






Dijkhuis                  Expires 24 July 2025                  [Page 5]

Internet-Draft                     HDK                      January 2025


   To enable remote derivation of child HDKeys, the unit uses the parent
   HDK to derive the parent public key and a second public key for key
   encapsulation.  The issuer returns a key handle, using which both
   parties can derive a sequence of child HDKeys.  Key encapsulation
   prevents other parties from discovering a link between the public
   keys of the parent and the children, even if the other party knows
   the parent HDK or can eavesdrop communications.

   Locally derived parents can have remotely derived children.  Remotely
   derived parents can have locally derived children.

2.1.3.  Blinded proof of possession

   The next concept to illustrate is blinded proof of possession.  This
   enables a unit to prove possession of a (device) private key without
   disclosing the directly associated public key.  This way, solutions
   can avoid linkability across readers of a digital document that is
   released with proof of possession.

   In this example, a document is issued with binding to a public key
   pk', which is a blinding public key pk blinded with the blinding
   factor bf in some HDK hdk = (pk', salt, bf).  The unit can present
   the document with a proof of possession of the corresponding blinded
   private key, which is the blinding private key sk blinded with bf.
   The unit applies some authentication function device_data =
   authenticate(sk, reader_data, bf) to the blinding private key,
   reader-provided data and the blinding factor.  The unit can
   subsequently use the output device_data to prove possession to the
   reader using common algorithms.






















Dijkhuis                  Expires 24 July 2025                  [Page 6]

Internet-Draft                     HDK                      January 2025


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

   The reader does not need to be aware that an HDK function or key
   blinding was used, since for common algorithms, the blinded public
   key and the proof are indistinguishable from non-blinded keys and
   proofs.

   When applied on HDK level n, the blinding private key sk is the
   device private key blinded with a combination of n blinding factors.
   These can either be combined within the secure cryptographic device,
   by subsequent computation of the blinded private key starting with
   the device private key, or outside of the secure cryptographic
   device, by combining the blinding factors outside of the secure
   cryptographic device.

   Blinding methods can be constructed such that the secure
   cryptographic device does not need to be designed for key blinding.
   In such cases, the computation of device_data is distributed between
   two parties: the secure cryptographic device using common
   cryptographic operations, and the unit component invoking these
   operations.  Some blinded proof of possession algorithms can only be
   centralised.



Dijkhuis                  Expires 24 July 2025                  [Page 7]

Internet-Draft                     HDK                      January 2025


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.




Dijkhuis                  Expires 24 July 2025                  [Page 8]

Internet-Draft                     HDK                      January 2025


   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.



Dijkhuis                  Expires 24 July 2025                  [Page 9]

Internet-Draft                     HDK                      January 2025


   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.





Dijkhuis                  Expires 24 July 2025                 [Page 10]

Internet-Draft                     HDK                      January 2025


   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.




Dijkhuis                  Expires 24 July 2025                 [Page 11]

Internet-Draft                     HDK                      January 2025


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.

2.8.  The HDK key alias format

   An HDK can be represented canonically using the following string
   format, in augmented Backus-Naur form (ABNF) [RFC5234] and applying
   non-padded base64url encoding [RFC4648] for key handles:







Dijkhuis                  Expires 24 July 2025                 [Page 12]

Internet-Draft                     HDK                      January 2025


   hdk-key-alias  = origin-alias "/" path

   ; The origin-alias is an opaque identifier for a device
   ; key pair, the associated HDK instantiation, and the seed.
   origin-alias   = 1*255no-slash

   ; The hdk-path identifies the indices and key handles to
   ; apply from left to right.
   hdk-path       = hdk-index *("/" hdk-sub-path)

   hdk-sub-path   = *(hdk-edge "/") hdk-index
   hdk-edge       = ("#" hdk-key-handle) / hdk-index

   ; The index is to be parsed to an integer between 0 and
   ; 2^32-1 (inclusive) and used as input to CreateContext.
   hdk-index      = non-zero-digit 0*9DIGIT

   ; The key handle is to be decoded from
   hdk-key-handle = 1*base64url-char

   no-slash       = %x21-%x2E / %x30-%x7E ; ASCII printable, no "/"
   non-zero-digit = %31-39
   base64url-char = ALPHA / DIGIT / "-" / "_"

   A unit MAY use the HDK key alias format to represent keys internally.

   A unit MUST NOT directly include the device private key in the
   origin-alias.

   A unit MUST NOT directly include the seed in the origin-alias.

   When taking input in the HDK key alias format:

   *  a unit MAY pose further limitations on the value of origin-alias;

   *  a unit MUST limit either the amount of hdk-edge instances or the
      total length of the hdk-key-alias;

   *  a unit MUST verify that the byte strings represented by hdk-key-
      handle has the size of ciphertext in KEM.

   Example key handles:









Dijkhuis                  Expires 24 July 2025                 [Page 13]

Internet-Draft                     HDK                      January 2025


   my_pid_key/0

   my_pid_key/12345

   my_pid_key/0/iS2ipkvGCDI0-Lps25Ex2KdjTfGRmIBjGEHkjBCPoQg/3

   ; newline for printing purposes not in the actual hdk-path
   second_key/123/45/itnCVhZ-DYZDaUqofDNhHEbNc9XOrdnLL9B-9dVZ
   tTg/6789/3JVRsML8NvUnCx1CvzpZrHSn4TkSUpGgn8r-X_RiQ1Y/3

3.  Generic HDK instantiations

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:






Dijkhuis                  Expires 24 July 2025                 [Page 14]

Internet-Draft                     HDK                      January 2025


   *  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.





Dijkhuis                  Expires 24 July 2025                 [Page 15]

Internet-Draft                     HDK                      January 2025


      -  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.

3.2.1.  Using additive blinding

   Instantiations of HDK using additive blinding use:

   *  prime-order groups (Section 3.2)

   Instantiations of HDK using additive blinding provide:










Dijkhuis                  Expires 24 July 2025                 [Page 16]

Internet-Draft                     HDK                      January 2025


   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

   Note that all algorithms in [I-D.draft-bradleylundberg-cfrg-arkg-02]
   use additive blinding.

3.2.2.  Using multiplicative blinding

   Instantiations of HDK using multiplicative blinding use:

   *  prime-order groups (Section 3.2)

   Instantiations of HDK using multiplicative blinding provide:

   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

   Note that all algorithms in
   [I-D.draft-irtf-cfrg-signature-key-blinding-07] use multiplicative
   blinding.

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:



Dijkhuis                  Expires 24 July 2025                 [Page 17]

Internet-Draft                     HDK                      January 2025


   *  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

3.3.1.  Using ECDH shared secrets

   Instantiations of HDK using ECDH shared secrets use:

   *  elliptic curves (Section 3.3)

   *  multiplicative blinding (Section 3.2.2)

   Instantiations of HDK using ECDH shared secrets provide:

   *  DH: The Elliptic Curve Key Agreement Algorithm - Diffie-Hellman
      (ECKA-DH) [TR03111] with elliptic curve G, consisting of the
      functions:

      -  CreateSharedSecret(skX, pkY): Outputs a shared secret byte
         string Z_AB representing the x-coordinate of the Element
         ScalarMult(pkY, skX).

   Note that DH enables an alternative way of authenticating a key pair
   (sk, pk) without creation or verification of a signature:










Dijkhuis                  Expires 24 July 2025                 [Page 18]

Internet-Draft                     HDK                      January 2025


   # 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)

   Now with the shared secret Z_AB, the unit and the reader can compute
   a secret shared key.  The unit can convince the reader that it
   possesses sk for example by sharing a message authentication code
   created using this key.  The reader can verify this by recomputing
   the code using its value of Z_AB.  This is for example used in ECDH-
   MAC authentication defined in [ISO18013-5].

   In this example, step 1 can be postponed in the interactions between
   the unit and the reader if a trustworthy earlier commitment to pk is
   available, for example in a sealed document.

   Similarly, ECDH enables authentication of key pair (sk', pk') blinded
   from an original key pair (sk, pk) using a blinding factor bf such
   that:

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

   In this case, the computation in step 4 can be performed as such:

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

   Note that the value of ScalarMult(pkR, bf) does not need to be
   computed within the secure cryptographic device that protects sk.

3.3.2.  Using EC-SDSA signatures

   Instantiations of HDK using EC-SDSA (Schnorr) signatures use:

   *  additive blinding (Section 3.2.1)




Dijkhuis                  Expires 24 July 2025                 [Page 19]

Internet-Draft                     HDK                      January 2025


   *  digital signatures (Section 3.1)

   *  elliptic curves (Section 3.3)

   Instantiations of HDK using EC-SDSA signatures provide:

   *  DSA: An EC-SDSA digital signature algorithm [TR03111],
      representing signatures as pairs (c, s).

   Note that in this case, the following definition is equivalent to the
   original definition of BlindSign:

   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

3.3.3.  Using P-256

   Instantiations of HDK using P-256 use:

   *  elliptic curves (Section 3.3)

   Instantiations of HDK using P-256 provide:

   *  G: The NIST curve secp256r1 (P-256) [SEC2].

   *  H2C: P256_XMD:SHA-256_SSWU_RO_ [RFC9380], which uses SHA-256
      [FIPS180-4] as H.

   *  KEM: DHKEM(P-256, HKDF-SHA256) [RFC9180].

4.  Concrete HDK instantiations

   The RECOMMENDED instantiation is the HDK-ECDH-P256.  This avoids the
   risk of having the holder unknowingly producing a potentially non-
   repudiable signature over reader-provided data.  Secure cryptographic
   devices that enable a high level of assurance typically support
   managing ECDH keys with the P-256 elliptic curve.







Dijkhuis                  Expires 24 July 2025                 [Page 20]

Internet-Draft                     HDK                      January 2025


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.






Dijkhuis                  Expires 24 July 2025                 [Page 21]

Internet-Draft                     HDK                      January 2025


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.  Application considerations

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.


















Dijkhuis                  Expires 24 July 2025                 [Page 22]

Internet-Draft                     HDK                      January 2025


   +---------------------+          +----------------------+
   |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



Dijkhuis                  Expires 24 July 2025                 [Page 23]

Internet-Draft                     HDK                      January 2025


   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.








Dijkhuis                  Expires 24 July 2025                 [Page 24]

Internet-Draft                     HDK                      January 2025


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.2.1.  Wallet Trust Evidence

   The Wallet Trust Evidence public key is the first level 0 HDK public
   key.  To achieve reader unlinkability, the wallet SHOULD limit access
   to a trusted person identification document provider only.

   To prevent association across identities, the solution provider MUST
   before issuing Wallet Trust Evidence ensure that (a) a newly
   generated device key pair is used and (b) the wallet follows the
   protocol so that the HDK output is bound to exactly this key.  For
   (a), the solution provider could rely on freshness of a key
   attestation and ensure that each device public key is attested only
   once.  For (b), the wallet could proof knowledge of the blinding
   factor bf with a Schnorr non-interactive zero-knowledge proof
   [RFC8235] with base point pk_device.  This would ensure that the root
   blinding key bf is not shared with the solution provider to reduce
   the risk of the solution provider unblinding future derived keys.

5.2.2.  Issuer Trust Evidence

   The Issuer Trust Evidence public key can be any other HDK public key.
   The solution provider MUST verify that the wallet knows the
   associated private key before issuing Issuer Trust Evidence.  The
   solution provider MUST ensure that sk_device is under sole control of
   the unit holder.  To achieve reader unlinkability, the unit MUST
   limit access of Issuer Trust Evidence to a single issuer.  Subsequent
   issuers within the same HDK tree do not need to receive any Issuer
   Trust Evidence, since they can derive equally secure keys by applying
   the remote HDK protocol to presented keys attested by trusted (other)
   issuers.

5.3.  Applying HDK in OpenID for Verifiable Credential Issuance

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







Dijkhuis                  Expires 24 July 2025                 [Page 25]

Internet-Draft                     HDK                      January 2025


                     +===================+==========+
                     | OpenID4VCI        | HDK      |
                     +===================+==========+
                     | Credential        | document |
                     +-------------------+----------+
                     | Credential Issuer | issuer   |
                     +-------------------+----------+
                     | Verifier          | reader   |
                     +-------------------+----------+
                     | Wallet            | unit     |
                     +-------------------+----------+

                                 Table 1

   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 (https://github.com/openid/OpenID4VCI/issues/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.  Security considerations

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.  References

7.1.  Normative References








Dijkhuis                  Expires 24 July 2025                 [Page 26]

Internet-Draft                     HDK                      January 2025


   [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>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/rfc/rfc4648>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [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>.



Dijkhuis                  Expires 24 July 2025                 [Page 27]

Internet-Draft                     HDK                      January 2025


   [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,



Dijkhuis                  Expires 24 July 2025                 [Page 28]

Internet-Draft                     HDK                      January 2025


              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>.

Acknowledgements

   This design is based on ideas introduced to the EU Digital Identity
   domain by Peter Lee Altmann.

   Helpful feedback came from Emil Lundberg, John Bradley and Remco
   Schaar.

Contributors

   Micha Kraus


Author's Address

   Sander Dijkhuis (editor)
   Cleverbase
   Email: mail@sanderdijkhuis.nl









Dijkhuis                  Expires 24 July 2025                 [Page 29]