Skip to content
This repository has been archived by the owner on Apr 2, 2024. It is now read-only.

gematik/poc-fue-credentialExchangeLib

BranchesTags

Repository files navigation


Credential Exchange Library for kotlin

About The Project

This Work ist part of a discontinued collaboration within IDUnion project.

The “credential exchange library for kotlin” implemenents a technology stack that allows to implements issuer, holder and verifier of the eco system described in chapter 1.2 of the "Verifiable Credentials Data Model" [vcdm]. It can be used on top of jvm or android. The library is an experimental implementation to proof existing and new concepts based on the following technology stack:

technology stack
@startuml

frame "applications" {
    [android app]<<issuer, holder, verifier>>
    [web app]<<issuer, holder, verifier>>
}

frame "protocols" {
    [W3C-Verifiable Credentials Data Model (Verifiable Credentials)]
    [DIF-Manifest (Issuing Credentials)]
    [DIF-Presentation Exchange (Exchange Presentations)]
}

frame "data integrity" {
    [W3C-CryptoVocabulary (LD Proofs)]
}

frame "transports" {
    [DIF-DIDComm Messaging V2]
    [RFC-WebSockets]
}

frame "data representation" {
    [RFC-JSON]
    [W3C-JSON-LD]
    [W3C-JSON-LD-Framing]
}

[web app] -down[hidden]-> [DIF-Manifest (Issuing Credentials)]
[DIF-Manifest (Issuing Credentials)] -down[hidden]-> [W3C-CryptoVocabulary (LD Proofs)]
[DIF-Manifest (Issuing Credentials)] -down[hidden]-> [DIF-DIDComm Messaging V2]
[DIF-Manifest (Issuing Credentials)] -down[hidden]-> [RFC-JSON]
@enduml

The goal of this library is not to implement the above-mentioned specifications completely. Instead, it uses the definitions of the specs where suitable and tries to simplify the implementation where ever possible to get a light-weight and versatile-usable library. The current version of the library supports the following features:

  • W3C verifiable credentials and presentations as described in chapter 3 "Core Data Model" of "Verifiable Credentials Data Model v2.0" [vcdm]

  • Protocols to issue credentials (issuer - holder) and to present them (holder - verifier) based on but not compliant to the mechanisms described in "Credential Manifest" [credential-manifest], "Presentation Exchange 2.0" [presentation-exchange] and the corresponding ARIES RFC’s which define the "credential issueing protocol 2.0" Issue Credential and the "presentation proof protocol 2.0" Present Proof. The library is strictly focused on credentials using JSON-LD and uses JSON-LD framing to query credentials and presentations. ARIES doesn’t support JSON-LD framing. Further, ARIES requires DIDComm to establish and maintain connections. This library is not restricted to DIDComm. Instead, it defines an abstract connection object which can be implemented using specific transports (e.g. web sockets, DidComm, …​). So the library is based on the above-mentioned specifications, but is not interoperable with ARIES.

  • JSON [json] and JSON-LD JSON-LD to serialize, deserialize and normalize credentials, presentations and exchange protocol messages.

  • JSON-LD-Framing [json-ld-framing] to selectively query credentials and presentations

  • Invitations

    • different transport mechanisms (QR-Code, NFC, BLE)

    • different service types (DidCommV2, WebSocket)

  • Interchangeable connection management:

    • DidCommV2

    • WebSockets

  • generic, message based signature and proofing scheme in order to support selective disclosure with different signature algorithms even post quantum cryptography

  • different proof types and signature machanisms to support a wide range of use cases:

    • Ecdsa secp256r1 to support:

      • high level of assurance with hardware protected keys

      • hardware based cryptoboxes for device binding including key attestation

      • biometric protected keys for holder binding using device and biometric binding

      • asynchronous signing to allow user interaction for biometric confirmation (fingerprint and face id)

    • Ecdsa secp256k1 to support interoperability with eco-systems based on Koblitz curve cryptosystems

    • BBS+ for zero knowledge based selective disclosure

    • Dillithium to support post quantum signatures. This library demonstrates post quantum signatures in combination with selective disclosure.

  • The layered architecture allows to combine the different technologies. E.g. the library allows to implement a wallet which request credentials using WebSockets and presents them using DidComm). A presentation can contain an authentication proof based on secp256r1 to implement holder binding based on device and biometric binding and BBS+ proof to allow selective disclosure.

For the sake of simplicity the library doesn’t support to request lists of credentials. Instead, the holder requests every credential separately. Consequently, the corresponding property fullfilment ([credential-manifest]) is not implemented. JSON-LD-Framing is used to specify the credentials. Consequentlty, the special syntax defined in the [credential-manifest] and [presentation-exchange] to define credential in input- and outputdescriptors is not used.

Overview

The library implements the necessary protocols to issue credentials from the issuer to the holder and to present credentials from the holder to the verifier. The library can be used in the backend to implement cloud agents or in the frontend to implement mobile agents. Please note that an agent can act in different roles (E.g. an issuer can act as verifier to collect claims about the holder before issuing a credential; a verifier can act as holder in order to proof that he is authorized to requests and verify claims about the holder etc.) Nevertheless, this specification will refer to a specific agent by using the role which reflects its primary purpose.

ecosystem overview - [vcdm]
@startuml
[Issuer] <<agent>>
[Holder] <<agent>>
[Verifier] <<agent>>
[Issuer] -right- [Holder] : Issue Credentials
[Holder] -right- [Verifier] : Present Proof
[Issuer] -down- [Verifiable Data Registry] : Verify Identifiers
[Holder] -down- [Verifiable Data Registry] : Register Identifiers
[Verifier] -down- [Verifiable Data Registry] : Verify Identifiers
@enduml

The library doesn’t make any assumptions about the "Verifiable Data Registry". DID’s are used as identifier. The library implements did:peer and did:key which don’t require a verifiable data registry. In order to support other did methods (did:web, did:indy, did:sov, did:ether) a suitable did resolver needs to be integrated to resolve the verificationMethod of the LDProof. The establishing of the trust relationships to verify identifiers (e.g. Distributed Ledgers, WEB, X509 PKI, …​) is out of scope of this library.

