@meeco/svx-api-sdk 1.0.0-stage.20231211153548.58a6d84 → 1.0.0-stage.20231218095603.d71b65e

package/.openapi-generator/FILES

@@ -265,6 +265,7 @@ models/ShreIntentListResponse.ts
 models/UpdateDelegationsRequest.ts
 models/VCApp.ts
 models/VCAppSignal.ts
+models/VCClaimsDto.ts
 models/VCCnfDto.ts
 models/VCComponent.ts
 models/VCConstraintsDto.ts
@@ -297,9 +298,11 @@ models/VCDatabase.ts
 models/VCErrorResponseDto.ts
 models/VCErrorsResponseDto.ts
 models/VCFieldsDto.ts
+models/VCFieldsDtoFilter.ts
+models/VCFilterDto.ts
 models/VCFormatDto.ts
 models/VCGenerateCredentialDto.ts
-models/VCGenerateCredentialDtoCnf.ts
+models/VCGenerateCredentialDtoClaims.ts
 models/VCGenerateCredentialPayloadDto.ts
 models/VCGeneratePresentationDto.ts
 models/VCGeneratePresentationPayloadDto.ts

package/lib/esm/apis/SharesApi.js

@@ -347,7 +347,7 @@ export class SharesApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Share your item with connected users
      */
     itemsIdSharesPostRaw(requestParameters, initOverrides) {
@@ -382,7 +382,7 @@ export class SharesApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Share your item with connected users
      */
     itemsIdSharesPost(id, meecoDelegationId, meecoOrganisationId, postItemSharesRequest, initOverrides) {
@@ -392,7 +392,7 @@ export class SharesApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Update all shares of one item
      */
     itemsIdSharesPutRaw(requestParameters, initOverrides) {
@@ -427,7 +427,7 @@ export class SharesApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Update all shares of one item
      */
     itemsIdSharesPut(id, meecoDelegationId, meecoOrganisationId, putItemSharesRequest, initOverrides) {

package/lib/esm/apis/VerifiableCredentialsApi.js

@@ -304,7 +304,7 @@ export class VerifiableCredentialsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p>
+     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p><br /><h4>Type property caveat</h4><p> <code>Type</code> is required for <code>vc+sd-jwt</code> format and must be a string <br /> however, endpoint accepts <code>Type</code> as an Array of string for <code>JWT VC</code> in format of <code>[\"VerifiableCredential\", \"AlumniCredential\"]</code> as well. <br /></p>
      * Generate credential based on type and claims provided
      */
     credentialsGeneratePostRaw(requestParameters, initOverrides) {
@@ -342,7 +342,7 @@ export class VerifiableCredentialsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p>
+     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p><br /><h4>Type property caveat</h4><p> <code>Type</code> is required for <code>vc+sd-jwt</code> format and must be a string <br /> however, endpoint accepts <code>Type</code> as an Array of string for <code>JWT VC</code> in format of <code>[\"VerifiableCredential\", \"AlumniCredential\"]</code> as well. <br /></p>
      * Generate credential based on type and claims provided
      */
     credentialsGeneratePost(meecoOrganisationID, vCGenerateCredentialPayloadDto, accept, initOverrides) {

package/lib/esm/models/{VCGenerateCredentialDtoCnf.js → VCClaimsDto.js}

@@ -11,26 +11,28 @@
  * https://openapi-generator.tech
  * Do not edit the class manually.
  */
+import { exists } from '../runtime';
+import { VCCnfDtoFromJSON, VCCnfDtoToJSON, } from './VCCnfDto';
 /**
- * Check if a given object implements the VCGenerateCredentialDtoCnf interface.
+ * Check if a given object implements the VCClaimsDto interface.
  */
-export function instanceOfVCGenerateCredentialDtoCnf(value) {
+export function instanceOfVCClaimsDto(value) {
     let isInstance = true;
-    isInstance = isInstance && "jwk" in value;
     return isInstance;
 }
-export function VCGenerateCredentialDtoCnfFromJSON(json) {
-    return VCGenerateCredentialDtoCnfFromJSONTyped(json, false);
+export function VCClaimsDtoFromJSON(json) {
+    return VCClaimsDtoFromJSONTyped(json, false);
 }
-export function VCGenerateCredentialDtoCnfFromJSONTyped(json, ignoreDiscriminator) {
+export function VCClaimsDtoFromJSONTyped(json, ignoreDiscriminator) {
     if ((json === undefined) || (json === null)) {
         return json;
     }
     return {
-        'jwk': json['jwk'],
+        'id': !exists(json, 'id') ? undefined : json['id'],
+        'cnf': !exists(json, 'cnf') ? undefined : VCCnfDtoFromJSON(json['cnf']),
     };
 }
-export function VCGenerateCredentialDtoCnfToJSON(value) {
+export function VCClaimsDtoToJSON(value) {
     if (value === undefined) {
         return undefined;
     }
@@ -38,6 +40,7 @@ export function VCGenerateCredentialDtoCnfToJSON(value) {
         return null;
     }
     return {
-        'jwk': value.jwk,
+        'id': value.id,
+        'cnf': VCCnfDtoToJSON(value.cnf),
     };
 }

package/lib/esm/models/VCCredentialVerificationResultResponseDto.js

@@ -21,7 +21,8 @@ export const VCCredentialVerificationResultResponseDtoChecksEnum = {
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCCredentialVerificationResultResponseDto interface.

package/lib/esm/models/VCFieldsDto.js

@@ -12,6 +12,7 @@
  * Do not edit the class manually.
  */
 import { exists } from '../runtime';
+import { VCFieldsDtoFilterFromJSON, VCFieldsDtoFilterToJSON, } from './VCFieldsDtoFilter';
 /**
  * Check if a given object implements the VCFieldsDto interface.
  */
@@ -30,7 +31,7 @@ export function VCFieldsDtoFromJSONTyped(json, ignoreDiscriminator) {
     return {
         'path': json['path'],
         'purpose': !exists(json, 'purpose') ? undefined : json['purpose'],
-        'filter': !exists(json, 'filter') ? undefined : json['filter'],
+        'filter': !exists(json, 'filter') ? undefined : VCFieldsDtoFilterFromJSON(json['filter']),
     };
 }
 export function VCFieldsDtoToJSON(value) {
@@ -43,6 +44,6 @@ export function VCFieldsDtoToJSON(value) {
     return {
         'path': value.path,
         'purpose': value.purpose,
-        'filter': value.filter,
+        'filter': VCFieldsDtoFilterToJSON(value.filter),
     };
 }

package/lib/esm/models/VCFieldsDtoFilter.js

@@ -0,0 +1,48 @@
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * SVX API
+ * No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
+ *
+ * The version of the OpenAPI document: 1.3.1
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import { exists } from '../runtime';
+/**
+ * Check if a given object implements the VCFieldsDtoFilter interface.
+ */
+export function instanceOfVCFieldsDtoFilter(value) {
+    let isInstance = true;
+    isInstance = isInstance && "type" in value;
+    return isInstance;
+}
+export function VCFieldsDtoFilterFromJSON(json) {
+    return VCFieldsDtoFilterFromJSONTyped(json, false);
+}
+export function VCFieldsDtoFilterFromJSONTyped(json, ignoreDiscriminator) {
+    if ((json === undefined) || (json === null)) {
+        return json;
+    }
+    return {
+        'type': json['type'],
+        '_const': !exists(json, 'const') ? undefined : json['const'],
+        'pattern': !exists(json, 'pattern') ? undefined : json['pattern'],
+    };
+}
+export function VCFieldsDtoFilterToJSON(value) {
+    if (value === undefined) {
+        return undefined;
+    }
+    if (value === null) {
+        return null;
+    }
+    return {
+        'type': value.type,
+        'const': value._const,
+        'pattern': value.pattern,
+    };
+}

package/lib/esm/models/VCFilterDto.js

@@ -0,0 +1,48 @@
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * SVX API
+ * No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
+ *
+ * The version of the OpenAPI document: 1.3.1
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import { exists } from '../runtime';
+/**
+ * Check if a given object implements the VCFilterDto interface.
+ */
+export function instanceOfVCFilterDto(value) {
+    let isInstance = true;
+    isInstance = isInstance && "type" in value;
+    return isInstance;
+}
+export function VCFilterDtoFromJSON(json) {
+    return VCFilterDtoFromJSONTyped(json, false);
+}
+export function VCFilterDtoFromJSONTyped(json, ignoreDiscriminator) {
+    if ((json === undefined) || (json === null)) {
+        return json;
+    }
+    return {
+        'type': json['type'],
+        '_const': !exists(json, 'const') ? undefined : json['const'],
+        'pattern': !exists(json, 'pattern') ? undefined : json['pattern'],
+    };
+}
+export function VCFilterDtoToJSON(value) {
+    if (value === undefined) {
+        return undefined;
+    }
+    if (value === null) {
+        return null;
+    }
+    return {
+        'type': value.type,
+        'const': value._const,
+        'pattern': value.pattern,
+    };
+}

package/lib/esm/models/VCGenerateCredentialDto.js

@@ -12,7 +12,7 @@
  * Do not edit the class manually.
  */
 import { exists } from '../runtime';
-import { VCGenerateCredentialDtoCnfFromJSON, VCGenerateCredentialDtoCnfToJSON, } from './VCGenerateCredentialDtoCnf';
+import { VCGenerateCredentialDtoClaimsFromJSON, VCGenerateCredentialDtoClaimsToJSON, } from './VCGenerateCredentialDtoClaims';
 /**
  * Check if a given object implements the VCGenerateCredentialDto interface.
  */
@@ -33,10 +33,10 @@ export function VCGenerateCredentialDtoFromJSONTyped(json, ignoreDiscriminator)
     return {
         'credential_type_id': json['credential_type_id'],
         'issuer': json['issuer'],
-        'claims': json['claims'],
+        'claims': VCGenerateCredentialDtoClaimsFromJSON(json['claims']),
         'revocable': !exists(json, 'revocable') ? undefined : json['revocable'],
         'expires_at': !exists(json, 'expires_at') ? undefined : (new Date(json['expires_at'])),
-        'cnf': !exists(json, 'cnf') ? undefined : VCGenerateCredentialDtoCnfFromJSON(json['cnf']),
+        'type': !exists(json, 'type') ? undefined : json['type'],
     };
 }
 export function VCGenerateCredentialDtoToJSON(value) {
@@ -49,9 +49,9 @@ export function VCGenerateCredentialDtoToJSON(value) {
     return {
         'credential_type_id': value.credential_type_id,
         'issuer': value.issuer,
-        'claims': value.claims,
+        'claims': VCGenerateCredentialDtoClaimsToJSON(value.claims),
         'revocable': value.revocable,
         'expires_at': value.expires_at === undefined ? undefined : (value.expires_at.toISOString()),
-        'cnf': VCGenerateCredentialDtoCnfToJSON(value.cnf),
+        'type': value.type,
     };
 }

package/lib/esm/models/VCGenerateCredentialDtoClaims.js

@@ -0,0 +1,40 @@
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * SVX API
+ * No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
+ *
+ * The version of the OpenAPI document: 1.3.1
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import { exists } from '../runtime';
+import { VCCnfDtoFromJSON, VCCnfDtoToJSON, } from './VCCnfDto';
+/**
+ * Check if a given object implements the VCGenerateCredentialDtoClaims interface.
+ */
+export function instanceOfVCGenerateCredentialDtoClaims(value) {
+    let isInstance = true;
+    return isInstance;
+}
+export function VCGenerateCredentialDtoClaimsFromJSON(json) {
+    return VCGenerateCredentialDtoClaimsFromJSONTyped(json, false);
+}
+export function VCGenerateCredentialDtoClaimsFromJSONTyped(json, ignoreDiscriminator) {
+    if ((json === undefined) || (json === null)) {
+        return json;
+    }
+    return Object.assign(Object.assign({}, json), { 'id': !exists(json, 'id') ? undefined : json['id'], 'cnf': !exists(json, 'cnf') ? undefined : VCCnfDtoFromJSON(json['cnf']) });
+}
+export function VCGenerateCredentialDtoClaimsToJSON(value) {
+    if (value === undefined) {
+        return undefined;
+    }
+    if (value === null) {
+        return null;
+    }
+    return Object.assign(Object.assign({}, value), { 'id': value.id, 'cnf': VCCnfDtoToJSON(value.cnf) });
+}

package/lib/esm/models/VCIdTokenVerificationResultResponseDto.js

@@ -21,7 +21,8 @@ export const VCIdTokenVerificationResultResponseDtoChecksEnum = {
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCIdTokenVerificationResultResponseDto interface.

package/lib/esm/models/VCOldPresentationRequestResponseVerificationResultResponseDto.js

@@ -21,7 +21,8 @@ export const VCOldPresentationRequestResponseVerificationResultResponseDtoChecks
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCOldPresentationRequestResponseVerificationResultResponseDto interface.

package/lib/esm/models/VCPresentationRequestResponseVerificationOptionsDto.js

@@ -19,7 +19,8 @@ import { VCRequestVerificationOptionsDtoFromJSON, VCRequestVerificationOptionsDt
  * @export
  */
 export const VCPresentationRequestResponseVerificationOptionsDtoChecksEnum = {
-    Format: 'format'
+    Format: 'format',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCPresentationRequestResponseVerificationOptionsDto interface.

package/lib/esm/models/VCPresentationRequestResponseVerificationResultResponseDto.js

@@ -24,7 +24,8 @@ export const VCPresentationRequestResponseVerificationResultResponseDtoChecksEnu
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCPresentationRequestResponseVerificationResultResponseDto interface.

package/lib/esm/models/VCPresentationRequestUpdateVerificationResultRequestDto.js

@@ -24,7 +24,8 @@ export const VCPresentationRequestUpdateVerificationResultRequestDtoChecksEnum =
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCPresentationRequestUpdateVerificationResultRequestDto interface.

package/lib/esm/models/VCPresentationRequestVerificationResultResponseDto.js

@@ -21,7 +21,8 @@ export const VCPresentationRequestVerificationResultResponseDtoChecksEnum = {
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCPresentationRequestVerificationResultResponseDto interface.

package/lib/esm/models/VCPresentationVerificationOptionsDto.js

@@ -19,7 +19,8 @@ export const VCPresentationVerificationOptionsDtoChecksEnum = {
     Format: 'format',
     Signature: 'signature',
     Expiration: 'expiration',
-    Nonce: 'nonce'
+    Nonce: 'nonce',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCPresentationVerificationOptionsDto interface.

package/lib/esm/models/VCPresentationVerificationResultResponseDto.js

@@ -22,7 +22,8 @@ export const VCPresentationVerificationResultResponseDtoChecksEnum = {
     Expiration: 'expiration',
     Nonce: 'nonce',
     Schema: 'schema',
-    RevocationStatus: 'revocation_status'
+    RevocationStatus: 'revocation_status',
+    Constraints: 'constraints'
 };
 /**
  * Check if a given object implements the VCPresentationVerificationResultResponseDto interface.

package/lib/esm/models/index.js

@@ -248,6 +248,7 @@ export * from './ShreIntentListResponse';
 export * from './UpdateDelegationsRequest';
 export * from './VCApp';
 export * from './VCAppSignal';
+export * from './VCClaimsDto';
 export * from './VCCnfDto';
 export * from './VCComponent';
 export * from './VCConstraintsDto';
@@ -280,9 +281,11 @@ export * from './VCDatabase';
 export * from './VCErrorResponseDto';
 export * from './VCErrorsResponseDto';
 export * from './VCFieldsDto';
+export * from './VCFieldsDtoFilter';
+export * from './VCFilterDto';
 export * from './VCFormatDto';
 export * from './VCGenerateCredentialDto';
-export * from './VCGenerateCredentialDtoCnf';
+export * from './VCGenerateCredentialDtoClaims';
 export * from './VCGenerateCredentialPayloadDto';
 export * from './VCGeneratePresentationDto';
 export * from './VCGeneratePresentationPayloadDto';

package/lib/types/apis/SharesApi.d.ts

@@ -183,22 +183,22 @@ export declare class SharesApi extends runtime.BaseAPI {
      */
     itemsIdSharesGet(id: string, meecoDelegationId?: string, meecoOrganisationId?: string, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GetItemSharesResponse>;
     /**
-     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Share your item with connected users
      */
     itemsIdSharesPostRaw(requestParameters: ItemsIdSharesPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<VaultSharesCreateResponse>>;
     /**
-     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Share your item with connected users.  Each share can be a share of all slots of the item, in that case `slot_id` is `NULL`, or it can be a share of just one slot. In this case `slot_id` references one of the slots of the item.  There are 3 users involved in each share:  * owner - the owner of the shared item * sender -  the user who shares data. Can be the owner or one of the recipients * recipient - the user who recieves the shared data.   Whether a non-owner may on-share a shared slot is defined in field `onsharing_permitted`.  Only the owner of the item can set `onsharing_permitted` to `true`. If `onsharing_permitted` is `false`, the recipient may on-share the item, but when that recipient creates an on-share, `onsharing_permitted` in that on-share is forced to be `false`. In other words, the depth of on-sharing in limited to 3:       OWNER ==> RECIPIENT AND SENDER ==>  RECIPIENT    Some shares require that the recipient accepts the terms of the share. Until the terms are not accepted the share DEK is hidden.   Data in slots is initially encrypted with the DEK in field `encrypted_dek`. The DEK in `encrypted_dek` is encrypted with the public key of the share recipient. When processing a share the client application is expected to decrypt the slot data and re-encrypt with the private DEK.  A public key of the recipient is needed to encrypt the share DEK. Updating all shares of the same item is performed by the owner in one go. In a situation when a share has been created by a recipient, not the owner, and there is no connection between the owner and the recipient, the owner has no access to a public key of the recipient. In order to address this problem when a share is created we also add fields `public_key` and `keypair_external_id` from the connection record between the recipient and the sender. `keypair_external_id` identifies the keypair that the public key belongs to.  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`. Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Share your item with connected users
      */
     itemsIdSharesPost(id: string, meecoDelegationId?: string, meecoOrganisationId?: string, postItemSharesRequest?: PostItemSharesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<VaultSharesCreateResponse>;
     /**
-     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Update all shares of one item
      */
     itemsIdSharesPutRaw(requestParameters: ItemsIdSharesPutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ItemSharesUpdateResponse>>;
     /**
-     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `encrypted_value_verification_key` when creating or updating the share. When other senders create a share, `encrypted_value_verification_key` must be `NULL`.  `value_verification_hash` may and should be sent by every sender, owner or not, because `value_verification_hash` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
+     * Updating all shares of one item is done by the item owner in one go.  Before calling this endpoint the client application is expected to retrieve the list of shares IDs and public keys via `GET /items/{id}/shares`.  The POST body of this endpoint contains  * a list of share DEKs encrypted with public keys of share recipients * a list of slot values for each slot and each share, each encrypted with the DEK of the share that the slot belongs to  * Optionally: a list of completed `ClientTask` tasks  When a recipient of a share on-shares the data with someone else, nothing prevents him/her to encrypt some other data instead of the original data. We need a way to enforce integrity of on-shares. We do this with help of HMAC - hash-based message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.    Two fields in each slot are used for this purpose: * `encrypted_value_verification_key` - is a value verification key encrypted in the same way as the value itself: with the share DEK * `value_verification_hash` - the result of the HMAC function run on the slot value using `encrypted_value_verification_key`. `value_verification_hash` is stored as-is, unencrypted.   Only the owner of the data may send `value_verification_hash` when creating or updating the share. When other senders create a share, `value_verification_hash` must be `NULL`.  `encrypted_value_verification_key` may and should be sent by every sender, owner or not, because `encrypted_value_verification_key` must be re-encrypted with the share DEK for each share.  If the sender replaces `encrypted_value_verification_key` and/or the slot value, this will break the client-side verification against `encrypted_value_verification_key`.  Field `encrypted_value` may be `NULL`. If `encrypted_value` is `NULL`, then `encrypted_value_verification_key` and `value_verification_hash` may also be `NULL`. If `encrypted_value` is present, then `encrypted_value_verification_key` and `value_verification_hash` are mandatory.
      * Update all shares of one item
      */
     itemsIdSharesPut(id: string, meecoDelegationId?: string, meecoOrganisationId?: string, putItemSharesRequest?: PutItemSharesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ItemSharesUpdateResponse>;

package/lib/types/apis/VerifiableCredentialsApi.d.ts

@@ -162,12 +162,12 @@ export declare class VerifiableCredentialsApi extends runtime.BaseAPI {
      */
     credentialTypesPost(meecoOrganisationID: string, vCCreateCredentialTypePayloadDto: VCCreateCredentialTypePayloadDto, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<VCCredentialTypeResponseDto>;
     /**
-     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p>
+     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p><br /><h4>Type property caveat</h4><p> <code>Type</code> is required for <code>vc+sd-jwt</code> format and must be a string <br /> however, endpoint accepts <code>Type</code> as an Array of string for <code>JWT VC</code> in format of <code>[\"VerifiableCredential\", \"AlumniCredential\"]</code> as well. <br /></p>
      * Generate credential based on type and claims provided
      */
     credentialsGeneratePostRaw(requestParameters: CredentialsGeneratePostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<VCUnsignedCredentialResponseDto>>;
     /**
-     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p>
+     * <h4>Requires the following security rights:</h4><ul><li><code>vc:org:manage</code></li></ul><br /><hr /><p>Generates unsigned verifiable credential token in JWT format. Client is expected to sign it with a private key.</p><hr /><p>An example of how credential signing in Javascript:</p><pre><code>import { generateKeyPairFromSeed } from \'@stablelib/ed25519\'; <br />import { EdDSASigner, hexToBytes } from \'did-jwt\'; <br /><br />const key = generateKeyPairFromSeed(hexToBytes(SECRET_HEX)); <br />const signerFn = EdDSASigner(key.secretKey); <br /><br />const signature = await signerFn(unsignedJwt); <br />const vcJwt = [unsignedJwt, signature].join(\'.\');</code></pre><hr /><br /><h4>Issuer property caveat</h4><p>We use <b>openapi-generator</b> to generate Typescript SDK for the given API swagger definition. However, <b>openapi-generator</b> does not support <b>oneOf</b> configuration properly and generates an invalid Typescript SDK. To avoid the problem, swagger defines <b>issuer</b> property only as string for the moment. While in fact, endpoint accepts issuer as an object in format of <code>{id: string; name: string;}</code> as well.</p><br /><h4>Type property caveat</h4><p> <code>Type</code> is required for <code>vc+sd-jwt</code> format and must be a string <br /> however, endpoint accepts <code>Type</code> as an Array of string for <code>JWT VC</code> in format of <code>[\"VerifiableCredential\", \"AlumniCredential\"]</code> as well. <br /></p>
      * Generate credential based on type and claims provided
      */
     credentialsGeneratePost(meecoOrganisationID: string, vCGenerateCredentialPayloadDto: VCGenerateCredentialPayloadDto, accept?: CredentialsGeneratePostAcceptEnum, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<VCUnsignedCredentialResponseDto>;