# HLB Work packages and Data structures

### Governikus work packages

:::info
The DIDComm data structures may differ from the SDK's final implementation. Nevertheless, the flow should remain the same.
:::

:::info
More detailed examples with APIs and examples would be provided at a later point.
:::

##### Configuring the SDK
The SDK can be configured via a JSON / YAML file. The main areas of configuration are:

The “plugin“ implementations used by the SDK. A set of core plugins / components are required (e.g. a DID resolver plugin, Key Manager plugin) and are included with the SDK distribution. Any plugin can be replaced with a custom implementation (given the expected interface is satisfied) to extend / customize the SDK instance. In many cases this configuration section can remain unchanged.

Locations for artifacts / dependencies managed by the SDK instance (e.g. the location to which logs should be persisted, the location of the databases used by the SDK to persist data / managed identities).

Configuration for the identities / DIDs which should be managed by the SDK instance. This allows developers to define all required roles / identities up-front (with associated labels). The SDK will then ensure that the appropriate identities are loaded / created as part of the starting process. An additional configuration option, didcommService can be included as well, which will result in a corresponding service section being added to the identity DID Document. The URL included with this configuration option will be used by other interacting parties (e.g. Wallets) to send responses.

In future releases additional configuration options might be included here (i.e. the roles this identity can take, the DID method used to create this identity, callbackURLs specific to this issuer or verifier, etc.).

{
  "plugins": [
    //.. Configuration for the registered plugins (e.g. DID Resolver)
  ],
  "logger": {
    "level": "info",
    "dir": "./var/logs"
  },
  // Internal, SDK relevant config
  "db": {
    "database_url": "..."
  },
  // Internal, SDK relevant config
  "keri_db_path": "...",
  // Configuration for all identities which should be managed by the SDK.
  // For each included entry, an identity will be created (if not present), and the DID will be populated on identity creation.
  "dids": [
    {
      "did": "",
      "label": "example_verifier",
      "didcommService": "https://example.com/verifier/inbox",
    }
  ]
}