Issue Credential

The issuing protocol can be initiated by the issuer or the holder. The initiation of protocols can be triggered from outside (E.g. the issuer offers a credential after he has authenticated the holder and collected enough information to issue a credential) or as nested transaction (E.g. the holder initiated the credential issuing protocol and the issuer spawns a child thread to collect credentials from the holder required to issue the requested credential. After the issuer has collected the required credentials he returns to the parent thread.)

Issuer initiated credential issuing

issuer initiated credential issuing
@startuml
autonumber "[0]"
Issuer -> Holder : Invitation (invitationId, from, goal_code)
Holder -> Holder : Scans and accepts invitation
Issuer <-> Holder : Establishing connection
Issuer <- Holder : Invitation Accept (invitationId)
Issuer -> Holder : CredentialOffer(OutputDescriptor)
Holder -> Holder : Consent
Issuer <- Holder : CredentialRequest(InputDescriptor, HolderKey)
Issuer -> Holder : CredentialSubmit(Credential)
@enduml

Invitation

The issuer (inviter) sends an invitation to the holder (invitee) to invite him to exchange a credential. The invitation message is sent by reusing an existing connection (e.g. existing DIDComm connection) or out-of-band (QR-Code, NFC, BLE, deep link, …​) encoded as oob parameter in an invitation URL. The invitation is a generalized version of the invitation defined in the didcomm V2 specification [didcomm]. The generalized version of the invitation allows establishing of DidComm and other connections (e.g. websockets).

invitation url offering credentials issuing over a websocket
https://my-wallet.me/ssi?oob=ewogICJpZCI6ICI5ZDk5MDNjOC04ZDRjLTQ0YTMtYTRhOS1hMWQwMmY1ZmFiNzciLAogICJmcm9tIjogIndzczovL3ByYXhpcy1zb21tZXJnYXJ0ZW4uZGU6ODA5MCIsCiAgImxhYmVsIjogIlByYXhpcyBTb21tZXJnYXJ0ZW4iLAogICJnb2FsIjogIklzc3VlIFZhY2NpbmF0aW9uIENlcnRpZmljYXRlIiwKICAiZ29hbENvZGUiOiAiT0ZGRVJfQ1JFREVORElBTCIKfQ==
decoded invitation message offering credentials issuing over a websocket
{
  "id": "9d9903c8-8d4c-44a3-a4a9-a1d02f5fab77",
  "from": "wss://praxis-sommergarten.de:8090",
  "label": "Praxis Sommergarten",
  "goal": "Issue Vaccination Certificate",
  "goalCode": "OFFER_CREDENDIAL"
}

  • id: REQUIRED. Unique identifier of the invitation. The invitee sends this id back during establishing of connection in order to allow the inviter to correlate the connection request with the invitation.

  • from: REQUIRED. URI of the sender of the invitation. The invitee sends the invitation accept message to this URI. The scheme defines how to process the URI:

    • did: resolve the did document to get service endpoint and the public keys of the inviter for authentication and agreement (encryption) to establish a didcomm V2 connection - [didcomm]

    • wss: establish a secure websocket connection tunneled over Transport Layer Security - [websocket]

  • label: OPTIONAL. Describes the inviter of the message. The receiver may want to display the label to the user.

  • goal_code: OPTIONAL. A pre-defined code the receiver shall use in automatically deciding what to do with the out-of-band message. The library pre-defines the following goal_codes:

    • OFFER_CREDENDIAL: indicates that the credential issuing protocol shall be initiated by the issuer by sending a credential offer

    • REQUEST_CREDENTIAL: indicates that the credential issuing shall be initiated by the holder by sending a credential request

  • goal: OPTIONAL. A self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message.

Holder accepts invitation

The holder scans the invitation (QR-Code, NFC-Tag) and accepts it.

Connection Establishing

After accepting the invitation the holder and connects to the inviter specified by the invitation parameter from to establish a secure two-way communication. The library has implemented two connection types:

The above-mentioned invitation requests to establish a secure web-socket connection wss to the host healthinsurancenorth.com.

The library defines a generic connection object which can be extended to implement other connection types (e.g. for proximity use cases: Wifi-Direct, BLE, …​). The connection type to be used by the invitee is defined by the uri scheme of the parameter from.

TODO: implementation of proximity use cases using BLE or Wifi Direct to proof concept

After the connection is established the inviter and invitee can exchange message over a secure channel until the connection is closed by one of the peers.

Invitation Accept

In order to indicate to the issuer the acceptance of the message the holder sends an invitation accept message.

invitation accept message
{
  "invitationId": "9d9903c8-8d4c-44a3-a4a9-a1d02f5fab77"
}

  • invitationId: REQUIRED. The unique id of the accepted invitation. The issuer (inviter) can use this id to find the accepted invitation. If the invitation was sent via a secure channel (e.g. DidComm, postal mail, person-to-person, …​) to a specific holder (invitee) the issuer can make assumptions about him.

  • otp: OPTIONAL. If a higher level of assurance about the authenticity of the invitee is required the inviter can use a separate communication channel (e.g. a second postal mail, SMS, …​) to send an additional one time password to the invitee. In this case the invitee has to set the parameter otp to the received one time password.

TODO: support of parameter otp not yet implemented in library

Credential Offer

The issuer sends a credential offer to the holder describing the credentials he is offering. From a functional perspective the credential offer is similar to the DIF credential manifest. On the other hand they are quite different:

  • The credential offer uses the @context property to define the context and defining the version. Therefore, the property spec_version is not used.

  • The property outputDescriptor uses JSON-LD framing to describe the credential offered by the issuer.

  • The property presentation_definition is not used. Instead, if the issuer requires additional data from the holder to issue a credential he starts a nested presentation exchange protocol to collect them. This approach is more flexible, simplifies the issuing protocol and reduces the dependencies between credential issuing and presentation exchange protocol.

  • The protocol is focusing on W3C credentials and JSON-LD. Therefore, the only supported credential format is LDP_VC. A explicite format property is not required.

