Skip to content
Snippets Groups Projects
Verified Commit a090ac78 authored by Konstantin Tsabolov's avatar Konstantin Tsabolov
Browse files

chore(docs): add flows examples

parent 551078ba
No related branches found
No related tags found
No related merge requests found
Pipeline #41157 failed
Stage: build
    Hide whitespace changes
    Inline Side-by-side
    README.md
    + 47
    − 41
    View file @ a090ac78
    # Organizational Credential Manager (v2) # Organization Credential Manager (OCM)
    ## Overview ## Introduction
    OCM (Organizational Credential Manager) is a Node.js-based microservice system designed to manage organizational credentials. Organization Credential Manager (OCM) is a comprehensive suite of microservices designed to facilitate the management of digital credentials within an organizational context. Utilizing the principles of Self-Sovereign Identity (SSI), OCM leverages a series of components to enable secure, efficient handling of credentials, keys, and connections between entities.
    ## Prerequisites ## Components
    * Node.js (version 20 or later) OCM is comprised of several key microservices, each serving a specific role within the credential management ecosystem:
    * pnpm
    * Docker and Docker Compose for local development
    ## Installation ### [SSI Abstraction](apps/ssi-abstraction/README.md)
    A wrapper around the Credo library ([Credo](https://credo.js.org)), formerly known as Aries Framework Javascript, an implementation of a Hyperledger Indy Agent in TypeScript. This service abstracts the complexities of SSI operations for other components.
    1. Clone the repository: ### [Tenant Manager](apps/tenant-manager/README.md)
    Manages the creation and listing of OCM tenants, with each tenant maintaining their collections of credentials, keys, etc. This service acts as a critical interface to the SSI Abstraction functionality and is intended for administrative use only.
    ```bash ### [DID Manager](apps/did-manager/README.md)
    git clone https://gitlab.eclipse.org/eclipse/xfsc/ocm/ocm-engine.git Provides API functions for registering Decentralized Identifiers (DIDs) on the Indy Ledger and resolving existing DID Documents, facilitating secure identity verification and management.
    ```
    2. Navigate to the repository directory: ### [Connection Manager](apps/connection-manager/README.md)
    Facilitates the establishment of connections between OCM tenants using Aries protocols, enabling secure, verified interactions.
    ```bash ### [Schema Manager](apps/schema-manager/README.md)
    cd ocm-engine Allows tenants to manage Indy Schemas and Credential Definitions, laying the groundwork for the creation and recognition of standardized credential formats.
    ```
    3. Start the whole stack in Docker Compose: ### [Credential Manager](apps/credential-manager/README.md)
    Offers an API for the detailed management of tenant credentials, streamlining the process of issuing, holding, and verifying digital credentials.
    ```bash ### [Proof Manager](apps/proof-manager/README.md)
    docker compose up -d Enables tenants to create proof requests, an essential feature for the verification of credential authenticity and integrity.
    ```
    OR ## Deployment
    3. Install dependencies: ### Kubernetes
    ```bash OCM can be deployed within a Kubernetes cluster to leverage the benefits of container orchestration for managing and scaling the microservices efficiently. The deployment process is streamlined through the use of Helm, a package manager for Kubernetes that facilitates the installation, upgrade, and management of Kubernetes applications.
    pnpm i
    ```
    4. Create `.env` files for services: Each microservice within OCM is equipped with its own Helm chart located in the service's folder. These Helm charts define the Kubernetes resources required for deploying and running the service, including Deployments, Services, and any necessary ConfigMaps or Secrets.
    ```bash ### Docker Compose (Local)
    cp apps/ssi-abstraction/.env.example apps/ssi-abstraction/.env
    cp apps/connection-manager/.env.example apps/connection-manager/.env
    cp apps/credential-manager/.env.example apps/credential-manager/.env
    cp apps/did-manager/.env.example apps/did-manager/.env
    cp apps/proof-manager/.env.example apps/proof-manager/.env
    cp apps/schema-manager/.env.example apps/schema-manager/.env
    ```
    4. Start the services locally: For local development and testing purposes, the OCM stack can also be run using Docker Compose with the following command:
    ```bash ```bash
    pnpm start docker compose up -d
    ``` ```
    ## Example Flows (OCM Usage) This command builds the service container images and starts the stack. It's a convenient way to quickly bring up the OCM environment on a local machine for development, testing, or demonstration purposes.
    Please refer to [OCM-flow-overview](documentation/ocm-flow-overview.md) ## Local Development
    To run each service locally, the following prerequisites are needed:
    - Node.js (installed on the local machine)
    - pnpm (package manager)
    - Docker Compose (for running NATS server and S3 storage)
    Before starting a service, create a `.env` file in the service's directory based on the `.env.example` provided, renaming it to `.env`.
    ## Documentation and Example Flows
    For detailed usage and example flows, please refer to the [Postman Collection](documentation/Gaia-X_Organization_Credential_Manager.postman_collection.json) and the [OCM Example Flows](documentation/ocm-example-flows.md).
    ## Security
    Note: Authentication and Authorization mechanisms are considered outside the scope of this project and should be addressed at the infrastructure level or through other means.
    ## License ## License
    This project is licensed under the [Apache 2.0 License](LICENSE) Licensed under the Apache 2.0 License ([LICENSE](LICENSE)).
    documentation/ocm-example-flows.md 0 → 100644
    + 263
    − 0
    View file @ a090ac78
    # OCM Example Flows
    ## Prerequisites
    Before diving into the example flows of using Organization Credential Manager (OCM), it's essential to set up the environment and create the foundational elements required for managing digital credentials. Follow these steps to get started:
    ### Step 1: Create a Tenant
    The first step involves creating a tenant within OCM. A tenant represents an organizational entity within OCM, encapsulating its own collection of credentials, keys, and configurations. This step is crucial as it establishes the context within which all subsequent operations will be performed.
    To create a tenant, you will need to interact with the [**Tenant Manager**](../apps/tenant-manager/README.md). This can be done through a command-line interface, script, or potentially a user interface developed for administrative purposes. Here's an example command (note: replace `tenant_name` with your desired tenant name):
    ```bash
    # Example command to create a tenant
    curl -X POST http://ocm-indy.xfsc.dev/v1/tenants -d '{"label": "tenant_name"}'
    ```
    > **Important:** The Tenant Manager is a critical component that should be secured appropriately. Implementing authentication and authorization mechanisms is out of the scope of this project. It is the responsibility of the OCM Administrator to secure access to the Tenant Manager, potentially by developing a custom user interface and access control system.
    ### Step 2: Create a DID for the Tenant
    After creating a tenant, the next step is to create a Decentralized Identifier (DID) for it. A DID uniquely identifies the tenant and facilitates secure, verifiable interactions within the OCM ecosystem and beyond.
    This step is performed using the [**DID Manager**](../apps/did-manager/README.md), which interfaces with the Indy Ledger to register the DID and manage its associated DID Document.
    Here's how you can create a DID for your newly created tenant:
    ```bash
    # Example command to create a DID for the tenant
    curl -X POST "http://ocm-indy.xfsc.dev/v1/dids?tenantId=<tenantId>" -d '{"seed": "<seed>"}'
    ```
    In this command, replace `<tenantId>` with your tenant's unique identifier and `<seed>` with a randomly generated string of 32 characters. This seed is crucial for the creation of a secure and unique DID. For a detailed example and additional parameters that can be included in the DID creation request, please refer to the [DID Manager's documentation](../apps/did-manager/README.md).
    This will register a new DID on the ledger and associate it with your tenant, enabling the tenant to participate in secure digital interactions.
    ## Connections
    ### Creating an Invitation
    To initiate a secure connection between tenants in the OCM ecosystem, the first step is to create an invitation. This invitation follows the Aries protocol, serving as a standardized way to establish peer-to-peer connections.
    To create an invitation, use the Connection Manager service. Here's an example command to generate an invitation:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/invitations?tenantId=<tenantId>"
    ```
    In this command, replace `<tenantId>` with the identifier of the tenant creating the invitation. The response from this command will include an invitation object, which contains the information needed by another tenant to connect.
    The response from this command will include an invitationUrl. This URL encapsulates the invitation object, which contains the information needed by another tenant to connect.
    ### Accepting an Invitation
    After an invitation has been created and the `invitationUrl` delivered to the intended recipient, the next step for the recipient is to accept the invitation to initiate the connection process. The delivery of the `invitationUrl` can be achieved through various methods, such as email, sharing a QR code, or any other secure means of communication preferred by the parties involved.
    Once the recipient has the `invitationUrl`, they can proceed to accept the invitation using the Connection Manager service. Accepting an invitation establishes a secure, peer-to-peer connection between the two tenants, based on the Aries protocols. Here is an example command for accepting an invitation:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/connection-manager/accept-invitation?tenantId=<recipientTenantId>" -d '{"invitationUrl": "<invitationUrl>"}'
    ```
    In this command, replace `<recipientTenantId>` with the identifier of the tenant accepting the invitation, and `<invitationUrl>` with the URL received. This action completes the connection setup, enabling secure communication and transactions between the two tenants.
    ### Establishing a Connection to Self
    For scenarios where a tenant needs to establish a connection within their own organizational boundaries—essentially connecting to themselves—OCM provides a streamlined process that bypasses the traditional invitation and acceptance steps. This self-connection is particularly useful for internal testing, development, or scenarios where segregated parts of an organization need to interact securely without the need for external verification.
    To establish a connection to self, a single request is made, simplifying the connection setup process. Here's how to initiate a self-connection:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/connections?tenantId=<tenantId>"
    ```
    Replace `<tenantId>` with the identifier of the tenant initiating the self-connection. This request does not require a payload, as the necessary information is derived from the tenant ID provided in the request.
    This command instructs the Connection Manager to create a new connection record that is automatically marked as active and trusted, without the need for the traditional invitation exchange process. The resulting connection can then be used for internal transactions, credential issuance, and verifications, just like any other connection established through invitation and acceptance.
    ## Schemas and Credential Definitions
    Within the framework of Aries and Hyperledger Indy, the concepts of schemas and credential definitions play crucial roles in the management and issuance of verifiable credentials. Schemas provide a structured template that defines the attributes and format of the credentials, essentially outlining what information a credential will contain. Credential definitions, on the other hand, tie these schemas to specific issuers, enabling them to issue verifiable credentials based on the predefined schema. Together, these components ensure that credentials are issued in a standardized and interoperable manner, facilitating their verification across different systems and platforms.
    ### Creating a Schema
    To create a schema within the OCM ecosystem, utilize the Schema Manager service. Here's how you can initiate the process:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/schemas?tenantId=<tenantId>" -d 'payload'
    ```
    In the command above, replace `<tenantId>` with the identifier of the tenant creating the schema, and replace `'payload'` with the actual payload. The payload should look like this:
    ```json
    {
    "name": "ExampleSchema",
    "version": "1.0",
    "attributeNames": ["firstName", "lastName", "email"],
    "issuerDid": "issuerDidValue"
    }
    ```
    This payload includes the schema's name, version, the attribute names it will include, and the `issuerDid`. Ensure to replace `"issuerDidValue"` with the actual DID of the issuer.
    ### Creating a Credential Definition
    After a schema has been established, the subsequent step involves creating a credential definition. This step associates the schema with an issuer, thereby permitting the issuance of verifiable credentials based on that schema. Credential definitions can also specify revocation support, which adds an additional layer of security and control for credential issuers. Here’s how to create a credential definition with revocation support:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/schema-manager/create-credential-definition?tenantId=<tenantId>" -d 'payload'
    ```
    In the above command, replace `<tenantId>` with the identifier of the tenant creating the credential definition, and substitute `'payload'` with the actual payload. The payload should be structured as follows:
    ```json
    {
    "issuerDid": "issuerDidValue",
    "schemaId": "schemaId",
    "tag": "tagValue",
    "supportsRevocation": true
    }
    ```
    This detailed payload specifies the `issuerDid`, identifying the issuer, and `schemaId`, linking to the specific schema. The `tag` field, which can be a random semantic version string, helps in distinguishing between different credential definitions created by the same issuer for the same schema. Setting `supportsRevocation` to true enables the issued credentials to be revocable.
    ## Issuing a Credential
    Issuing a credential within the OCM framework involves a two-step process: making an offer for a credential and then accepting this offer. This process aligns with the Aries protocol for credential exchange, ensuring a standardized approach to issuing verifiable credentials.
    ### Making a Credential Offer
    The first step in issuing a credential is to make an offer. This offer is sent from the issuer to the prospective credential holder and includes details about the credential being offered, such as the credential definition ID and the attributes it will contain.
    To make a credential offer, the Credential Manager service is used. Here’s how you can initiate a credential offer:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/credential-offers?tenantId=<issuerTenantId>" -d 'payload'
    ```
    Replace `<issuerTenantId>` with the identifier of the tenant (issuer) making the offer. The payload should be structured as follows and replace `'payload'` with it:
    ```json
    {
    "connectionId": "{{connection_id}}",
    "credentialDefinitionId": "{{credential_definition_id}}",
    "attributes": [
    {
    "name": "firstName",
    "value": "John"
    },
    {
    "name": "lastName",
    "value": "Doe"
    }
    // Add other attributes as needed
    ]
    }
    ```
    This payload specifies the connection over which the offer is made (`connectionId`), the credential definition ID (`credentialDefinitionId`), and the attributes of the credential being offered.
    ### Accepting a Credential Offer
    Upon receiving a credential offer, the prospective holder can accept the offer to initiate the credential issuance process. Accepting the offer involves sending a response back to the issuer, indicating the recipient's willingness to receive the credential as per the offer's terms.
    To accept a credential offer, the Credential Manager service is again utilized. Here's an example command to accept an offer:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/credential-offers/<offer_id>/accept?tenantId=<holderTenantId>"
    ```
    Replace `<holderTenantId>` with the identifier of the tenant (holder) accepting the offer. Replace `"{{offer_id}}"` with the actual ID of the credential offer received. This completes the credential issuance process, successfully issuing the credential from the issuer to the holder.
    ### Self-Issuance of Credentials
    In certain scenarios, a tenant might opt for self-issuance of credentials, where the issuer and the credential holder are the same entity. This process simplifies the credential issuance flow by automatically accepting the credential offer, effectively skipping the manual step of accepting the offer.
    Self-issuance is particularly useful for credentials that don't require external verification or approval, allowing for a streamlined, efficient process. To initiate self-issuance, the same Credential Manager service is used, but the process combines making an offer and automatically accepting it in a single step.
    Here’s an example of how to initiate a self-issued credential:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/credential-offers/self?tenantId=<tenantId>" -d 'payload'
    ```
    Replace `<tenantId>` with the identifier of the tenant issuing the credential to themselves. The payload should be structured similarly to making an offer but is tailored for self-issuance:
    ```json
    {
    "connectionId": "{{self_connection_id}}",
    "credentialDefinitionId": "{{credential_definition_id}}",
    "attributes": [
    {
    "name": "firstName",
    "value": "John"
    },
    {
    "name": "lastName",
    "value": "Doe"
    }
    // Add other attributes as needed
    ]
    }
    ```
    This payload includes the credential definition ID (`credentialDefinitionId`) and the attributes of the credential being issued. Upon submission, the offer is automatically accepted, and the credential is issued directly to the self-issuing tenant, bypassing the need for an explicit acceptance step.
    ## Proof Requests
    The process of requesting and providing proofs is fundamental in the verification of credentials within the OCM framework. This involves two main steps: making a proof request by the verifier and accepting this request by the holder, leading to the sharing of a verifiable proof.
    ### Making a Proof Request
    A proof request is initiated by a verifier who needs to verify certain attributes or credentials held by another party. This request specifies what information is needed and may include specific attributes, credential types, or conditions that the proof must satisfy.
    To make a proof request, use the Proof Manager service. Here's how to initiate a proof request:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/proofs?tenantId=<verifierTenantId>" -d 'payload'
    ```
    Replace `<verifierTenantId>` with the identifier of the tenant (verifier) making the proof request. The payload detailing the specifics of the proof request should look like this, and replace `'payload'` with:
    ```json
    {
    "name": "dynamic_chameleon",
    "connectionId": "connectionId",
    "requestedAttributes": {
    "person_names": {
    "names": ["firstName", "lastName"],
    "restrictions": [{}]
    }
    },
    "requestedPredicates": {}
    }
    ```
    This payload includes a `name` for the proof request, which is dynamically generated to ensure uniqueness, the `connectionId` over which the request is made, and a `requestedAttributes` object detailing the requirements of the proof, such as the attributes' names and any restrictions related to the credentials being verified. The `requestedPredicates` section can be used to specify additional constraints but is empty in this example.
    ### Accepting a Proof Request
    Upon receiving a proof request, the credential holder can respond by providing the requested proof, assuming they possess the credentials that satisfy the request's criteria. Accepting a proof request involves preparing and sending a proof that meets the verifier's specifications.
    To accept a proof request and provide the necessary proof, the Proof Manager service is again utilized. Here's an example command to accept a proof request and send the proof:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/proofs/<proofId>/accept?tenantId=<holderTenantId>" -d 'payload'
    ```
    Replace `<holderTenantId>` with the identifier of the tenant (holder) responding to the proof request.
    This action completes the proof exchange, allowing the verifier to receive and verify the proof.
    ## Revoking Credentials
    In certain situations, it may become necessary to revoke a credential that has been issued, for example, if the information is no longer valid or if the credential was issued in error. OCM supports the revocation of credentials, allowing issuers to invalidate a previously issued credential. This process ensures that the credential can no longer be used for verification purposes.
    To revoke a credential, a single request is made to the Credential Manager service. This request specifies the `credentialId` of the credential to be revoked. Here's how to initiate a credential revocation:
    ```bash
    curl -X POST "http://ocm-indy.xfsc.dev/v1/credentials/<credentialId>?tenantId=<issuerTenantId>"
    ```
    Replace `<issuerTenantId>` with the identifier of the tenant (issuer) initiating the revocation. Replace `"credentialId"` with the actual ID of the credential you wish to revoke. This action invalidates the credential, ensuring it cannot be presented or verified in future transactions. It's important to note that the revocation process is irreversible, and once a credential is revoked, it cannot be reinstated.
    documentation/ocm-flow-overview.md deleted 100644 → 0
    + 0
    − 347
    View file @ 551078ba
    # OCM API flows
    ## Create a connection with a PCM
    -> under connection-manager
    1. Create an invitation url
    POST
    {{baseUrl}}/v1/invitation-url?alias=trust
    - in the response copy
    e.g. -> "invitationUrl": "https://example.com:443/ocm/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiI0ZDA2N2FlMi1kNTQ5LTRlYzQtYmU2OC00MzFmMzdkMjJlODUiLCJsYWJlbCI6InNzaS1hYnN0cmFjdGlvbi1hZ2VudCIsInJlY2lwaWVudEtleXMiOlsiNVl6U21xcjY5d0RFSzVvQWpzZFQ3UktjazJuaHdmS0phVVVneUVESEFuNWQiXSwic2VydmljZUVuZHBvaW50IjoiaHR0cHM6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119",
    or "invitationUrlShort"
    2. Convert the invitation URL to a QR code and scan with the PCM
    ## Create a connection with another OCM
    -> under connection-manager
    1. Create an invitation url
    POST
    {{baseUrl}}/v1/invitation-url?alias=trust
    - in the response copy
    e.g. -> "invitationUrl": "https://example.com:443/ocm/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiI0ZDA2N2FlMi1kNTQ5LTRlYzQtYmU2OC00MzFmMzdkMjJlODUiLCJsYWJlbCI6InNzaS1hYnN0cmFjdGlvbi1hZ2VudCIsInJlY2lwaWVudEtleXMiOlsiNVl6U21xcjY5d0RFSzVvQWpzZFQ3UktjazJuaHdmS0phVVVneUVESEFuNWQiXSwic2VydmljZUVuZHBvaW50IjoiaHR0cHM6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119",
    2. Accept connection on the other OCM
    POST
    {{baseUrl}}/v1/accept-connection-invitation
    body:
    {
    "invitationUrl": "https://example.com:443/ocm-provider/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiJhNzE1OGFkZS1iMjBkLTQwYmQtODliNy1jM2RhMjg1NWU0ZDAiLCJsYWJlbCI6IkdYRlMtSW50ZWdyYXRpb24iLCJyZWNpcGllbnRLZXlzIjpbIkNYYlViTTNEeEJ3SzNWTFptaXBWOEtDYmQyVmVXM1NDa3BOb01qblRSb1JiIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHBzOi8vaW50ZWdyYXRpb24uZ3hmcy5kZXY6NDQzL29jbS1wcm92aWRlci9kaWRjb21tIiwicm91dGluZ0tleXMiOltdfQ",
    "autoAcceptConnection": true
    }
    ## Issue a credential to an already established connection
    -> under attestation-manager
    1. create a schema (optional in case the desired schema already exists on the ledger)
    POST
    {{baseUrl}}/v1/schemas
    body:
    **make sure to create a unique name for it and choose whatever, however many attributes you want**
    ```
    {
    "name": "BasicCredential-oct-3-2022",
    "createdBy": "asdasdasd",
    "version": "1.0.0",
    "attributes": [
    "firstName",
    "lastName"
    ]
    }
    ```
    2. Create credential definition
    POST
    {{baseUrl}}/v1/credentialDef
    body:
    **make sure to use the schemaID from the previous response and create a unique name here as well**
    ```
    {
    "schemaID": "the schema id from the response of 1.",
    "name": "BasicCredential-oct-3-2022-credDef.1.0.2",
    "isRevokable": false,
    "isAutoIssue": false,
    "expiryHours": "23",
    "createdBy": "asdasdasfas"
    }
    ```
    3. Offer a credential
    POST
    {{baseUrl}}/v1/create-offer-credential
    body:
    **make sure to use here the connection id from ## Create a connection 2. response and the credential definition id from the previous response**
    **make sure the names of the attributes here match the names of the attributes in the schema**
    ```
    {
    "connectionId": "12926da1-916f-46d3-8f44-56df4d79c2c3",
    "credentialDefinitionId": "7KuDTpQh3GJ7Gp6kErpWvM:3:CL:520446:BasicCredential-oct-3-2022-credDef.1.0.2",
    "comment": "Issueacredential.1.0",
    "attributes": [
    {
    "name": "firstName",
    "value": "Jon"
    },
    {
    "name": "lastName",
    "value": "Doe"
    }
    ],
    "autoAcceptCredential": "always"
    }
    ```
    ## Accept a credential (OCM - OCM)
    **on the PCM, it is part of the GUI**
    **on the OCM, the procedure is the following:**
    -> under attestation-manager
    1. Get all credentials and find the one of interest (unaccepted credential will be in **state: offer-received**)
    POST
    {{baseUrl}}/v1/credential
    response example:
    ```
    {
    "statusCode": 200,
    "message": "Credential fetch successfully",
    "data": {
    "count": 2,
    "records": [
    {
    "id": "6a6ee15d-a68b-46af-ac9b-e07bc544dc3b",
    "credentialId": "624a76fd-f8f7-4f92-b4f8-d7497ce70a04",
    "credDefId": "8y8oycXjnQCRT2t3mRuzbP:3:CL:37720:LegalInformation-1.0.2",
    "threadId": "9f95a52a-1387-40c7-a4b0-96d9d8d0b63b",
    "state": "done",
    "principalDid": "KGaeQVaF3FzjWTU6bJJ21Y",
    "connectionId": "12cd39de-d792-410a-8db2-39140cfc3579",
    "createdDate": "2023-02-22T13:28:58.149Z",
    "updatedDate": "2023-02-22T13:34:48.467Z",
    "expirationDate": null
    },
    {
    "id": "de74fafe-7a35-45c2-b872-2ea07ae0d952",
    "credentialId": "5623fceb-3d40-4d99-a230-c142c646d5fe",
    "credDefId": "8y8oycXjnQCRT2t3mRuzbP:3:CL:37720:LegalInformation-1.0.2",
    "threadId": "fa5aab2c-4ecb-4b69-bc00-8b83de3444a1",
    "state": "offer-received",
    "principalDid": "KGaeQVaF3FzjWTU6bJJ21Y",
    "connectionId": "12cd39de-d792-410a-8db2-39140cfc3579",
    "createdDate": "2023-02-23T07:09:34.143Z",
    "updatedDate": "2023-02-23T07:09:34.143Z",
    "expirationDate": null
    }
    ]
    }
    }
    ```
    2. accept credential offer
    POST
    {{baseUrl}}/v1/accept-offer?credentialID={{copy-the-credentialId-from-the-previous-response}}
    ## To send a proof request to someone in order to present claims for a custom issued credential
    -> under proof manager
    POST
    /v1/send-presentation-request
    **the connection id can be found in a connection record**
    **the credential definition id can be found on attestation-manager -> GET {{baseUrl}}/v1/credentialDef**
    body:
    ```
    {
    "comment": "Proof Presenation",
    "attributes": [
    {
    "schemaId": "",
    "credentialDefId": "7KuDTpQh3GJ7Gp6kErpWvM:3:CL:520446:BasicCredential-oct-3-2022-credDef.1.0.2",
    "attributeName": "lastName",
    "value": "",
    "condition": ""
    }
    ],
    "connectionId": "a4c01f34-c292-4e8a-b59a-2036d31e4988"
    }
    ```
    ## Accept a proof request
    **on the PCM it is done through the GUI**
    **on the OCM follow this procedure:**
    1. Find the desired proof request id
    GET
    {{baseUrl}}/v1/agent-proofs
    The proof request will be in **state: request-received**
    2. Accept the proof request
    POST
    {{baseUrl}}/v1/accept-proof-request?proofRecordId={{proofId}}
    Response example:
    ```
    {
    "statusCode": 200,
    "message": "Request accepted successfully",
    "data": {
    "_tags": {
    "threadId": "6b5c57b3-137f-4f52-87f5-bd086596503c",
    "state": "request-received",
    "connectionId": "653b8cdc-d919-4b65-b399-7bf17ce36ffc"
    },
    "metadata": {},
    "id": "19c5269f-c3e5-4369-b8d0-87fe22accc9a",
    "createdAt": "2023-03-10T10:56:07.498Z",
    "requestMessage": {
    "@type": "https://didcomm.org/present-proof/1.0/request-presentation",
    "@id": "6b5c57b3-137f-4f52-87f5-bd086596503c",
    "comment": "Proof Presenation",
    "request_presentations~attach": [
    {
    "@id": "libindy-request-presentation-0",
    "mime-type": "application/json",
    "data": {
    "base64": "eyJuYW1lIjoiUHJvb2YgUmVxdWVzdCIsInZlcnNpb24iOiJQcm9vZiBSZXF1ZXN0Iiwibm9uY2UiOiI5MTAwMDg3="
    }
    }
    ]
    },
    "state": "presentation-sent",
    "connectionId": "653b8cdc-d919-4b65-b399-7bf17ce36ffc",
    "threadId": "6b5c57b3-137f-4f52-87f5-bd086596503c",
    "presentationMessage": {
    "@type": "https://didcomm.org/present-proof/1.0/presentation",
    "@id": "c1089096-b834-4fe8-a51d-f3472b1b1dcd",
    "presentations~attach": [
    {
    "@id": "libindy-presentation-0",
    "mime-type": "application/json",
    "data": {
    "base64": "eyJwcm9vZiI6eyJwcm9vZnMiOlt7InByaW1hcnlfcHJvb2YiOnsiZXFfcHJvb2YiOnsicmV2ZWFsZWRfYXR0cnMiOnsicHJjZmlyc3RuYW1lIjoiNjgyMTE2NTZCI6bnVsbCwidGltZXN0YW1wIjpudWxsfV19"
    }
    }
    ],
    "~thread": {
    "thid": "6b5c57b3-137f-4f52-87f5-bd086596503c"
    }
    }
    }
    }
    ```
    ## Credential types can be used for automatically requesting proof on a specific credential during login when OCM and TSA are integrated with AA Services
    **with the following type: principalMemberCredential**
    By default, there will be no credential type on the OCM. An existing schema on the chosen ledger can be linked, or a new schema can be created and linked to this credential type.
    ## In order to create a credential type:
    -> under attestation manager
    POST
    {{baseUrl}}/v1/credentialType
    body:
    ```
    {
    "type": "principalMemberCredential",
    "schemaId": "7KuDTpQh3GJ7Gp6kErpWvM:2:test_profileCredential-220722:1.0"
    }
    ```
    ## In order to update schema type for credential type:
    -> under attestation manager
    PATCH
    /v1/updateSchemaIdByType?type={credentialType}
    Example: /v1/updateSchemaIdByType?type=principalMemberCredential
    body:
    ```
    {
    "schemaId": "7KuDTpQh3GJ7Gp6kErpWvM:2:test_principalMemberCredential-060722:1.0"
    }
    ```
    ## To check interactions with an existing connection
    GET
    {{baseUrl}}/v1/connection-information?connectionId={{the-connectionId-you-are-looking-for}}
    example response:
    ```
    {
    "statusCode": 200,
    "message": "Connection information fetch successfully",
    "data": {
    "records": {
    "issueCredentials": [
    {
    "id": "6a6ee15d-a68b-46af-ac9b-e07bc544dc3b",
    "credentialId": "624a76fd-f8f7-4f92-b4f8-d7497ce70a04",
    "credDefId": "8y8oycXjnQCRT2t3mRuzbP:3:CL:37720:LegalInformation-1.0.2",
    "threadId": "9f95a52a-1387-40c7-a4b0-96d9d8d0b63b",
    "state": "done",
    "principalDid": "KGaeQVaF3FzjWTU6bJJ21Y",
    "connectionId": "12cd39de-d792-410a-8db2-39140cfc3579",
    "createdDate": "2023-02-22T13:28:58.149Z",
    "updatedDate": "2023-02-22T13:34:48.467Z",
    "expirationDate": null
    },
    {
    "id": "de74fafe-7a35-45c2-b872-2ea07ae0d952",
    "credentialId": "5623fceb-3d40-4d99-a230-c142c646d5fe",
    "credDefId": "8y8oycXjnQCRT2t3mRuzbP:3:CL:37720:LegalInformation-1.0.2",
    "threadId": "fa5aab2c-4ecb-4b69-bc00-8b83de3444a1",
    "state": "offer-received",
    "principalDid": "KGaeQVaF3FzjWTU6bJJ21Y",
    "connectionId": "12cd39de-d792-410a-8db2-39140cfc3579",
    "createdDate": "2023-02-23T07:09:34.143Z",
    "updatedDate": "2023-02-23T07:09:34.143Z",
    "expirationDate": null
    }
    ],
    "presentProofs": []
    }
    }
    }
    ```
    0% or .
    You are about to add 0 people to the discussion. Proceed with caution.
    Finish editing this message first!
    Please register or to comment

    Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent