IDealWALLET|Specification

Abstract

Most Decentralized Identifier (DIDs) target Distributed Ledgers Technologies (DLT) or require to be online to achieve a sufficient level of trust. This document serves the specification for the generation and interpretation of an offline capable DID method branded KASMIR DID.

1. Conformance

In this document the key words MAY, MUST, MUST NOT, and SHOULD are used and to be interpreted as described in [RFC2119] and when they appear, they are capitalized.

2. Terminology

ASM

Hardware Secure Module with installed Secure Applet

DID

Decentralized Identifier [DID-CORE]

DLT

Distributed Ledgers Technologies

EC

Elliptic Curves

Holder

the subject who holds one or more credentials and generating presentations from them

HSM

Hardware Secure Module

ID

identifier is a name that identifies/labels a unique class of objects

Issuer

creating and issuing a credential

IRI

Internationalized Resource Identifiers

JSON

JavaScript Object Notation

JWK

JSON Web Key as specified in [RFC7517]

KAPRION

Cooperative and Adaptive Process Interoperability Online Network (Kooperatives und Adaptives Prozess-Interoperabilitäts-Online-Netzwerk)

KASMIR

KAPRION ASM Mír

SSI

Self-Sovereign Identity, a paradigm of digital identity control that returns control of an entity’s own digital being to that entity itself.

URI

Uniform Resource Identifier

URN

Uniform Resource Name

UUID

Universally Unique Identifier

Verifier

is receiving one or more credentials, optionally inside a presentation, for processing

W3C

World Wide Web Consortium

Witness

is an entity which validates or anchors the key event log with key states.

3. Introduction

In den meisten Fällen kann keine flächendeckende Garantie ausgesprochen werden, dass Geräte, die digitale Kommunikationsfähigkeiten besitzen, immer an einem aktiven Netzwerk hängen und somit nicht immer online auf Daten zugreifen können. Für die meisten web-basierende Angebote stellt das kein Problem dar, da sie ohnehin nur online verfügbar sind, dennoch sollten Daten ebenso leicht ohne Drittnetze (im folgendem als offline bezeichnet) austauschbar sein, ähnlich wie seit Jahrhunderten Zahlungsmittel ihren Besitzer wechseln. Eine offline fähige ID muss jedoch auch auch vertrauenswürdig sein, denn schließlich hat ein Gerät nicht immer die gleichen interfaces wie ein etwaiger menschlicher Konterfei, um zusätzliche attribute zu prüfen. Diese Anforderungen gelingen nur in zusammenspiel verschiedener Komponenten. Im folgendem wird die did:kasmir vorgestellt, verschiedene Technologien vereint, bzw. erweitert.

Zur Offlinefähigkeit wird als Anforderung eine ledger agnostic voraus gesetzt, die u.a. von [DID-KEY], wo der identifier den public key darstellt, [DID-WEB] [DID-PEER] [DID-KERI]

  • Anforderungen HSM, offline, ohne DLT, Interop

  • basiert auf einer modifizierten KERI

  • merge peer / web

The DID method MUST be ledger agnostic

The KASMIR DID specification conforms the requirements of the Decentralized Identifiers v1.0 Specification [DID-CORE] and will be prefixed with did:kasmir.

4. Concept

4.1. Keys

4.5. Key State

tbd.