The following credential offer offers a VaccinationCertificate. The supported content is defined by the property frame. The frame defines the context and the type of the credential. Further, it allows the issuer to restrict the supported claims to a subset of the claims defined in the referenced context using LD-Framing (see [json-ld-framing].

credential offer
{
  "id": "53825166-796f-428f-9783-7768a04e01b3",
  "@context": "https://gematik.de/credential-exchange/v1",
  "type": "CredentialOffer",
  "outputDescriptor": {
    "id": "9ce38bcc-1ac0-4f18-99eb-df179888bc03",
    "frame": {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/vaccination/v1"
      ],
      "type": "VaccinationCertificate"
    }
  }
}

  • id: OPTIONAL. Unique node identifier of the credential offer - see JSON-LD.

  • @context: REQUIRED. Defines the context of the conversation. @context refers to a pre-defined context which defines the semantic of the vocabulary used within the credential offer. By defining the vocabulary issuer and holder can communicate with one another more efficiently without losing accuracy - see JSON-LD.

  • type: REQUIRED. IRI specifing the type of the node (request) - see JSON-LD. Must be set to CredentialOffer which expands to https://gematik.de/credentialexchange#CredentialOffer

  • outputDescriptor: REQUIRED. Descriptor which describes the credential offered by the issuer.

    • id: OPTIONAL. Unique node identifier of the credential offer - see JSON-LD.

    • frame: REQUIRED. JSON-LD frame which specifies the credential - see [json-ld-framing].

      The holder can use this frame as is to request an instance of the specified credential (in the below example a complete insurance certificate) or extend the frame to describe the requested credential in more detail (e.g. just requesting the insurant data and skip the coverage information).

Consent

The holder application (e.g. a mobile wallet) informs the user about the credential offered by issuer and asks for a consent to request the credential. The application allows the user to specify in more detail the credential he is interested in using the frame received in the credential offer. Based on the consent of the user the application creates a descriptor of the credential using JSON-LD-FRAMING - see [json-ld-framing].

Credential Request

The holder sends a credential request to the issuer to request the consented credential. Further the holder specifies a holderKey that will be used by the issuer to bind the credential to the holder. The library supports asynchronous signing using hardware backed, biometric protected keys. Using these features the credential can be bind to the device of the holder and his biometrics features (fingerprint or faceId).

credential request
{
  "id": "2d615ff6-87f0-4cbe-bfed-f38449c79997",
  "@context": "https://gematik.de/credential-exchange/v1",
  "type": "CredentialRequest",
  "outputDescriptor": {
    "id": "9ce38bcc-1ac0-4f18-99eb-df179888bc03",
    "frame": {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/vaccination/v1"
      ],
      "type": "VaccinationCertificate"
    }
  },
  "holderKey": "did:key:zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM" (1)
}

  1. holder key used by the issuer to bind the issued credential to the holder

properties:

  • id: OPTIONAL. Unique node identifier of the credential request - see JSON-LD.

  • @context: REQUIRED. Defines the context of the conversation. @context refers to a pre-defined context which defines the semantic of the vocabulary used within the credential request. By defining the vocabulary issuer and holder can communicate with one another more efficiently without losing accuracy - see JSON-LD.

  • type: REQUIRED. IRI specifing the type of the node (request) - see JSON-LD. Must be set to CredentialRequest which expands to https://gematik.de/credentialexchange#CredentialRequest

  • outputDescriptor: REQUIRED. Descriptor which describes the credential requested by the holder.

    • id: OPTIONAL. Unique node identifier of the credential offer - see JSON-LD.

    • frame: REQUIRED. JSON-LD frame which specifies the credential - see [json-ld-framing].

      JSON-LD-FRAMING allows the holder to specify the requested credentials accurately. He can just specify the type of credential or specify in details which claims shall be or shall not be asserted in the credential.

  • holderKey: cryptographic material which the holder controls and the issuer can use to bind the issued credential to the holder.

Credential Submit

Finally, the issuer submits the requested credential. The vaccination credential is bound to the recipient of the vaccination by setting the recipient id to the holderKey.

credential submit
{
  "id": "2bc472db-c1c6-4370-b26d-e5147f233876",
  "@context": "https://gematik.de/credential-exchange/v1",
  "type": "CredentialSubmit",
  "credential": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://w3id.org/vaccination/v1"
    ],
    "type": [
      "VerifiableCredential",
      "VaccinationCertificate"
    ],
    "credentialSubject": {
      "type": "VaccinationEvent",
      "order": "3/3",
      "batchNumber": "hlh",
      "dateOfVaccination": "2024-02-21T12:00:00Z",
      "administeringCentre": "Praxis Sommergarten",
      "healthProfessional": "883110000015376",
      "countryOfVaccination": "GE",
      "nextVaccinationDate": "2024-08-21T12:00:00Z",
      "recipient": {
        "id": "did:key:zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM", (1)
        "type": "VaccineRecipient",
        "birthDate": "1965-05-04T12:00:00Z",
        "familyName": "Mustermann",
        "givenName": "Max",
        "gender": "Male"
      },
      "vaccine": {
        "type": "Vaccine",
        "atcCode": "J07BX03",
        "medicalProductName": "Bimervax",
        "marketingAuthorizationHolder": "HIPRA Human Health S.L.U."
      }
    },
    "issuer": "did:key:zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv",
    "issuanceDate": "2024-02-21T11:27:26Z",
    "proof": {
      "@context": "https://w3id.org/security/bbs/v1",
      "type": "BbsBlsSignature2020",
      "created": "2024-02-21T11:27:26Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "did:key:zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv#zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv",
      "proofValue": "uOa4nfIpBY695dc9bo0akhzKAkqU9g4yz+00SaCF/ACgaQhEEwZQmTnEw9zdbIDQCxhHBjUk/tipv32d93RyIlnQaiy9xlYA/qxilfQ23HYNMOalZYCLP8lVlEFQh0MhEHFOsybSoHuUIP8COvap4g=="
    }
  }
}

  1. credential is bound to the vaccination recipient by setting his id to the holder key

