Merge pull request #583 from Concordium/vp-v1/naming-alignment

Vp v1/naming alignment

Author: soerenbf

docs/pages/verifiable-presentations.md

@@ -7,8 +7,8 @@ This document describes how to create v1 verifiable presentations and how to ver
 - [Build Statement](#build-statement)
   - [Identity/account credential statements](#identityaccount-credential-statements)
 - [JSON representation](#json-representation)
-- [Verifiable Presentation Request (proof request)](#verifiable-presentation-request-proof-request)
-- [Verifiable Presentation (proof)](#verifiable-presentation-proof)
+- [Verification Request](#verification-request)
+- [Verifiable Presentation](#verifiable-presentation)
 - [Verifiable Audit Record](#verifiable-audit-record)
 <!--toc:end-->
 
@@ -131,7 +131,7 @@ Note that this type of statement is only allowed for the following attributes:
 
 ## JSON representation
 
-The `VerifiablePresentationRequestV1`, `VerifiablePresentationV1`, and `VerifiableAuditRecordV1` can be represented as
+The `VerificationRequestV1`, `VerifiablePresentationV1`, and `VerifiableAuditRecordV1` can be represented as
 JSON by calling the associated `.toJSON` method (will also be called implicitly with `JSON.stringify`). Correspondingly,
 parsing the JSON values can be done with the `.fromJSON` function exposed for each type.
 
@@ -142,13 +142,13 @@ Example: service serializes presentation request in response to frontend; fronte
 ```ts
 const json = JSON.stringify(presentationRequest); // service sends back presentation request to frontend
 ...
-const presentationRequest = VerifiablePresentationRequestV1.fromJSON(JSON.parse(json)); // frontend parses the JSON.
+const presentationRequest = VerificationRequestV1.fromJSON(JSON.parse(json)); // frontend parses the JSON.
 ```
 
-## Verifiable Presentation Request (proof request)
+## Verification Request
 
 To get a _verifiable presentation_ of one or more _verifiable credentials_ owned by a user, the entity requesting
-the information must first build a _verifiable presentation request_. In the V1 protocol, this is done in the following
+the information must first build a _verification request_. In the V1 protocol, this is done in the following
 sequence:
 
 1. Make the _request context_, consisting of
@@ -166,9 +166,9 @@ Once this is done, the request must be _anchored_ on chain with a transaction. T
 const nonce = Uint8Array.from(...) // randomly generated 32-byte value
 const connectionID = ... // e.g. a wallet-connect ID
 const contextString = 'My compliant web3 wine shop'
-const context = VerifiablePresentationRequestV1.createSimpleContext(nonce, connectionID, contextString)
+const context = VerificationRequestV1.createSimpleContext(nonce, connectionID, contextString)
 
-const statement = new VerifiablePresentationRequestV1.statementBuilder()...
+const statement = new VerificationRequestV1.statementBuilder()...
 
 // a GRPC client connected a node on the network the anchor should be registered on
 const grpcClient: ConcordiumGRPCClient = ...;
@@ -177,8 +177,8 @@ const sender: AccountAddress.Type = ...;
 // the keys for the account to sign the anchor transaction
 const signer: Signer = ...;
 
-// create the presentation request with an on-chain anchor, which can be checked by the owner of the credentials.
-const presentationRequest = await VerifiablePresentationRequestV1.createAndAchor(
+// create the verification request with an on-chain anchor, which can be checked by the owner of the credentials.
+const verificationRequest = await VerificationRequestV1.createAndAchor(
     grpcClient,
     sender,
     signer,
@@ -187,24 +187,24 @@ const presentationRequest = await VerifiablePresentationRequestV1.createAndAchor
 );
 ```
 
-## Verifiable Presentation (proof)
+## Verifiable Presentation
 
 Computing a _verifiable presentation_ from a _verifiable presentation request_ is a process of the following sequence
 for each credential statement in the request:
 
-1. Identify valid credentials for the statement by looking at the ID qualifier of the `VerfiablePresentationRequest.Statement`.
+1. Identify valid credentials for the statement by looking at the ID qualifier of the `VerificationRequestV1.Statement`.
 2. Validate the attributes of the credential in the context of the statement.
 3. Construct a `VerifiablePresentationV1.Statement` corresponding to the credential. This is is _not_ the same as the
-   `VerfiablePresentationRequest.Statement` we built for the `VerfiablePresentationRequest` previously; here we're working with
+   `VerificationRequestV1.Statement` we built for the `VerificationRequestV1` previously; here we're working with
    a specific credential, e.g. from the users wallet.
-    a. for `VerfiablePresentationRequest.IdentityStatement`s, the `source` also needs to be taken into account. This
+    a. for `VerificationRequestV1.IdentityStatement`s, the `source` also needs to be taken into account. This
        specifies the type of credential requested by the dapp. This can either be set to
        `["Identity"] | ["Account"] | ["Identity", "Account"]`, where the latter means that the application constructing
        the proof can decide which proof to construct for the statement.
 
 When this is done for all credential statements in the request, we construct the _proof context_ corresponding to the
 _request context_ of the request, specifying values for each requested context value in
-`VerifiablePresentationRequestV1.Context.requested`.
+`VerificationRequestV1.Context.requested`.
 
 ```ts
 // specify the resource ID (e.g. website URL or fingerprint of TLS certificate that the wallet is connected to)
@@ -213,14 +213,14 @@ _request context_ of the request, specifying values for each requested context v
 // request.
 const contextValues: GivenContext[] = [{label: 'ResourceID', context: ...}];
 
-// The application goes through each statement in the presentation request, and constructs a corresponding statement
+// The application goes through each statement in the verification request, and constructs a corresponding statement
 // used as input to the presentation. The difference between the two statement types boil down to the presence of an ID
 // qualifier vs. an ID (selected by the application based on the id qualifier).
-const statements: VerifiablePresentationV1.Statement[] = presentationRequest.credentialStatements.map((entry) => {
+const statements: VerifiablePresentationV1.SubjectClaims[] = verificationRequest.credentialStatements.map((entry) => {
     // prioritize creating identity based proofs, as these are more privacy-preserving
     if (entry.source.includes('identity'))
-        return {id: createIdentityStatementDID(...), statement: entry.statement};
-    return {id: createAccountDID(...), statement: entry.statement};
+        return VerifiablePresentationV1.createIdentityClaims(..., entry.statement);
+    return VerifiablePresentation.createAccountClaims(..., entry.statement);
 });
 
 // the inputs for the credential owned by the user, i.e. credential attribute values. For each
@@ -232,24 +232,24 @@ const inputs: CommitmentInput[] = [
 
 const presentation = await VerifiablePresentationV1.createFromAnchor(
     grpcClient,
-    presentationRequest,
+    verificationRequest,
     statements,
     inputs,
     contextValues
 );
 
 // verify the presentation elsewhere
-const result = VerifiablePresentationV1.verifyWithNode(presentation, presentationRequest, grpcClient, network);
+const result = VerifiablePresentationV1.verifyWithNode(presentation, verificationRequest, grpcClient, network);
 ```
 
 ## Verifiable Audit Record
 
-Services can opt in to create a _verification audit record_ from the _verifiable presentation request_ and corresponding
+Services can opt in to create a _verification audit record_ from the _verification request_ and corresponding
 _verifiable presentation_. This exists as a record and a corresponding anchor. The record should be stored by the dapp backend (e.g. in a database),
 and the anchor should be registered on chain. The transacton hash of the anchor registration should be stored along the record.
 
 ```ts
 const uuid: string = ...;
-const record = VerificationAuditRecordV1.create(uuid, presentationRequest, presentation);
+const record = VerificationAuditRecordV1.create(uuid, verificationRequest, presentation);
 const anchorTransactionHash = await VerificationAuditRecordV1.registerAnchor(record, grpcClient, sender, signer);
 ```

examples/nodejs/common/verifiable-credential-statements.ts

@@ -1,7 +1,7 @@
-import { IdentityProviderDID, VerifiablePresentationRequestV1 } from '@concordium/web-sdk';
+import { IdentityProviderDID, VerificationRequestV1 } from '@concordium/web-sdk';
 
 // #region documentation-snippet
-let builder = VerifiablePresentationRequestV1.statementBuilder();
+let builder = VerificationRequestV1.statementBuilder();
 
 // Add an identity credential statement. Alternatively, if the proof produced from the
 // statement should be tied to an account, use `builder.addAccountStatement`.

examples/nodejs/proofs/verifiable-presentation-id-cred.ts

@@ -4,11 +4,10 @@ import {
     IdentityObjectV1,
     IdentityProvider,
     IdentityProviderDID,
-    VerifiablePresentationRequestV1,
     VerifiablePresentationV1,
     VerificationAuditRecordV1,
+    VerificationRequestV1,
     createIdentityCommitmentInputWithHdWallet,
-    createIdentityStatementDID,
     sha256,
     streamToList,
 } from '@concordium/web-sdk';
@@ -118,35 +117,30 @@ const grpc = new ConcordiumGRPCNodeClient(
 
 const [sender, signer] = parseKeysFile(walletFile);
 
-// First we generate the presentation request.
+// First we generate the verification request.
 //
 // This will normally happen server-side.
-const context = VerifiablePresentationRequestV1.createSimpleContext(
+const context = VerificationRequestV1.createSimpleContext(
     sha256([Buffer.from(Date.now().toString())]),
     randomUUID(),
     'Example VP'
 );
-const statements = VerifiablePresentationRequestV1.statementBuilder()
+const statements = VerificationRequestV1.statementBuilder()
     .addAccountOrIdentityStatement([new IdentityProviderDID(network, identityProviderIndex)], (b) => {
         b.addEUResidency();
         b.addMinimumAge(18);
     })
     .getStatements();
-const presentationRequest = await VerifiablePresentationRequestV1.createAndAchor(
-    grpc,
-    sender,
-    signer,
-    context,
-    statements,
-    { info: 'Example VP anchor' }
-);
+const verificationRequest = await VerificationRequestV1.createAndAchor(grpc, sender, signer, context, statements, {
+    info: 'Example VP anchor',
+});
 
-console.log('PRESENTATION REQUEST: \n', JSONBig.stringify(presentationRequest, null, 2), '\n');
+console.log('VERIFICATION REQUEST: \n', JSONBig.stringify(verificationRequest, null, 2), '\n');
 
-// simulate sending a response to the client requesting the presentation request
-const requestJson = JSONBig.stringify(presentationRequest);
+// simulate sending a response to the client requesting the verification request
+const requestJson = JSONBig.stringify(verificationRequest);
 
-// Then we create the presentation.
+// Then we create the verifiable presentation.
 //
 // This will normally happen in an application that holds the user credentials. In this example, the information
 // normally held by said application, i.e. the credential used, the idp index, and the id index, is passed as program
@@ -167,21 +161,17 @@ const arsInfos: Record<number, ArInfo> = ars.reduce((acc, ar) => {
 }, {});
 const idp: IdentityProvider = { ipInfo, arsInfos };
 
-// simulate receiving presentation request
-const requestParsed = VerifiablePresentationRequestV1.fromJSON(JSONBig.parse(requestJson));
+// simulate receiving verification request
+const requestParsed = VerificationRequestV1.fromJSON(JSONBig.parse(requestJson));
 // At this point, we have all the values held inside the application.
 // From the above, we retreive the secret input which is at the core of creating the verifiable presentation (proof)
-const credentialInput = createIdentityCommitmentInputWithHdWallet(idObject, idp, identityIndex, wallet);
+const proofInput = createIdentityCommitmentInputWithHdWallet(idObject, idp, identityIndex, wallet);
 
 // we select the identity to prove the statement for
-const selectedIdentity = createIdentityStatementDID(network); // we unwrap here, as we know the statement exists (we created it just above)
 const idStatement = requestParsed.credentialStatements.find(
     (s) => s.type === 'identity'
-)! as VerifiablePresentationRequestV1.IdentityStatement; // we unwrap here, as we know the statement exists (we created it just above)
-const specifiedStatement: VerifiablePresentationV1.IdentityStatement = {
-    id: selectedIdentity,
-    statement: idStatement.statement,
-};
+)! as VerificationRequestV1.IdentityStatement; // we unwrap here, as we know the statement exists (we created it just above)
+const claims = VerifiablePresentationV1.createIdentityClaims(network, idp.ipInfo.ipIdentity, idStatement.statement);
 
 console.log('Waiting for anchor transaction to finalize:', requestParsed.transactionRef.toString());
 
@@ -191,8 +181,8 @@ await grpc.waitForTransactionFinalization(requestParsed.transactionRef);
 const presentation = await VerifiablePresentationV1.createFromAnchor(
     grpc,
     requestParsed,
-    [specifiedStatement],
-    [credentialInput],
+    [claims],
+    [proofInput],
     [{ label: 'ResourceID', context: 'Example VP use-case' }]
 );
 
@@ -204,11 +194,11 @@ console.log('PRESENTATION:\n', JSONBig.stringify(presentation, null, 2), '\n');
 // simulate receiving presentation to be verified
 const presentationParsed = VerifiablePresentationV1.fromJSON(JSONBig.parse(presentationJson));
 
-if (!(await VerifiablePresentationV1.verifyWithNode(presentationParsed, presentationRequest, grpc, network)))
+if (!(await VerifiablePresentationV1.verifyWithNode(presentationParsed, verificationRequest, grpc, network)))
     throw new Error('Failed to verify the presentation');
 
 // Finally, the entity requesting the proof stores the audit report and registers a pulic version on chain
-const report = VerificationAuditRecordV1.create(randomUUID(), presentationRequest, presentation);
+const report = VerificationAuditRecordV1.create(randomUUID(), verificationRequest, presentation);
 const auditTransaction = await VerificationAuditRecordV1.registerAnchor(report, grpc, sender, signer, {
     info: 'Some public info',
 });

packages/rust-bindings/ts-src/dapp.ts

@@ -7,6 +7,6 @@ import wasmBase64 from '../lib/dapp/web/esm/index_bg.wasm';
 // Expected to resolve to base64 encoded bytes of wasm module
 
 const bytes = Buffer.from(wasmBase64, 'base64');
-initSync(bytes);
+initSync({ module: bytes });
 
 export * from '../lib/dapp/web/esm/index.js';

packages/rust-bindings/ts-src/wallet.ts

@@ -7,6 +7,6 @@ import wasmBase64 from '../lib/wallet/web/esm/index_bg.wasm';
 // Expected to resolve to base64 encoded bytes of wasm module
 
 const bytes = Buffer.from(wasmBase64, 'base64');
-initSync(bytes);
+initSync({ module: bytes });
 
 export * from '../lib/wallet/web/esm/index.js';

packages/sdk/CHANGELOG.md

@@ -2,6 +2,25 @@
 
 ## Unreleased
 
+## 11.1.0-alpha.2
+
+### Added
+
+- `VerifiablePresentationV1.createAccountClaims` and `VerifiablePresentationV1.createIdentityClaims` to build the
+  subject claims used as input for the `VerifiablePresentationV1.create...` functions.
+
+### Changed
+
+- `createIdentityStatementDID` now takes the index of the identity provider of the identity.
+- `VerifiablePresentationRequestV1` renamed to `VerificationRequestV1`
+
+- `VerifiablePresentationV1.Statement` renamed to `VerifiablePresentationV1.SubjectClaims` to align with the w3c VC spec
+  - `VerifiablePresentationV1.AccountStatement` -> `VerifiablePresentationV1.AccountClaims`, created with
+    `VerifiablePresentation.createAccountClaims`.
+  - `VerifiablePresentationV1.IdentityStatement` -> `VerifiablePresentationV1.IdentityClaims`, created with
+    `VerifiablePresentation.createIdentityClaims`.
+- `VerifiablePresentationV1.CredentialInputs` renamed to `VerifiablePresentationV1.VerificationMaterial`.
+
 ## 11.1.0-alpha.1
 
 ### Fixed

packages/sdk/src/wasm/VerifiablePresentationV1/audit-record.ts

@@ -13,7 +13,7 @@ import {
 } from '../../types.js';
 import { cborDecode, cborEncode } from '../../types/cbor.js';
 import { AccountAddress, DataBlob, TransactionExpiry, TransactionHash } from '../../types/index.js';
-import { VerifiablePresentationRequestV1, VerifiablePresentationV1 } from './index.js';
+import { VerifiablePresentationV1, VerificationRequestV1 } from './index.js';
 
 const JSONBig = _JB({ alwaysParseAsBig: true, useNativeBigInt: true });
 
@@ -37,7 +37,7 @@ class VerificationAuditRecordV1 {
      * @param id - Unique identifier for this audit record
      */
     constructor(
-        public readonly request: VerifiablePresentationRequestV1.Type,
+        public readonly request: VerificationRequestV1.Type,
         public readonly presentation: VerifiablePresentationV1.Type,
         public readonly id: string
     ) {}
@@ -79,7 +79,7 @@ export type JSON = Pick<Type, 'id'> & {
     /** The audit record version */
     version: 1;
     /** The serialized verifiable presentation request */
-    request: VerifiablePresentationRequestV1.JSON;
+    request: VerificationRequestV1.JSON;
     /** The serialized verifiable presentation */
     presentation: VerifiablePresentationV1.JSON;
 };
@@ -95,7 +95,7 @@ export type JSON = Pick<Type, 'id'> & {
  */
 export function create(
     id: string,
-    request: VerifiablePresentationRequestV1.Type,
+    request: VerificationRequestV1.Type,
     presentation: VerifiablePresentationV1.Type
 ): VerificationAuditRecordV1 {
     return new VerificationAuditRecordV1(request, presentation, id);
@@ -109,7 +109,7 @@ export function create(
  */
 export function fromJSON(json: JSON): VerificationAuditRecordV1 {
     return new VerificationAuditRecordV1(
-        VerifiablePresentationRequestV1.fromJSON(json.request),
+        VerificationRequestV1.fromJSON(json.request),
         VerifiablePresentationV1.fromJSON(json.presentation),
         json.id
     );

packages/sdk/src/wasm/VerifiablePresentationV1/index.ts

@@ -9,15 +9,14 @@
  * - VerifiablePresentationRequestV1: For creating and managing presentation requests
  * - VerifiablePresentationV1: For creating and verifying presentations with ZK proofs
  * - VerificationAuditRecord: For public audit trails of verification events
- * - PrivateVerificationAuditRecord: For private audit records with full data
  */
 import * as VerificationAuditRecordV1 from './audit-record.js';
 import * as VerifiablePresentationV1 from './proof.js';
-import * as VerifiablePresentationRequestV1 from './request.js';
+import * as VerificationRequestV1 from './request.js';
 
 export {
-    /** Namespace for verifiable presentation request operations */
-    VerifiablePresentationRequestV1,
+    /** Namespace for verification request operations */
+    VerificationRequestV1,
     /** Namespace for verifiable presentation proof operations */
     VerifiablePresentationV1,
     /** Namespace for verification audit record operations */