##### Defining Verifiable Presentation requests
Based on the DIF [Presentation Exchange](https://identity.foundation/presentation-exchange/) specification, the verifier (Gateway) can specify what is requested (`input_descriptors`) and the set of constraints which the holder (SmartWallet) has to satisfy (e.g. Verifiable Credential of type `Iso18013DriversLicense`). An example of an `input_descriptor` which defines the constraints for an mDL request can be seen below.

{
  "presentation_definition": {
    "id": "111",
    "input_descriptors": [
      {
        "id": "iso_18013_mdl",
        "name": "Mobile Driving License",
        "purpose": "We want to verify if you have a valid driving license",
        "constraints": {
          "fields": [
            {
              "path": [
                "$.type"
              ],
              "filter": {
                "type": "array",
                "items": {
                  "type": "string"  
                },
                "minItems": 2,
                "contains": {
                  "const": "Iso18013DriversLicense"
                },
              }
            }
          ]
        }
      }
    ]
  }
}

Additionally, the `input_descriptors` can include other [constraints](https://identity.foundation/presentation-exchange/#input-descriptor-object) defined with [JSON Schema](https://json-schema.org/specification.html), such as:
* asserting that the holder's Driving License (or mDL) is not expired
* asserting that they are allowed to drive a specific vehicle based on the mDL's `driving_privileges`
* etc.

> The constraints above will be defined at a later point as soon as we choose the mDL VC data model

##### Requesting Verifiable Presentations

In order to establish an encrypted communication channel with the wallet, the verifier (Gateway) has to use the SDK to generate an [out-of-band invitation](https://identity.foundation/waci-didcomm/#json-message) for the Presentation Request, as seen below. It should be embedded into a SmartWallet deeplink (under the `_oob` query parameter) and returned to the service provider (e.g. HLB), which would then display it as either a QR code (if used on the desktop) or a clickable button (if used on a mobile device). Additionally, the service provider can embed a redirect link to the deeplink, to which the SmartWallet would redirect once the interaction has finished.

{
   "type":"https://didcomm.org/out-of-band/2.0/invitation",
   "id":"f137e0db-db7b-4776-9530-83c808a34a42",
   "from":"did:example:issuer",
   "body":{
      "goal_code":"streamlined-vp",
      "accept":[
         "didcomm/v2"
      ]
   }
}

Finally, the holder (SmartWallet) would send a [Presentation Proposal](https://identity.foundation/waci-didcomm/#step-2-send-message-proposing-presentation) message to the `didcommService` specified in the verifier's DID Document, an example of which can be seen below. Note that the `phtid` (parent thread id) should match the invitation's `id`. Following the establishment of the encrypted channel between the holder and the verifier, both can securely exchange messages, as described in the following section.

{
    "type": "https://didcomm.org/present-proof/3.0/propose-presentation",
    "id": "95e63a5f-73e1-46ac-b269-48bb22591bfa",
    "pthid": "f137e0db-db7b-4776-9530-83c808a34a42",
    "from": "did:example:prover",
    "to": ["did:example:verifier"]
}

As a follow up to the Presentation Proposal, the verifier would send an HTTP response with a [Request Presentation](https://identity.foundation/waci-didcomm/#step-3-send-message-requesting-presentation) message, which the SDK would generate based on the provided `input_descriptors`. As soon as the holder receives the presentation request, it will attempt to find the requested Verifiable Credentials based on the verifier's `input_descriptors` e.g. the mDL VC. If successful, the holder would send the verifier the requested Verifiable Credentials as a [Verifiable Presentation](https://identity.foundation/waci-didcomm/#step-4-present-proof), as seen below.

{
  "type": "https://didcomm.org/present-proof/3.0/presentation",
  "id": "f1ca8245-ab2d-4d9c-8d7d-94bf310314ef",
  "thid": "95e63a5f-73e1-46ac-b269-48bb22591bfa",
  "from": "did:example:prover",
  "to": [
    "did:example:verifier"
  ],
  "body": {},
  "attachments": [
    {
      "id": "2a3f1c4c-623c-44e6-b159-179048c51260",
      {...},
      "data": {
        "json": {
          {...},
          "holder": "did:example:123",
          "verifiableCredential": [
              // Requested Verifiable Credentials
          ],
          "presentation_submission": {
            // input_descriptor mapping to Verifiable Credentials
          },
          "proof": {
            // Presentation proof/signature
          }
        }
      }
    }
  ]
}

Finally, the requested Verifiable Credential (mDL) will be included in the Verifiable Presentation. By using the SDK's HTTP API, the verifier can access it by using WebHooks, as defined in the SDK's [HTTP API document](https://bafybeibb3fq43nicbg7dwg5zbztd7xz4462y2tb265jg7v2buuavlsavlu.ipfs.infura-ipfs.io/).

As for the Verifiable Credential itself, the mDL can be represented in several ways, according to the [W3C draft](https://w3c-ccg.github.io/vdl-vocab). The [first example](https://w3c-ccg.github.io/vdl-vocab/#example-a-iso18013-5-mdl-expressed-as-a-w3c-verifiable-credential-featuring-an-ed25519-digital-signature) preserves the ISO 18013 mDL's data model, while the [second one](https://w3c-ccg.github.io/vdl-vocab/#example-a-iso18013-5-mdl-expressed-as-a-w3c-verifiable-credential-featuring-an-ed25519-digital-signature-0) is modelled in a way that is closer to the W3C's Verifiable Credential specification. Either version can be used for the Gateway integration.

### SmartWallet work packages

##### Update all the interaction flows

Since the SDK 2.0 will use the Aries RFCs for credential exchange, specifically [issue-credential](https://github.com/hyperledger/aries-rfcs/tree/main/features/0453-issue-credential-v2) and [present-proof](https://github.com/hyperledger/aries-rfcs/blob/main/features/0454-present-proof-v2/README.md) in combination with DIF's [Presentation Exchange](https://identity.foundation/presentation-exchange/), all of our interaction flows will have to be updated. This would include both the integration of the SDK and UI/UX changes. For the first iteration(s), the biggest UI/UX changes will happen to the Credential Share (present-proof) flow. The other ones (Credential Issuance and Authentication) would not change much for the beginning.

##### Remove seedphrase recovery

Compared to the first version of the SDK, we no longer have the option of displaying to the user their seedphrase, which was used for recovering their identity in case they don't have access to their device. Additionally, the seedphrase was also used for recovering the user's device PIN in case it was forgotten. As a result, we would have to research/implement alternative ways of recovering both the identity (e.g. backing up the data and the private keys) and the device PIN.

##### Other work packages

* Support credential management with SDK 2.0
* Support the establishment of secure connections + UI/UX
* Support initiating the (new) interaction flows with deeplinks
* Support exchanging credentials by using [connections](https://github.com/hyperledger/aries-rfcs/blob/main/features/0160-connection-protocol/README.md) + UI/UX
* Convert the mDL into a Verifiable Credential
* define the mDL metadata based on DIF's [Credential Manifest](https://identity.foundation/credential-manifest/) specification
* Integrate the latest version of the BDR's mDL SDK in the SmartWallet + UI/UX
* both iOS and Android

### Questions

* How would the Gateway interface with the SDK?
* Direct calls to the SDK (language specific)
* HTTP API (language independent)