properties:

  • id: OPTIONAL. Unique node identifier of the credential request - see JSON-LD.

  • @context: REQUIRED. Defines the context of the conversation. @context refers to a pre-defined context which defines the semantic of the vocabulary used within the credential request. By defining the vocabulary issuer and holder can communicate with one another more efficiently without losing accuracy - see JSON-LD.

  • type: REQUIRED. IRI specifing the type of the node (request) - see JSON-LD. Must be set to CredentialSubmit which expands to https://gematik.de/credentialexchange#CredentialSubmit

  • credential: REQUIRED. Credential as specified in [vcdm].

Present Proof

The presentation exchange protocol can be initiated by the holder or the verifier. Either the holder sends a presentation offer request to the verifier to indicated his willingness to share a presentation or the verifier send a presentation request to the holder. The triggering of the presentation exchange protocol is independent of who has engaged the communication. Instead, the triggering is pre-agreed by the parties or defined by the goal_code in the invitation message.

Holder initiated presentation exchange

holder initiated presentation exchange
@startuml
autonumber "[0]"
Holder -> Verifier : Invitation (invitationId, from, goal_code)
Verifier -> Verifier : Scans and accepts invitation
Holder <-> Verifier : Establishing connection
Holder <- Verifier : Invitation Accept (invitationId)
Holder -> Verifier : PresentationOffer(InputDescriptor)
Holder <- Verifier : PresentationRequest(InputDescriptor)
Holder -> Holder : Consent
Holder -> Verifier : PresentationSubmit(Credential)
@enduml

Invitation

decoded invitation message offering to present vaccination certificate over didcomm
{
  "id": "131ba536-040b-4efd-a1bd-f1cffc1c5e9e",
  "from": "did:peer:2.Ez6LScFUqjx36MtH5y8TNWVDSXmtD8PFU6XicsWXGvGwpyWdW.Vz6MkvejenJQzJXQPUVcJk2g7ruyg283jfx7oJHmAZvvieyn2.SeyJpZCI6IjhkMGI3NjI1LTRjZWUtNDJkYi1iYzA5LWEyYmY1NDE3ZGNjOSIsInQiOiJkbSIsInMiOnsidXJpIjoiaHR0cDovLzE5Mi4xNjguMTc4LjEwMjo5MDk1L2RpZGNvbW0iLCJyIjpbXSwiYSI6WyJkaWRjb21tL3YyIl19fQ",
  "label": "Mobile Wallet 2",
  "goal": "Present VaccinationCertificate",
  "goalCode": "OFFER_PRESENTATION"
}

Verifier accepts invitation

The verifier accepts the invitation using the same procedure as described in chapter [_holder_accepts_invitation]

Connection Establishing

The connection is established as described in chapter [_connection_establishing], but this time the property from of the invitation requests a didcomm connection to a specific peer did did:peer. The verifier resolves the did to get the did document and establishes the connection to the service point defined in the did document.

Invitation Accept

The verifier sends an invitation accept as described in chapter [_invitation_accept].

Presentation Offer

presentation offer offering an insurant certificate and vaccination certificate
{
  "id": "658b1626-b701-4b9f-a36b-813e85a7840d",
  "@context": "https://gematik.de/credential-exchange/v1",
  "type": "PresentationOffer",
  "inputDescriptor": [
    {
      "id": "39755ad8-a4ee-4ac6-929d-52d8203a102a",
      "frame": { (1)
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://w3id.org/vaccination/v1"
        ],
        "type": [
          "VerifiableCredential",
          "VaccinationCertificate"
        ]
      }
    },
    {
      "id": "4e933ab1-e536-4692-a6dd-db3c6da600e2",
      "frame": { (2)
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://gematik.de/vsd/v1"
        ],
        "type": [
          "VerifiableCredential",
          "InsuranceCertificate"
        ]
      }
    }
  ]
}

  1. frame specifying vaccination certificate

  2. frame specifying insurant certificate

The holder sends a presentation to indicate which credentials he is willing to share with the verifier. The holder uses JSON-LD framing to define the type of the credentials as well as the claims which he is willing to disclose. In the above example the holder is willing to share his insurance certificate and his vaccination certificate with all contained claims.

Presentation Request

presentation request requesting proof of vaccination status and identity of vaccinated person
{
  "@context": "https://gematik.de/credential-exchange/v1",
  "type": "PresentationRequest",
  "inputDescriptor": [(0)
    { (1)
      "id": "4de5606d-cede-4571-9a1b-260c0c8e62d2",
      "frame": {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://w3id.org/vaccination/v1"
        ],
        "type": [
          "VerifiableCredential",
          "VaccinationCertificate"
        ],
        "credentialSubject": {
          "@explicit": true,
          "@requireAll": true,
          "type": [
            "VaccinationEvent" (2)
          ],
          "order": [
            "3/3" (3)
          ],
          "recipient": { (4)
            "@explicit": true,
            "type": [
              "VaccineRecipient"
            ],
            "id": {
            }
          }
        }
      }
    },
    { (5)
      "id": "984bb32c-70ea-4e3b-9bc3-00af747d146f",
      "frame": {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://gematik.de/vsd/v1"
        ],
        "type": [
          "VerifiableCredential",
          "InsuranceCertificate"
        ],
        "credentialSubject": {
          "@explicit": true,
          "@requireAll": true,
          "type": [
            "Insurance"
          ],
          "insurant": {
            "@explicit": true,
            "type": [
              "Insurant"
            ],
            "id": {
            },
            "portrait": {
            }
          }
        }
      }
    }
  ]
}

  1. input descriptor requests two certificates:

  2. descriptor 1 defines a vaccination certificate which must contain

  3. a vaccination event which is

  4. the third event of a sequence of three events and

  5. the id of the recipient

  6. descriptor 2 defines an insurance certificate which must contain

  7. the id of the insurant and

  8. his portrait

The holder should only request the information he needs to fulfill the use case. In our example he requests the vaccination status (3 of 3) and the id of the vaccination recipient (holder key). Further, he requests the portrait of the insurant and the id of the insurant (holder key). Both certificates needs to be bound to the same holder to complete the authentication.

Consent

The holder declares consent to disclose the following personal information:

  • vaccincation certificate

    • vaccination status

    • id of reciptient (holder key)

  • insurance certificate

    • portrait

    • id of insurant (holder key)

