Package co.ankatech.keymanagement.client.keymanagement.api

Class CapabilityGrantsApi

java.lang.Object
co.ankatech.keymanagement.client.keymanagement.api.CapabilityGrantsApi
public class CapabilityGrantsApi extends Object

  • Constructor Details

    • CapabilityGrantsApi

      public CapabilityGrantsApi()

    • CapabilityGrantsApi

      public CapabilityGrantsApi(ApiClient apiClient)

  • Method Details

    • getApiClient

      public ApiClient getApiClient()

    • setApiClient

      public void setApiClient(ApiClient apiClient)

    • getHostIndex

      public int getHostIndex()

    • setHostIndex

      public void setHostIndex(int hostIndex)

    • getCustomBaseUrl

      public String getCustomBaseUrl()

    • setCustomBaseUrl

      public void setCustomBaseUrl(String customBaseUrl)

    • createCapabilityGrantCall

      public okhttp3.Call createCapabilityGrantCall(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest, ApiCallback _callback) throws ApiException
      Build call for createCapabilityGrant
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • createCapabilityGrant

      public CapabilityGrantResponse createCapabilityGrant(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest) throws ApiException
      Create Capability Grant A wildcard grant (an empty assetKids) requires allowWildcardAsset=true; without it the body fails validation and the answer is the 400. Every FK (actorId, exchangeContextId, constraintPolicyId) is validated to belong to the path tenant — cross-tenant probing is rejected. **This operation confers standing operation authority on the Actor.** While the grant is effective, the scopes its capabilities derive are part of every token the Actor mints — without any `actor_roles` row being written. That is why the caller must also hold `admin.tenant.actor.roles.assign` whenever the grant would add a scope the Actor does not already hold, and why the operation is refused outright under a support-access impersonation session. Call `previewCapabilityGrant` first to obtain the same verdict without writing anything: it returns the refusal this operation would return, with the same `type` URI. **An Actor that an Internal Crypto Use Case owns cannot receive a standalone grant.** A use case's actor acts only for that use case: its grants are the use case's own, created with it and revoked with it, so authority attached from outside would widen the use case beyond its declared operations and die silently when the use case is revoked. The refusal is `422 actor-owned-by-use-case`, and ownership is the use case's record of the actor — an INTERNAL actor an operator created is admitted.
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      Returns:
      CapabilityGrantResponse
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • createCapabilityGrantWithHttpInfo

      public ApiResponse<CapabilityGrantResponse> createCapabilityGrantWithHttpInfo(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest) throws ApiException
      Create Capability Grant A wildcard grant (an empty assetKids) requires allowWildcardAsset=true; without it the body fails validation and the answer is the 400. Every FK (actorId, exchangeContextId, constraintPolicyId) is validated to belong to the path tenant — cross-tenant probing is rejected. **This operation confers standing operation authority on the Actor.** While the grant is effective, the scopes its capabilities derive are part of every token the Actor mints — without any `actor_roles` row being written. That is why the caller must also hold `admin.tenant.actor.roles.assign` whenever the grant would add a scope the Actor does not already hold, and why the operation is refused outright under a support-access impersonation session. Call `previewCapabilityGrant` first to obtain the same verdict without writing anything: it returns the refusal this operation would return, with the same `type` URI. **An Actor that an Internal Crypto Use Case owns cannot receive a standalone grant.** A use case's actor acts only for that use case: its grants are the use case's own, created with it and revoked with it, so authority attached from outside would widen the use case beyond its declared operations and die silently when the use case is revoked. The refusal is `422 actor-owned-by-use-case`, and ownership is the use case's record of the actor — an INTERNAL actor an operator created is admitted.
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      Returns:
      ApiResponse<CapabilityGrantResponse>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • createCapabilityGrantAsync

      public okhttp3.Call createCapabilityGrantAsync(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest, ApiCallback<CapabilityGrantResponse> _callback) throws ApiException
      Create Capability Grant (asynchronously) A wildcard grant (an empty assetKids) requires allowWildcardAsset=true; without it the body fails validation and the answer is the 400. Every FK (actorId, exchangeContextId, constraintPolicyId) is validated to belong to the path tenant — cross-tenant probing is rejected. **This operation confers standing operation authority on the Actor.** While the grant is effective, the scopes its capabilities derive are part of every token the Actor mints — without any `actor_roles` row being written. That is why the caller must also hold `admin.tenant.actor.roles.assign` whenever the grant would add a scope the Actor does not already hold, and why the operation is refused outright under a support-access impersonation session. Call `previewCapabilityGrant` first to obtain the same verdict without writing anything: it returns the refusal this operation would return, with the same `type` URI. **An Actor that an Internal Crypto Use Case owns cannot receive a standalone grant.** A use case's actor acts only for that use case: its grants are the use case's own, created with it and revoked with it, so authority attached from outside would widen the use case beyond its declared operations and die silently when the use case is revoked. The refusal is `422 actor-owned-by-use-case`, and ownership is the use case's record of the actor — an INTERNAL actor an operator created is admitted.
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object

    • deleteCapabilityGrantCall

      public okhttp3.Call deleteCapabilityGrantCall(@Nonnull UUID tenantId, @Nonnull UUID grantId, ApiCallback _callback) throws ApiException
      Build call for deleteCapabilityGrant
      Parameters:
      tenantId - (required)
      grantId - (required)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • deleteCapabilityGrant

      public void deleteCapabilityGrant(@Nonnull UUID tenantId, @Nonnull UUID grantId) throws ApiException
      Revoke Capability Grant (soft delete — re-grantable at same dimensions later)
      Parameters:
      tenantId - (required)
      grantId - (required)
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • deleteCapabilityGrantWithHttpInfo

      public ApiResponse<Void> deleteCapabilityGrantWithHttpInfo(@Nonnull UUID tenantId, @Nonnull UUID grantId) throws ApiException
      Revoke Capability Grant (soft delete — re-grantable at same dimensions later)
      Parameters:
      tenantId - (required)
      grantId - (required)
      Returns:
      ApiResponse<Void>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • deleteCapabilityGrantAsync

      public okhttp3.Call deleteCapabilityGrantAsync(@Nonnull UUID tenantId, @Nonnull UUID grantId, ApiCallback<Void> _callback) throws ApiException
      Revoke Capability Grant (soft delete — re-grantable at same dimensions later) (asynchronously)
      Parameters:
      tenantId - (required)
      grantId - (required)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object

    • getCapabilityGrantCall

      public okhttp3.Call getCapabilityGrantCall(@Nonnull UUID tenantId, @Nonnull UUID grantId, ApiCallback _callback) throws ApiException
      Build call for getCapabilityGrant
      Parameters:
      tenantId - (required)
      grantId - (required)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • getCapabilityGrant

      public CapabilityGrantResponse getCapabilityGrant(@Nonnull UUID tenantId, @Nonnull UUID grantId) throws ApiException
      Get Capability Grant
      Parameters:
      tenantId - (required)
      grantId - (required)
      Returns:
      CapabilityGrantResponse
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • getCapabilityGrantWithHttpInfo

      public ApiResponse<CapabilityGrantResponse> getCapabilityGrantWithHttpInfo(@Nonnull UUID tenantId, @Nonnull UUID grantId) throws ApiException
      Get Capability Grant
      Parameters:
      tenantId - (required)
      grantId - (required)
      Returns:
      ApiResponse<CapabilityGrantResponse>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • getCapabilityGrantAsync

      public okhttp3.Call getCapabilityGrantAsync(@Nonnull UUID tenantId, @Nonnull UUID grantId, ApiCallback<CapabilityGrantResponse> _callback) throws ApiException
      Get Capability Grant (asynchronously)
      Parameters:
      tenantId - (required)
      grantId - (required)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object

    • listCapabilityGrantsCall

      public okhttp3.Call listCapabilityGrantsCall(@Nonnull UUID tenantId, @Nullable UUID actorId, @Nullable String assetKid, @Nullable UUID exchangeContextId, @Nullable UUID constraintPolicyId, @Nullable Integer page, @Nullable Integer size, @Nullable List<String> sort, ApiCallback _callback) throws ApiException
      Build call for listCapabilityGrants
      Parameters:
      tenantId - (required)
      actorId - (optional)
      assetKid - Cryptographic asset kid to filter by (JSONB array membership on assetKids — matches atomic grants and either position of cross-kid grants) (optional)
      exchangeContextId - Exchange Context id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      constraintPolicyId - Constraint Policy id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      page - Zero-based page index (0..N) (optional, default to 0)
      size - The size of the page to be returned (optional, default to 25)
      sort - Sorting criteria in the format: property,(asc|desc). Default sort order is ascending. Multiple sort criteria are supported. (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • listCapabilityGrants

      public PageCapabilityGrantResponse listCapabilityGrants(@Nonnull UUID tenantId, @Nullable UUID actorId, @Nullable String assetKid, @Nullable UUID exchangeContextId, @Nullable UUID constraintPolicyId, @Nullable Integer page, @Nullable Integer size, @Nullable List<String> sort) throws ApiException
      List Capability Grants in tenant Returns the Capability Grants of the tenant that `getCapabilityGrant` can read: every grant in force, plus every grant retired because it was used up (revoke-on-use, or its maximum use count reached), which carries its `consumption` (time, use count, cause). A grant in force has `consumption: null`. A consumed grant authorizes nothing; it is listed so its consumption stays visible. Revoked grants, and grants whose Exchange expired or was revoked, are not listed. The list is optionally filtered by `actorId`, `assetKid`, `exchangeContextId` and/or `constraintPolicyId` (all AND-composed). Use `actorId` to render the Actor detail page, `assetKid` to render the per-key Access tab, `exchangeContextId` for the exchange-context blast-radius view, and `constraintPolicyId` to list the grants issued under a Constraint Policy. The `assetKid` filter matches JSONB array MEMBERSHIP on `assetKids` — cross-kid REENCRYPT/RESIGN grants match whether the key is the source or the target. The `exchangeContextId` and `constraintPolicyId` filters match the grant's scalar exchange-context and constraint-policy FKs. An unknown kid, exchange context or constraint policy (or one belonging to another tenant) returns an EMPTY page with HTTP 200 — never 403/404 — so resource existence is not disclosed. `assetKid`-filtered results are ordered by creation time descending (custom sort parameters are not applied on that path).
      Parameters:
      tenantId - (required)
      actorId - (optional)
      assetKid - Cryptographic asset kid to filter by (JSONB array membership on assetKids — matches atomic grants and either position of cross-kid grants) (optional)
      exchangeContextId - Exchange Context id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      constraintPolicyId - Constraint Policy id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      page - Zero-based page index (0..N) (optional, default to 0)
      size - The size of the page to be returned (optional, default to 25)
      sort - Sorting criteria in the format: property,(asc|desc). Default sort order is ascending. Multiple sort criteria are supported. (optional)
      Returns:
      PageCapabilityGrantResponse
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • listCapabilityGrantsWithHttpInfo

      public ApiResponse<PageCapabilityGrantResponse> listCapabilityGrantsWithHttpInfo(@Nonnull UUID tenantId, @Nullable UUID actorId, @Nullable String assetKid, @Nullable UUID exchangeContextId, @Nullable UUID constraintPolicyId, @Nullable Integer page, @Nullable Integer size, @Nullable List<String> sort) throws ApiException
      List Capability Grants in tenant Returns the Capability Grants of the tenant that `getCapabilityGrant` can read: every grant in force, plus every grant retired because it was used up (revoke-on-use, or its maximum use count reached), which carries its `consumption` (time, use count, cause). A grant in force has `consumption: null`. A consumed grant authorizes nothing; it is listed so its consumption stays visible. Revoked grants, and grants whose Exchange expired or was revoked, are not listed. The list is optionally filtered by `actorId`, `assetKid`, `exchangeContextId` and/or `constraintPolicyId` (all AND-composed). Use `actorId` to render the Actor detail page, `assetKid` to render the per-key Access tab, `exchangeContextId` for the exchange-context blast-radius view, and `constraintPolicyId` to list the grants issued under a Constraint Policy. The `assetKid` filter matches JSONB array MEMBERSHIP on `assetKids` — cross-kid REENCRYPT/RESIGN grants match whether the key is the source or the target. The `exchangeContextId` and `constraintPolicyId` filters match the grant's scalar exchange-context and constraint-policy FKs. An unknown kid, exchange context or constraint policy (or one belonging to another tenant) returns an EMPTY page with HTTP 200 — never 403/404 — so resource existence is not disclosed. `assetKid`-filtered results are ordered by creation time descending (custom sort parameters are not applied on that path).
      Parameters:
      tenantId - (required)
      actorId - (optional)
      assetKid - Cryptographic asset kid to filter by (JSONB array membership on assetKids — matches atomic grants and either position of cross-kid grants) (optional)
      exchangeContextId - Exchange Context id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      constraintPolicyId - Constraint Policy id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      page - Zero-based page index (0..N) (optional, default to 0)
      size - The size of the page to be returned (optional, default to 25)
      sort - Sorting criteria in the format: property,(asc|desc). Default sort order is ascending. Multiple sort criteria are supported. (optional)
      Returns:
      ApiResponse<PageCapabilityGrantResponse>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • listCapabilityGrantsAsync

      public okhttp3.Call listCapabilityGrantsAsync(@Nonnull UUID tenantId, @Nullable UUID actorId, @Nullable String assetKid, @Nullable UUID exchangeContextId, @Nullable UUID constraintPolicyId, @Nullable Integer page, @Nullable Integer size, @Nullable List<String> sort, ApiCallback<PageCapabilityGrantResponse> _callback) throws ApiException
      List Capability Grants in tenant (asynchronously) Returns the Capability Grants of the tenant that `getCapabilityGrant` can read: every grant in force, plus every grant retired because it was used up (revoke-on-use, or its maximum use count reached), which carries its `consumption` (time, use count, cause). A grant in force has `consumption: null`. A consumed grant authorizes nothing; it is listed so its consumption stays visible. Revoked grants, and grants whose Exchange expired or was revoked, are not listed. The list is optionally filtered by `actorId`, `assetKid`, `exchangeContextId` and/or `constraintPolicyId` (all AND-composed). Use `actorId` to render the Actor detail page, `assetKid` to render the per-key Access tab, `exchangeContextId` for the exchange-context blast-radius view, and `constraintPolicyId` to list the grants issued under a Constraint Policy. The `assetKid` filter matches JSONB array MEMBERSHIP on `assetKids` — cross-kid REENCRYPT/RESIGN grants match whether the key is the source or the target. The `exchangeContextId` and `constraintPolicyId` filters match the grant's scalar exchange-context and constraint-policy FKs. An unknown kid, exchange context or constraint policy (or one belonging to another tenant) returns an EMPTY page with HTTP 200 — never 403/404 — so resource existence is not disclosed. `assetKid`-filtered results are ordered by creation time descending (custom sort parameters are not applied on that path).
      Parameters:
      tenantId - (required)
      actorId - (optional)
      assetKid - Cryptographic asset kid to filter by (JSONB array membership on assetKids — matches atomic grants and either position of cross-kid grants) (optional)
      exchangeContextId - Exchange Context id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      constraintPolicyId - Constraint Policy id to filter by (scalar FK match on the grant). An unknown or cross-tenant id returns an empty page (never 403/404). (optional)
      page - Zero-based page index (0..N) (optional, default to 0)
      size - The size of the page to be returned (optional, default to 25)
      sort - Sorting criteria in the format: property,(asc|desc). Default sort order is ascending. Multiple sort criteria are supported. (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object

    • previewCapabilityGrantCall

      public okhttp3.Call previewCapabilityGrantCall(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest, ApiCallback _callback) throws ApiException
      Build call for previewCapabilityGrant
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • previewCapabilityGrant

      public ConferralPlanResponse previewCapabilityGrant(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest) throws ApiException
      Preview a Capability Grant creation — writes nothing Returns the verdict `createCapabilityGrant` would return for this exact body, and the scopes it would confer, without creating anything. The body, its validation and the refusal order are the SAME as the create's: this is one computation asked a different question, not a second opinion about it. Which refusals come back as a status and which come back INSIDE a 200 is decided by what the refusal is about: - Refusals about the REQUEST — a named resource that does not resolve (404), an Actor an Internal Crypto Use Case owns (422 `actor-owned-by-use-case`), a wildcard grant without its opt-in (400), a tenant type that does not permit control-plane mutation (422) — are returned as that status. The question cannot be answered, so there is no plan to describe. - Refusals about the CONFERRAL — the key cannot carry the capability, the Actor is not ACTIVE, the caller lacks `admin.tenant.actor.roles.assign` — come back as HTTP 200 with `refusal` populated, carrying the SAME `type` URI the create would have answered with. Describing them is the point: the console states the cause before the operator submits. Disclosure is bounded. `operationPermissions.required` and `confersNew` always answer; `alreadyHeld` and `toAdd` name scopes and are null unless the caller also holds `admin.tenant.actor.roles.read` — read `namesVisible` rather than inferring a withheld list from a null. Nothing states HOW MANY scopes would be added: this operation accepts any actor in the tenant, so without `roles.read` the caller learns only whether the grant would add anything — which the create reveals anyway by being admitted or refused. A cross-kid grant (REENCRYPT, RESIGN) names its two kids as `[source, target]`, and each is checked only for its own half: the source must permit the consuming operation (`decrypt` / `verify`), the target the producing one (`encrypt` / `sign`). An encrypt-only key is therefore an admissible REENCRYPT target. This operation is NOT refused under impersonation. It writes nothing and confers nothing; it reports what the write would do.
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      Returns:
      ConferralPlanResponse
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • previewCapabilityGrantWithHttpInfo

      public ApiResponse<ConferralPlanResponse> previewCapabilityGrantWithHttpInfo(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest) throws ApiException
      Preview a Capability Grant creation — writes nothing Returns the verdict `createCapabilityGrant` would return for this exact body, and the scopes it would confer, without creating anything. The body, its validation and the refusal order are the SAME as the create's: this is one computation asked a different question, not a second opinion about it. Which refusals come back as a status and which come back INSIDE a 200 is decided by what the refusal is about: - Refusals about the REQUEST — a named resource that does not resolve (404), an Actor an Internal Crypto Use Case owns (422 `actor-owned-by-use-case`), a wildcard grant without its opt-in (400), a tenant type that does not permit control-plane mutation (422) — are returned as that status. The question cannot be answered, so there is no plan to describe. - Refusals about the CONFERRAL — the key cannot carry the capability, the Actor is not ACTIVE, the caller lacks `admin.tenant.actor.roles.assign` — come back as HTTP 200 with `refusal` populated, carrying the SAME `type` URI the create would have answered with. Describing them is the point: the console states the cause before the operator submits. Disclosure is bounded. `operationPermissions.required` and `confersNew` always answer; `alreadyHeld` and `toAdd` name scopes and are null unless the caller also holds `admin.tenant.actor.roles.read` — read `namesVisible` rather than inferring a withheld list from a null. Nothing states HOW MANY scopes would be added: this operation accepts any actor in the tenant, so without `roles.read` the caller learns only whether the grant would add anything — which the create reveals anyway by being admitted or refused. A cross-kid grant (REENCRYPT, RESIGN) names its two kids as `[source, target]`, and each is checked only for its own half: the source must permit the consuming operation (`decrypt` / `verify`), the target the producing one (`encrypt` / `sign`). An encrypt-only key is therefore an admissible REENCRYPT target. This operation is NOT refused under impersonation. It writes nothing and confers nothing; it reports what the write would do.
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      Returns:
      ApiResponse<ConferralPlanResponse>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • previewCapabilityGrantAsync

      public okhttp3.Call previewCapabilityGrantAsync(@Nonnull UUID tenantId, @Nonnull CreateCapabilityGrantRequest createCapabilityGrantRequest, ApiCallback<ConferralPlanResponse> _callback) throws ApiException
      Preview a Capability Grant creation — writes nothing (asynchronously) Returns the verdict `createCapabilityGrant` would return for this exact body, and the scopes it would confer, without creating anything. The body, its validation and the refusal order are the SAME as the create's: this is one computation asked a different question, not a second opinion about it. Which refusals come back as a status and which come back INSIDE a 200 is decided by what the refusal is about: - Refusals about the REQUEST — a named resource that does not resolve (404), an Actor an Internal Crypto Use Case owns (422 `actor-owned-by-use-case`), a wildcard grant without its opt-in (400), a tenant type that does not permit control-plane mutation (422) — are returned as that status. The question cannot be answered, so there is no plan to describe. - Refusals about the CONFERRAL — the key cannot carry the capability, the Actor is not ACTIVE, the caller lacks `admin.tenant.actor.roles.assign` — come back as HTTP 200 with `refusal` populated, carrying the SAME `type` URI the create would have answered with. Describing them is the point: the console states the cause before the operator submits. Disclosure is bounded. `operationPermissions.required` and `confersNew` always answer; `alreadyHeld` and `toAdd` name scopes and are null unless the caller also holds `admin.tenant.actor.roles.read` — read `namesVisible` rather than inferring a withheld list from a null. Nothing states HOW MANY scopes would be added: this operation accepts any actor in the tenant, so without `roles.read` the caller learns only whether the grant would add anything — which the create reveals anyway by being admitted or refused. A cross-kid grant (REENCRYPT, RESIGN) names its two kids as `[source, target]`, and each is checked only for its own half: the source must permit the consuming operation (`decrypt` / `verify`), the target the producing one (`encrypt` / `sign`). An encrypt-only key is therefore an admissible REENCRYPT target. This operation is NOT refused under impersonation. It writes nothing and confers nothing; it reports what the write would do.
      Parameters:
      tenantId - (required)
      createCapabilityGrantRequest - (required)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object