The [did:peer section for Method 2](https://identity.foundation/peer-did-method-spec/#generation-method) describes how all keys can be compressed as one long identifier. In KERI it is not forbidden to generate something similar but other information also need to be added. Also there is a big disadvantage because it is not realy efficient to handle such long identifier in the Applet. Therefore I (@Tobias) recommend to generate a URL like string as it is described in the [W3C Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/#did-url-syntax) specification. As described above the key state object is part of the DID document so it might be useful to attach it as part of a base64url encrypted DID fragment.

did:keri:prefix#base64KeyStateObject

Alternatively a query could be constructed:

did:keri:prefix?keyState=base64KeyStateObject

If we assume the ICP event above is the last key state event, then we can create

did:keri:EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM#ImtleVN0YXRlIjp7InYiOiJLRVJJMTBKU09OMDAwMTFjXyIsImkiOiJFWkFvVE5aSDNVTHZhVTZaLWkwZDhKSlIybm13eVlBZlNWUHpoelM2YjVDTSIsInMiOiIwIiwidCI6ImljcCIsImt0IjoiMSIsImsiOlsiRGFVNkpSMm5td3laLWkwZDhKWkFvVE5aSDNVTHZZQWZTVlB6aHpTNmI1Q00iXSwibiI6IkVaLWkwZDhKWkFvVE5aSDNVTHZhVTZKUjJubXd5WUFmU1ZQemh6UzZiNUNNIiwid3QiOiIxIiwidyI6WyJEVE5aSDNVTHZhVTZKUjJubXd5WUFmU1ZQemh6UzZiWi1pMGQ4SlpBbzVDTSJdLCJjIjpbIkVPIl19

or

did:keri:EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM?keyState=eyJ2IjoiS0VSSTEwSlNPTjAwMDExY18iLCJpIjoiRVpBb1ROWkgzVUx2YVU2Wi1pMGQ4SkpSMm5td3lZQWZTVlB6aHpTNmI1Q00iLCJzIjoiMCIsInQiOiJpY3AiLCJrdCI6IjEiLCJrIjpbIkRhVTZKUjJubXd5Wi1pMGQ4SlpBb1ROWkgzVUx2WUFmU1ZQemh6UzZiNUNNIl0sIm4iOiJFWi1pMGQ4SlpBb1ROWkgzVUx2YVU2SlIybm13eVlBZlNWUHpoelM2YjVDTSIsInd0IjoiMSIsInciOlsiRFROWkgzVUx2YVU2SlIybm13eVlBZlNWUHpoelM2YlotaTBkOEpaQW81Q00iXSwiYyI6WyJFTyJdfQ

Note: The JSON was minified before base64url encoding

A simple key state event from [KERI] whitepaper
{
    "v" : "KERI10JSON00011c_",
    "i" : "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM", //DID of owner = controller
    "s" : "0",
    "t" :  "icp",
    "kt":  "1",
    "k" :  [
             "CF5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp",    //C ~ X25519KeyAgreementKey2019
             "DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",    //D ~ Ed25519VerificationKey2018 or Ed25519VerificationKey2020 (just choose one)
             "1AABAsL0-AEWBfl876zt4XcTWpGcA4V248OF-n-8gou45OZA" //1AAB ~ EcdsaSecp256k1VerificationKey2019
           ],
    "n" :  "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
    "wt":  "1",
    "w" : ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
    "c" :  ["EO"]
}

4.6. Resolver Metadata

tbd.

Like did:peer KERI keys also can have a purposecode and transform information but it is not encoded in constant two bytes, depending on purpose and/or key type the code length can go up to 12 bytes. At the moment only a length up to 4 bytes is documented.

4.7. The DID Document

tbd.
  • DID Doc used in DIDComm

  • Key State compact but needs to be resolved to DID Doc

  • Key Log a set of Key states

see issue 20 IDeal wallet

A simple DID document taken from example 1 of [DID-CORE]
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

5. DID Specification

5.1. Method Name

The method name that identifies this DID method MUST be: kasmir.

When did:kasmir is used a ASM which fulfills KAPRIONs KASMIR Applet specification MUST be used, an additional registry, such as DLT, MAY be optionally. If connected to an additional register the KASMIR method name MUST be pressent to identify the additional capabilities of the KASMIR applet.

Possible DID strings:
  • did:kasmir:method-specific-id

  • did:peer:3method-specific-id; Note the numalgo 3 is not yet defined Peer DID Method.

  • did:indy:kasmir:method-specific-id

  • did:indy:sov:kasmir:method-specific-id

  • did:…:kasmir:method-specific-id

5.2. Method Specific Identifier

Like in KERI the method specific identifier for the kasmir method is a self-addressing identifier which is fully generated and maintained within the ASM and protected by hardware.

The KASMIR self-addressing identifier is cryptographically bound to the inception keys used to create it.

6. Protocols

6.1. Create

wip.
  1. Required Applet calls

    1. init Key Object

    2. add n key(s)

    3. add m witness(es)/anchors

    4. gen method-specific-id

  2. Generate Key State

    1. add public keys

    2. add info about next keys

    3. add witness(es) and anchors (otional)

    4. sign the ICP

    5. store the ICP in a key event log (KEL)

  3. generate DID document (App)

    1. convert key event message to JSON

    2. extract prefix and gen did-string

    3. extract keys and add them to verificationMethod object

    4. add additional info

    5. add JSON key event message to DID document

6.1.1. Prefix generation

Symbols
  • \(N\) … prefix derivation code letter

  • \(H\) … SHA-256

  • \(D\) … Base64URL derivation

  • \(Q\) … current Public Key

  • \(Q'\) … next Public Key

  • \(\hat{Q}\) … witness Public Key

  • \(pab\) … prefix agreement byte

Generation process
  1. generate the full KERI object (add keys & witness & prefix agreement byte aka configuration mode)

  2. generate a SHA-256 hash over all pre-rotaded public keys

    \[next = H(Q'_0, \cdots, Q'_n), n \in \mathbb{N}\]
  3. generate a SHA-256 hash over all current public keys

    \[current = H(Q_0, \cdots, Q_n), n \in \mathbb{N}\]
  4. generate a SHA-256 hash over all witnesses

    \[witnesses = H(\hat{Q}_0, \cdots, \hat{Q}_m), m \in \mathbb{N}\]
    This step can provide a hen-egg-problem if the witnesses isn’t already established and the event is not a delegated inception event (DIP), therefore this is at the moment a not available for public.
  5. concatenate prefix agreement byte, current, next and witnesses and generate a SHA-256 hash

    \[data = H(pab \mathbin\Vert current \mathbin\Vert next~[\mathbin\Vert witnesses])\]
  6. generate a Base64URL string of the resulting hash

    \[digest = D(data)\]
  7. add derivation code for KAPRION Version

    \[method-specific-id = \text{'N'} \mathbin\Vert digest\]

6.2. Read

tbd.
sequenceDiagram
    Alice->>John: Hello John, how are you?
    John-->>Alice: Great!
    Alice-)John: See you later!

6.6. Resolving (offline)

tbd

How to resolve KERI DID into DID document (meaning JSON object didDocument as per [DIDComm v2 docs](https://w3c-ccg.github.io/universal-wallet-interop-spec/#example-3-a-did-resolution-response)) - not just KERI DID is needed for this, but also KEL (Key Event Log) or its current [Key State object](https://identity.foundation/keri/did_methods/#keyState)

  1. get KEL (Key Event Log) from keyState query parameter and service (if available) from service parameter

  2. extract prefix string from KEL (attribute i) and generate did as did:keri:prefix

  3. extract keys (attr. k) from KEL (ICP or last ROT event) - those are actually only x-coordinates of the pub. key

  4. build DID document -for each key:

  5. convert x-coordinate to Base64URL format by removing [derivation code](https://github.com/decentralized-identity/keri/blob/master/kids/kid0001.md#derivation-codes) (e.g. D) and adding =

    • e.g. DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM=

  6. Use [proper crypto algorithm](https://cryptobook.nakov.com/asymmetric-key-ciphers/elliptic-curve-cryptography-ecc#public-key-compression-in-the-elliptic-key-cryptosystems) to create full pub. key from the x-coordinate

  7. encode the pub.key in Base52 format

  8. Get a key type by the [derivation code](https://github.com/decentralized-identity/keri/blob/master/kids/kid0001.md#derivation-codes) (1st. char or first 4 chars)

  9. Get key controller from attr. i - we assume the controller is the DID owner

  10. Get key rights ([verification relationship](https://www.w3.org/TR/did-core/#verification-relationships) - authentication, assertionMethod, keyAgreement, capabilityInvocation…​)

    • keyAgreement is for key with derivation code C

    • all other is for key with derivation code 1AAB (or D)

  11. add last Key State (ICP or ROT) as DID Document Metadata as defined in [2.5 Resolver Metadata](https://identity.foundation/keri/did_methods/#resolvermetadata)

References