Presentation Submit

presentation submit providing proof of vaccination status and identity of vaccinated person
{
  "id": "9786cb7b-c4eb-4105-8af0-30a1ac958935",
  "@context": "https://gematik.de/credential-exchange/v1",
  "type": "PresentationSubmit",
  "presentation": {
    "id": "ae7aa203-ff6c-485c-9f43-837203915f83",
    "@context": "https://www.w3.org/2018/credentials/v1",
    "type": "VerifiablePresentation",
    "presentationSubmission": {
      "@context": "https://identity.foundation/presentation-exchange/submission/v1",
      "type": "PresentationSubmission",
      "definition_id": "0f11dba3-e5d8-4387-a240-bf715331a668",
      "descriptor_map": [
        {
          "id": "4de5606d-cede-4571-9a1b-260c0c8e62d2",
          "format": "ldp_vc",
          "path": "$.verifiableCredential[0]"
        },
        {
          "id": "984bb32c-70ea-4e3b-9bc3-00af747d146f",
          "format": "ldp_vc",
          "path": "$.verifiableCredential[1]"
        }
      ]
    },
    "verifiableCredential": [
      {
        "id": "urn:bnid:_:c14n0",
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://w3id.org/vaccination/v1"
        ],
        "type": [
          "VaccinationCertificate",
          "VerifiableCredential"
        ],
        "credentialSubject": {
          "id": "urn:bnid:_:c14n1",
          "type": "VaccinationEvent",
          "order": "3/3",
          "recipient": {
            "id": "did:key:zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM", (1)
            "type": "VaccineRecipient"
          }
        },
        "issuer": "did:key:zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv",
        "issuanceDate": "2024-02-21T11:27:26Z",
        "proof": {
          "@context": "https://w3id.org/security/bbs/v1",
          "type": "BbsBlsSignatureProof2020",
          "created": "2024-02-21T11:27:26Z",
          "nonce": "DT4n2kh5k781C6XXhUd73GyChOCGg8/tDL3mU0hEDO8=",
          "proofPurpose": "assertionMethod",
          "verificationMethod": "did:key:zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv#zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv",
          "proofValue": "ABsAwH8Pj9VYwOgbgWV5In1G6/9l1rX/LClIPM+8eM2WdNeQk3veUgTDtb5VQ7vY0yMfkeb8lZYnXZW7cmje8QYu13y1av1s9qkjoWK9aHdHuV5sdseaT7Ni/43hAeGvg/rIcov6gSahnFmqIZIhFDfteW00lphQ/bubEQ1qQ2yKIUSIxiyJSZSkXmPHAWJYQR180Z5GAAAAdKRpTJBXa2cdIEb5ieRmkj2+ktbKH9yIt0hNUJYj21gTz18fjsleIhYdtgTCejU5cgAAAAIJH7TNgPjyaD9zDP/qefaFBg0Sy9WjhjXNBKsmiZ1v/1mGExZkgZitLScpH3UTWYYOXOrqpkhvEFPuwNbv6a1HrZHIoMyb5I8Dsfbkpe4wiwcfhBXgkGd/yM7D4JNnIkgCv2iNtRZgjQE5URPMB0/BAAAAECCOghbL0P45xayTw/G6005rJZkFejhhSXv4a/TbFzHXPH2gwbZttQYHvA8Vx4HcwH2U2UpX1xqOvUxZuuIIxS9ak6Sa60i2kz+Gzd7LtbBrVryGectBULZRRwycP6cWNiU2WoouZedZcuUfRm2uDtxDq1EjDv/Q6GJJk2UMciDbECJ3KWEIXIaoplO2otS2xTwkU0I1P+NGnhA74kqP13JbtSLKFJmF2kc2PXy/t0qA/7HV1mnS8ebSQEJvoQcPNigHwFMHsPK0+f1VZRjAzKw4zJum19vvyRnjO8Z6+m0WYBN+c1kdeCLxI0NRn3T7lNwvE64NyvEa0YdFfCg9HvlOIdrm8Q3ImtwvIiw5st60/zNCJAHs/WHlT/XiEOZxlSXPZCuNNdTPJa7T/F/0H2Qc9+uCiYlkOPcpBor9SxFia6XE5hn8wHk2HLY5FX/UmnDyvlGJP2cCoS637/GbG9ZaY7BTMguMJ8SwdpBuq/o0PECbTpN1YJN4RuqgcZpWuR/0TBVYBqlCI3Z2lsHc+kTp3/nRdFKIkx4upitGgsd+WGwkl3TJfwu9iAirhumHnwDSZHJ7kBUXBxAFk4qtSqkGfEHr6+611uTlcg8yNTKOVHLD7nCIWPV38IhH0oxrgGV6CqHc4J9RQj41dmt1a1N4eHrIws7aKMD9doP7+/tv"
        }
      },
      {
        "id": "urn:bnid:_:c14n0",
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://gematik.de/vsd/v1"
        ],
        "type": [
          "InsuranceCertificate",
          "VerifiableCredential"
        ],
        "credentialSubject": {
          "id": "urn:bnid:_:c14n5",
          "type": "Insurance",
          "insurant": {
            "id": "did:key:zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM", (1)
            "type": "Insurant",
            "https://gematik.de/vsd#insurantPotrait": null
          }
        },
        "issuer": "did:key:zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv",
        "issuanceDate": "2024-02-21T11:26:40Z",
        "proof": {
          "@context": "https://w3id.org/security/bbs/v1",
          "type": "BbsBlsSignatureProof2020",
          "created": "2024-02-21T11:26:40Z",
          "nonce": "qlzt30XMt2BAouuw/IuIu4iofG6jjDHfxc3Uc64t4Rs=",
          "proofPurpose": "assertionMethod",
          "verificationMethod": "did:key:zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv#zUC78bhyjquwftxL92uP5xdUA7D7rtNQ43LZjvymncP2KTXtQud1g9JH4LYqoXZ6fyiuDJ2PdkNU9j6cuK1dsGjFB2tEMvTnnHP7iZJomBmmY1xsxBqbPsCMtH6YmjP4ocfGLwv",
          "proofValue": "ADsAAAUAAAHwH7aPNGe8MjXU9iyBvR7umXCDoIK8qJ4a//4x3rol0r6DToNbex/ZDU/OEVQ88J6buqekh1HB09NmGS+3BiLBoT5sGNEDWq2K147dExyAvjQY+wcepWusbPySU8zmyE2gxIoAx5q4dHfB4kBN7bfoedLJ98liObv84cEz3/BZtDWNN6+cGaUBvXpS+dLz4jElUgAAAHSycbCtTwXUdGlYnvu1GM+ClAqwOEwtu8iJ7LSI6G+EgvKrJ5BHkvyMjKyww8xlnKkAAAACUkrAdwg1zcq4qLUOHLbwW10T58acvDLW9DWw321xjjI/aXC9OzM0yMK7H+J/LEUANXKHrPAOwr0hj432bX8wOo5tNJTyO2Cvi6PWpE19wkyZR8dwvIuGgRCAVOuhKTrQbJK5ZQIxVqNT6+QQO0igtQAAADE/NrKl3pqswT1h1NwgihKJzPMASbdlLjuoIZL9rWpLpBdJcX4WSXbfaoHw3f8EvrP5FJ+ew73eJD4BxG39RadXSBdfUKNuvLWS74u5zvqI6oji0edKqcTf4qXBLRKI/Adu7SdxrtRMVVsY+Zq7moCE/G2bn27XjpGYfiCwKHpVuwtcBj/sBsFfLHhjmFyxWdRfhu+5wOWSu3vzeVVhWxXwbAFK0WZ2CpwbSwEebyjUItRgWxxOtimxBAYLvQTII0ZxXoRvls+2Ko0ws4xMGG1FKAiHOqSYyym3M2wRTNn3pWW1d/r0qmpQ7Z6b9rbLGPnIYy3B3izpjri6h3HeNqKZVMM/jQnbbYF9MlowQmiF29m8dMmd/dZ4KQJdXrlcgIsSnN49ouirvYtuMkpIeiEhc0R0yPr8c+S6YffR7XSbbkyCnOYk9IPqZG6j+MAB7tvFzdQa2CAMMvUmFiKSh12sDPBqSwULFOUL0Ms1tGqfkqBWE1FREdWmld4v1EuB9d9MQcqVYMMXEyxsRILAg8YC9kFAXGXZVUHkuxDh6lAQcinDSRFn9JIIV7AELFvqYY2t8wbsX4GUSAYs74XJmMaPXqTuak6MCwbS5SLKXjWa4zWmGK3ih6stkcmFlRPPOs8JN0CXvKgXny1BpAj6D76/89zkYT/uw7a1l4SV2IZbYgUssma5K9CHVOx4Rs+FcQXGwBp0ol7xHtN3pUUhejFJWeHuC6mITmLcTws70lF+4BZpAtqbXvk9lERWxp2nygtaNoy96r0HLPdgu/iS3HZmpxhJkXbm3DL8+SEFOtDg6ipOvLRCYpe2C6idJXW+e16vvjcAJFvR8YZ35tPm1iYQPONkUHHaiH2MBJYbZsIshJzHhTRsEl8mKVeWx29BvNpvT0BKDoqmhN3J6E7MZWD3w6gR+yX3maHMhhIyvSzIFFU3ir76u5IMy02mpSYSWtNrzsrnraeS9p5ReZzKw4JOAOKI6KYzH3ka1JwdPI6C8tBgAihNZlNh/7cvjl95gu0U4Sob5iw84MuZ0ri62RROZFNVWYWgPiI49vq623a0+GxqeOuYywdUAYy0Nb4W3YD2KpGOLK+zThXcjx/GEkzKaGioqOZAn4pwrMgyP8VMczVx/SBhYyC9swqPDVZLUYVMA9A2APt6QgnVRoY9tK8BnfzFlN5iAJy7UACIzuu5G0C2AYLG/BiZgGI5WxlRvaV8CKY6CXse1C9reEza4ALPQHa1F4dwdZG4uc+t4V8CgvHKAlImtApOpJyVLTOlxQACDuCtSakkcpeaxgH+Ulu/rNe82+0FXn1L/PRUJiiEmy8T1M0nDFbpG9ie4ZlcJXA7T/fIcSk5ut10QWE1G2PzGvptcXKDJ239RI9goZWOs8GOVXZNrA7tJ7iqn2HCOyJIEXhWEPVdWRw7CfGRiJTrUuQ89vJRyuV6i6qaq59MXlSQmvMiqI1+TSaGEQGNFSY4wbTvg69xdp4dFle35ftEDHvEtoUeAyRBGCZowhkezGMuzYmkdoHd8l66PB/K6x9NjSZiHlBaP2LqAk8sJmrYy427GMBymvTUZs97ghuWFlZSJLb6W4PTSorpTzVqW+96eubbtRdiFy9mrhPnimumOIExNOPUg/607XauqpyRaks4db99DR7vPicQ6Gw8Wtw9GfhDwbIjSlBRF5zXxkraviKU68EBzOZKsiOlSKv1wy7Cp8lJxnYVxJBSnhu1SYPue/3bH7ZD8cZVIQEH7DsNVCvqvqVPpKMGPcv6tBsRKVjE1dMexolkAmlj0s9c+nlA/FPtlqRgtC8keaDOZQBFNhyPOssjiXHpEqiOvxUpXRDbgS9TT+JNkt51ny6j27v0Lj6vgGZbnBOJpiGC3MwERwwW4pXQf4V/mZgom6LlFVb1uVhtlcpwzzfFiZBCAOYSH1j/FRTMqzo4m2MoC99v2c6RWEgsKE6yjhMy2YnqlzBQwcJf8D/DQv5a4tNTHn5BsKeZbMwp/xUFYTm6rF3fMjZzVFf6WLN9XU838MUKUHi4s7JyIq8ZZpxI7MMck7AL40gCRKh2hdLKf/Cc/lGpj9muP6HQucz0Vbru51dRSA=="
        }
      }
    ],
    "proof": {
      "@context": "https://www.w3.org/2018/credentials/v1",
      "type": "EcdsaSecp256r1Signature2019",
      "creator": "did:key:zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM", (1)
      "created": "2024-02-21T11:28:08Z",
      "proofPurpose": "authentication",
      "verificationMethod": "did:key:zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM#zDnaeWHPMWj9Q2gjQurBgY9wd7GM8jm94sX54S33BSfqCATvM", (1)
      "proofValue": "p/9uIYg3QPy/gFppz3ren7yhlb6FWk2YuH/Qg/eZCPhNWd7tp0fQOg2X92KGTn5bzzNZbU6tXkJtd41e6m6/sg=="
    }
  }
}

  1. By using the holderKey to provide the authentication proof the holder proofs that he is the legitimated recipient of the vaccination and the legitimated insurant. By using a hardware backed key EcdsaSecp256r1Signature2019, which is physically bound to a specific device and protected by biometric features (fingerprint or faceid), the presentation of the credentials by another person as the legitimated holder will fail.

