> For the complete documentation index, see [llms.txt](https://guide.transmute.industries/verifiable-data-platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.transmute.industries/verifiable-data-platform/technical-documentation/didauth-presentations.md). # DIDAuth Presentations Verifiable presentations are directional interactions between two specific parties. ### Overview These interactions involve the following steps:

DID-Auth Verifiable Presentation Flow

The presenter indicates an intention to make a presentation, invoking the receivers endpoint (1). The presentation receiver replies with a “challenge” which will be cryptographically included in the presentation, and optionally directions on which verifiable credentials are required (2). The presenter bundles the necessary (parts of) the Verifiable Credentials to be presented, creates a signed verifiable presentation (3), and submits the verifiable presentation to the presentation receiver (4). The presentation receiver accepts (or rejects) the inbound presentation (5), will typically want to verify its content (6), Both presenter and presentation receiver will also typically store the verifiable presentation (7) and (8) for future records. > **Note!** > > The interacting parts of this flow marked in dotted red implements the Traceability Interoperability standard #### Directional Interactions The following sections describes these steps in deeper technical details. The headline numbering refers to the above diagram. Being directional, there is an important difference here between being the *presenter* and being the *presentation receiver*; these roles are clearly marked at each section. ### 1. Indicating Presentation Intent The *presenter* initiates the presentation procedure by indicating to the *presentation receiver* that she intents to make a presentation. This is done using the “/available” endpoint: `POST /api/organizations/{organizationId}/presentations/available` > **Note!** > > It is important to note here that the call is made by the *presenter*, but “pointing at” the `organizationId` of the *presentation receiver*. Below is an example to illustrate usage of this endpoint: 
curl 'https://platform.transmute.industries/api/organizations/org_ABC/presentations/available' \
  -H 'accept: application/json' \
  -H 'authorization: Bearer YOUR_ACCESS_TOKEN'
### 2. Responding to Presentation Intent The above call will return a response from the *presentation receiver* similar to this: ```json { "audience": "https://platform.transmute.industries", "nonce": "ey..." } ``` The `nonce` will be used shortly in producing the verifiable presentation. The *presenter* must also take note of the types of verifiable credentials, which the *presentation receiver* requires for a given type of presentation. In the above example the empty array indicates that there are no such requirements, so in this case it is up to the *presenter* to decide on the relevant credentials to present. > **Note!**\ > Platform features will be added, allowing the presentationReceiver rich control over presenter and credentials requirements. > **Note!**\ > The nomenclature of these requests and response objects implements the Verifiable Presentation Request Specification standard (). ### 3. Generating a Signed Verifiable Presentation Upon receiving the above intention to present response, the *presenter* can go ahead and prepare the verifiable presentation. This is done with the “/prove” endpoint: `POST /presentations/prove` An example of is provided below: ```bash curl --location 'http://localhost:3000/api/presentations/prove' \ --header 'Accept: application/json' \ --header 'Authorization: Bearer **Your token here**' \ --header 'Content-Type: application/json' \ --data-raw '{ "presentation": { "@context": [ "https://www.w3.org/2018/credentials/v1" ], "type": [ "VerifiablePresentation" ], "id": "urn:uuid:81ef445d-59d5-4162-8487-cce4507645df", "holder": "did:web:example.com", "verifiableCredential": [ { "@context": [ "https://www.w3.org/ns/credentials/v2" ], "id": "data:application/vc+ld+json+sd-jwt;eyJraWQiOiJkaWQ6d2ViOmxvY2FsaG9zdCUzQTgwODA6b3JnYW5pemF0aW9uczpvcmdfV0dtQjJmYTFJSWlZVGFBWSN6Nk1rcUVlTkZmb2Z4TmpOTVZranY0WDFUcVgyYzJzTjRCQURkbUdvNm5lY1ZkNDciLCJhbGciOiJFZERTQSJ9.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIiwiaHR0cHM6Ly93M2lkLm9yZy90cmFjZWFiaWxpdHkvdjEiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIkVudHJ5TnVtYmVyQ3JlZGVudGlhbCJdLCJpZCI6InVybjp0cmFuc211dGU6Y3JlZGVudGlhbDhkNTc5NDg4LWQxMGMtNDlkMS05ZTE4LTI0NzZmY2RkNmU4YyIsImlzc3VlciI6eyJ0eXBlIjpbIk9yZ2FuaXphdGlvbiJdLCJsb2NhdGlvbiI6eyJ0eXBlIjpbIlBsYWNlIl0sImFkZHJlc3MiOnsidHlwZSI6WyJQb3N0YWxBZGRyZXNzIl0sInN0cmVldEFkZHJlc3MiOiIxOSBLbm94IFN0IiwiYWRkcmVzc0xvY2FsaXR5IjoiVG9yb250byIsImFkZHJlc3NSZWdpb24iOiJPTiIsImFkZHJlc3NDb3VudHJ5IjoiQ0EiLCJwb3N0YWxDb2RlIjoiTTNCIDFBMiJ9fSwiaWQiOiJkaWQ6d2ViOmxvY2FsaG9zdCUzQTgwODA6b3JnYW5pemF0aW9uczpvcmdfV0dtQjJmYTFJSWlZVGFBWSIsIm5hbWUiOiJPbndhcmRzIEEvUyJ9LCJjcmVkZW50aWFsU2NoZW1hIjp7ImlkIjoiaHR0cHM6Ly90cmFuc211dGUuaWQvdXJuOnRyYW5zbXV0ZTp0ZW1wbGF0ZTplbnRyeS1udW1iZXItY3JlZGVudGlhbCIsInR5cGUiOiJPcGVuQXBpU3BlY2lmaWNhdGlvblZhbGlkYXRvcjIwMjIifSwiY3JlZGVudGlhbFN1YmplY3QiOnsidHlwZSI6WyJFbnRyeU51bWJlciJdLCJlbnRyeU51bWJlciI6IjEyMzQ1MTIzNDU2In0sImlzc3VhbmNlRGF0ZSI6IjIwMjQtMDItMTJUMTQ6MTA6MjMuNjgyWiJ9.DbrTqAmvLQiMZ9SBqDZ1bgnyTG1iKbgjQ-QHjsilmZO-gOw8V27KxVoUD40wqxpzmffWhVl9yfzcbGCmuRezBg~", "type": "EnvelopedVerifiableCredential" } ] }, "options": { "audience": "example.com", "nonce": "d436f0c8-fbd9-4e48-bbb2-55fc5d0920a8" } }' ``` The presentation request includes a number of elements which the verifiable presentation will be based on. It also includes an “options” object, which the platform uses for the generating the verifiable presentation proof, including the `nonce` which was provided by the *presentationReceiver*. The “/prove” call returns the verifiable presentation, which includes a proof element: ```json { "verifiablePresentation": "ey..." } ``` ### 4. Submitting the Verifiable Presentation The presentation submission is completed by passing the above signed verifiable presentation directly to the “/submissions” endpoint: `POST /api/organizations/{receiverId}/presentations/submissions` ```bash curl --location --request POST 'https://platform.transmute.industries/api/organizations/org_ABC/presentations/submissions' \ --header 'Content-Type: application/json' \ --data-raw ' **Verifiable presentation here, as shown above** ' ``` #### Storing Own Submmitted Presentations Verifiable presentations are one-off interactions between the two interacting parties; the *presenter’s* verifiable presentation is tied to the specific session with the *presentation receiver*. It can be queried by calling the “/sent” endpoint: `GET /api/presentations/sent` ### 5. Receiving a Verifiable Presentation The following describes necessary steps for the *presentation receiver* receive an inbound verifiable presentation. It also describes optional configuration which the *presentation receiver* can make to control access and content of presentations. #### Listing Inbound Presentations The presentation receiver can see inbound verifiable presentations by calling the “/shared-with-me” endpoint: ```bash curl --location --request GET 'https://platform.transmute.industries/api/presentations/received' \ --header 'Authorization: Bearer **Your token here**' ``` This returns an array of all past presentations, each wrapped with metadata about the `sender`, its `id` and the `status` of the presentations. ```json [ { "id": "urn:transmute:presentation:ca239f8a-5700-4cdd-b60a-626163506e26", "sender": { "name": "Alice", "did": "did:web:example.com:org_ABC" }, "receiver": { "uri": "http://example.com/organizations/org_ABC/presentations/submissions", "name": "Alice" }, "status": "presentation_unopened", "verifiablePresentation": "ey...", "createdAt": "2024-07-23T22:15:40.594Z" }, ... ] ``` ### 6. Verifying and Accepting Presentations The *presentation receiver* may verify the inbound presentation anytime, for example as part of deciding whether or not to accept it. Verification is done with the “/presentations/verify” endpoint: ```bash curl --location --request POST 'https://platform.transmute.industries/api/presentations/verify' \ --header 'Authorization: Bearer **Your token here**' \ --header 'Content-Type: application/json' \ --data-raw '{ "verifiablePresentation": **Verifiable presentation here** } ' ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guide.transmute.industries/verifiable-data-platform/technical-documentation/didauth-presentations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.