Components

component diagram
@startuml

skinparam component {
  backgroundColor<<implemented>> LightGreen
}

[Applications kotlin/Android]  <<implemented>> as Applications
[credential exchange] <<implemented>> as CredentialExchange
[credential exchange protocols] <<implemented>> as Protocols
[connections] <<implemented>> as Connections
[WsConnection] <<implemented>> as WsConnection
[DIDCommConnection] <<implemented>> as DIDComm
[didcomm-jvm SICPA] <<implemented>> as SICPA
[kotlin serialization] <<implemented>> as Serialization
[ktor] <<implemented>> as ktor
[Rdf-Urdna] <<implemented>> as RdfUrdna
[JsonLd-Signatures] <<implemented>> as JsonLdSignatures
[jsonld titanium] <<implemented>> as JsonLd
[bbs-signatures (java wrapper)] <<implemented>> as BbsSignature
[   ECDSA\n(secp256r1)] <<implemented>> as secp256r1
[   ECDSA\n(secp256k1)] <<implemented>> as secp256k1
[   EdDSA\n(ed25519)]  <<implemented>> as ed25519
[           Dilithium\n(2(aes), 3(aes) 5(aes))]  <<implemented>> as dilithium
[HW AndroidKeystore] <<implemented>> as AndroidKeystore
[CL-Signatures] as ClSignatures
[bbs_plus (rust)] <<implemented>> as BbsPlus
[bouncycastle] <<implemented>>  as Bouncy
Applications -down- CredentialExchange
CredentialExchange -down- Protocols
CredentialExchange -down- Serialization
CredentialExchange -down- JsonLdSignatures
CredentialExchange -down- JsonLd
RdfUrdna -left- JsonLd
Protocols -down- Connections
Connections -down- WsConnection
WsConnection -down- ktor
Connections -down- DIDComm
DIDComm -down- SICPA
JsonLdSignatures -left- Serialization
Protocols -right- Serialization
Protocols -down- JsonLd
JsonLdSignatures -down- JsonLd
JsonLdSignatures -down- BbsSignature
JsonLdSignatures -down- RdfUrdna
JsonLdSignatures -down- secp256r1
JsonLdSignatures -down- secp256k1
JsonLdSignatures -down- ed25519
JsonLdSignatures -down- dilithium
JsonLdSignatures -down- ClSignatures
BbsSignature -down- BbsPlus
secp256r1 -down- AndroidKeystore
secp256r1 -down- Bouncy
secp256k1 -down- Bouncy
ed25519 -down- Bouncy
dilithium -down- Bouncy
BbsSignature -left[hidden]- RdfUrdna
secp256r1 -left[hidden]- BbsSignature
secp256k1 -left[hidden]- secp256r1
ed25519 -left[hidden]- secp256k1
ClSignatures -left[hidden]- ed25519

note right of Applications
  Demo applications:
  Insurance (Web), Medical Office (Web),
  Wallet (App) and Admission Control (App)
end note

note right of CredentialExchange
  artifact: de.gematik:credentialExchangeLib
  one lib for kotlin, java, Android
end note


@enduml

Communication Stack

The communication stack of the credential exchange library consists of three layers:

  1. Connection layer

  2. Protocol layer

  3. Application layer

Connection layer

The connection layer manages connections over their entire lifetime. It allows to establish new connections by listing for incoming connection requests and by connecting to remote peers. Connection are uniquely identified by an UUID. After the connection is established messages can be sent and received using the connection. Closed connections are destroyed or reused for future connection depending on their type:

  • WebSockets connections are destroyed when closed

  • DidComm connections are persistant connections and can be reused after closed

Further the connection layer provides the generic serialization and deserialization of the payload represented by JSON objects. So the connection layer provides an abstract interface to establish and close connections as well as send and receive messages. The protocol layer is independent of the different connection types implemented by the connection layer.

Protocol layer

The protocol layer implements two protocols:

  1. Credential Issueing Protocol (Issuer and Holder)

  2. Presentation Exchange Protocol (Holder and Verifier)

Please note that the trustworthiness of the peer should always be verified before disclosing sensitive personal information. The peer verification can be done on different levels (e.g. in person, client/server authentication using TLS, exchanging credentials, …​). The protocol layer only specifies how to use credentials. Even this step is optional, because the verification may be provided somewhere else as explained above.

Credential Issuing Protocol

The holder receives the invitation of the issuer out of band (e.g. qr-code, nfc, BlueTooth, …​). The holder (invitee) accepts the invitation by sending a inivitation accept message back to the issuer (inviter).

Holder
state diagram: credential issueing - holder
state WaitForSubThreadClosed {
    [*] --> SubmitPresentation : receive presentation request
    SubmitPresentation --> PresentationSubmitted : send presentation
    PresentationSubmitted --> [*] : close
}

[*] --> Initialized
Initialized --> WaitForCredentialOffer : send invitation
Initialized --> Closed : close
WaitForCredentialOffer --> SendCredentialRequest : receive offer
WaitForCredentialOffer --> WaitForCredential : send credential request
WaitForCredentialOffer --> Closed : close
SendCredentialRequest --> WaitForCredential : send credential request
SendCredentialRequest --> Closed : close
WaitForCredential --> CredentialReceived : receive credential
WaitForCredential --> WaitForSubThreadClosed : start sub-thread
WaitForSubThreadClosed --> WaitForCredential : sub-thread close
WaitForSubThreadClosed --> Closed : close
WaitForCredential --> Closed : close
CredentialReceived --> Closed : close
Closed --> [*]

@enduml

Please note that the issuer can request additional data from the holder before issuing the credential. This is done in a sub-thread. After the requested data are collected both parties return to the parent thread.

Issuer
state diagram: credential issueing - issuer
@startuml
state WaitForSubThreadClosed {
    [*] --> WaitForPresentation : send presentation request
    WaitForPresentation --> PresentationReceived : receive presentation request
    PresentationReceived --> [*] : close
}

[*] --> Initialized
Initialized --> SendCredentialOffer : receive invitation
Initialized --> Closed : close
SendCredentialOffer --> WaitForCredentialRequest : send offer
SendCredentialOffer --> SubmitCredential : receive request
SendCredentialOffer --> Closed : close
WaitForCredentialRequest --> SubmitCredential : receive request
WaitForCredentialRequest --> Closed : close
SubmitCredential --> CredentialSubmitted : send credential
SubmitCredential --> WaitForSubThreadClosed : start sub-thread
WaitForSubThreadClosed --> SubmitCredential : sub-thread close
WaitForSubThreadClosed --> Closed : close
SubmitCredential --> Closed : close
CredentialSubmitted --> Closed : close
Closed --> [*]

@enduml

Please note that the issuer acts as verifier if he needs additional data from the holder to issue the credential.

Presentation Exchange Protocol

The protocol can either be started by the holder or the verifier by receiving an invitation out of band (e.g. qr-code, nfc, BlueTooth, …​) and sending it back to the invitee.

Holder
state diagram: presentation exchange - holder
state WaitForSubThreadClosed {
    [*] --> WaitForPresentation : send presentation request
    WaitForPresentation --> PresentationReceived : receive presentation request
    PresentationReceived --> [*] : close
}

[*] --> Initialized
Initialized --> SendPresentationOffer : receive or send invitation
Initialized --> Closed : close
SendPresentationOffer --> WaitForPresentationRequest : send presentation offer
SendPresentationOffer --> SubmitPresentation : receive presentation request
SendPresentationOffer --> Closed : close
WaitForPresentationRequest --> SubmitPresentation : receive presentation request
WaitForPresentationRequest --> Closed : close
SubmitPresentation --> PresentationSubmitted : send presentation
SubmitPresentation --> WaitForSubThreadClosed : start sub-thread
WaitForSubThreadClosed --> SubmitPresentation : sub-thread close
WaitForSubThreadClosed --> Closed : close
SubmitPresentation --> Closed : close
PresentationSubmitted --> Closed : close
Closed --> [*]
@enduml

Please note that the holder acts as verifier if he needs to authenticate the verifier before disclosing sensitive personal data (sends presentation). The authentication is handled in a separate sub-thread using the presentation exchange protocol.

Verifier
state diagram: presentation exchange - verifier
@startuml
state WaitForSubThreadClosed {
    [*] --> SubmitPresentation : receive presentation request
    SubmitPresentation --> PresentationSubmitted : send presentation
    PresentationSubmitted --> [*] : close
}

[*] --> Initialized
Initialized --> WaitForPresentationOffer : receive or send invitation
Initialized --> Closed : close
WaitForPresentationOffer --> SendPresentationRequest : receive presentation offer
WaitForPresentationOffer --> WaitForPresentation : send presentation request
WaitForPresentationOffer --> Closed : close
SendPresentationRequest --> WaitForPresentation : send presentation request
SendPresentationRequest --> Closed : close
WaitForPresentation --> PresentationReceived : receive presentation
WaitForPresentation --> WaitForSubThreadClosed : start sub-thread
WaitForSubThreadClosed --> WaitForPresentation : sub-thread close
WaitForSubThreadClosed --> Closed : close
WaitForPresentation --> Closed : close
PresentationReceived --> Closed : close
Closed --> [*]

@enduml

Please note that the verifier acts as holder if he has to authenticate against the holder before receiving the requested presentation.

JSON-LD

Contexts

Credentials

Credential Querying using JSON-LD-Framing

Presentations

Holder Binding

Selective Disclosure

LD-Proof

Authentication Proofs

Assertion Proofs

LD-Signatures

Hardware-backed, biometric protected keys

Key Attestation

Post Quantum Cryptography

References

Prerequisites

This repository depends on a not yet published version 0.3.3 of org.didcommx:didcomm, so get didcomm-jvm build and publish to MavenLocal before.

Contributing

This project is part of a proof of concept which is no longer being maintained.

License

EUROPEAN UNION PUBLIC LICENCE v. 1.2

EUPL © the European Union 2007, 2016

Following terms apply:

  1. Copyright notice: Each published work result is accompanied by an explicit statement of the license conditions for use. These are regularly typical conditions in connection with open source or free software. Programs described/provided/linked here are free software, unless otherwise stated.

  2. Permission notice: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

    1. The copyright notice (Item 1) and the permission notice (Item 2) shall be included in all copies or substantial portions of the Software.

    2. The software is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the warranties of fitness for a particular purpose, merchantability, and/or non-infringement. The authors or copyright holders shall not be liable in any manner whatsoever for any damages or other claims arising from, out of or in connection with the software or the use or other dealings with the software, whether in an action of contract, tort, or otherwise.

    3. The software is the result of research and development activities, therefore not necessarily quality assured and without the character of a liable product. For this reason, gematik does not provide any support or other user assistance (unless otherwise stated in individual cases and without justification of a legal obligation). Furthermore, there is no claim to further development and adaptation of the results to a more current state of the art.

  3. Gematik may remove published results temporarily or permanently from the place of publication at any time without prior notice or justification.

About

credentialExchangeLib

Resources

Readme

License

EUPL-1.2 license

Security policy

Security policy
Activity
Custom properties

Stars

0 stars

Watchers

3 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages