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 Creates a grant owned by no other governance object (ownerType INDEPENDENT). Every grant authorizes in exactly one Exchange Context: `exchangeContextId` is required and must name an ACTIVE context of the tenant. A basic grant carries one to four of ENCRYPT, DECRYPT, SIGN, VERIFY over exactly one Key ID in `assetKids`; a REENCRYPT or RESIGN grant carries that one capability over one or more ordered `keyPairs`, each authorizing its own direction only (sourceKid to targetKid; the same Key ID on both ends is the in-place transformation). A wildcard basic grant (an empty `assetKids`) requires allowWildcardAsset=true and is admitted in a STANDARD tenant only. Every FK (actorId, exchangeContextId, constraintPolicyId) is validated to belong to the path tenant — cross-tenant probing is rejected. **An actor's live grants never overlap.** A grant whose capabilities and resources intersect a live grant of the same actor is refused 409 `capability-grant-overlap`, whatever the other grant's context, policy or owner: a wildcard intersects every Key ID, and key pairs intersect only when they are the same ordered pair. So the platform authorizes a request by at most one grant. **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 Creates a grant owned by no other governance object (ownerType INDEPENDENT). Every grant authorizes in exactly one Exchange Context: `exchangeContextId` is required and must name an ACTIVE context of the tenant. A basic grant carries one to four of ENCRYPT, DECRYPT, SIGN, VERIFY over exactly one Key ID in `assetKids`; a REENCRYPT or RESIGN grant carries that one capability over one or more ordered `keyPairs`, each authorizing its own direction only (sourceKid to targetKid; the same Key ID on both ends is the in-place transformation). A wildcard basic grant (an empty `assetKids`) requires allowWildcardAsset=true and is admitted in a STANDARD tenant only. Every FK (actorId, exchangeContextId, constraintPolicyId) is validated to belong to the path tenant — cross-tenant probing is rejected. **An actor's live grants never overlap.** A grant whose capabilities and resources intersect a live grant of the same actor is refused 409 `capability-grant-overlap`, whatever the other grant's context, policy or owner: a wildcard intersects every Key ID, and key pairs intersect only when they are the same ordered pair. So the platform authorizes a request by at most one grant. **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) Creates a grant owned by no other governance object (ownerType INDEPENDENT). Every grant authorizes in exactly one Exchange Context: `exchangeContextId` is required and must name an ACTIVE context of the tenant. A basic grant carries one to four of ENCRYPT, DECRYPT, SIGN, VERIFY over exactly one Key ID in `assetKids`; a REENCRYPT or RESIGN grant carries that one capability over one or more ordered `keyPairs`, each authorizing its own direction only (sourceKid to targetKid; the same Key ID on both ends is the in-place transformation). A wildcard basic grant (an empty `assetKids`) requires allowWildcardAsset=true and is admitted in a STANDARD tenant only. Every FK (actorId, exchangeContextId, constraintPolicyId) is validated to belong to the path tenant — cross-tenant probing is rejected. **An actor's live grants never overlap.** A grant whose capabilities and resources intersect a live grant of the same actor is refused 409 `capability-grant-overlap`, whatever the other grant's context, policy or owner: a wildcard intersects every Key ID, and key pairs intersect only when they are the same ordered pair. So the platform authorizes a request by at most one grant. **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

    • 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

    • getCapabilityGrantEffectiveRestrictionsCall

      public okhttp3.Call getCapabilityGrantEffectiveRestrictionsCall(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nullable OffsetDateTime at, ApiCallback _callback) throws ApiException
      Build call for getCapabilityGrantEffectiveRestrictions
      Parameters:
      tenantId - (required)
      grantId - (required)
      at - The instant asked about, RFC 3339; now when omitted. (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • getCapabilityGrantEffectiveRestrictions

      public CapabilityGrantEffectiveRestrictions getCapabilityGrantEffectiveRestrictions(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nullable OffsetDateTime at) throws ApiException
      Get the restrictions that governed a Capability Grant at an instant The Constraint Policy version in force for the grant at <code>at</code> (now when omitted), with its limits and its weekday and time-of-day schedule, read from the grant's assignment history. When no version was pinned at that instant every version member is null and the grant was unlimited. <code>scheduleTimeZone</code> is the platform zone the schedule is evaluated in, as currently set. An instant before the grant was created returns 404. **Authorization**: requires scope <code>admin.tenant.capability-grant.read</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      at - The instant asked about, RFC 3339; now when omitted. (optional)
      Returns:
      CapabilityGrantEffectiveRestrictions
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • getCapabilityGrantEffectiveRestrictionsWithHttpInfo

      public ApiResponse<CapabilityGrantEffectiveRestrictions> getCapabilityGrantEffectiveRestrictionsWithHttpInfo(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nullable OffsetDateTime at) throws ApiException
      Get the restrictions that governed a Capability Grant at an instant The Constraint Policy version in force for the grant at <code>at</code> (now when omitted), with its limits and its weekday and time-of-day schedule, read from the grant's assignment history. When no version was pinned at that instant every version member is null and the grant was unlimited. <code>scheduleTimeZone</code> is the platform zone the schedule is evaluated in, as currently set. An instant before the grant was created returns 404. **Authorization**: requires scope <code>admin.tenant.capability-grant.read</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      at - The instant asked about, RFC 3339; now when omitted. (optional)
      Returns:
      ApiResponse<CapabilityGrantEffectiveRestrictions>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • getCapabilityGrantEffectiveRestrictionsAsync

      public okhttp3.Call getCapabilityGrantEffectiveRestrictionsAsync(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nullable OffsetDateTime at, ApiCallback<CapabilityGrantEffectiveRestrictions> _callback) throws ApiException
      Get the restrictions that governed a Capability Grant at an instant (asynchronously) The Constraint Policy version in force for the grant at <code>at</code> (now when omitted), with its limits and its weekday and time-of-day schedule, read from the grant's assignment history. When no version was pinned at that instant every version member is null and the grant was unlimited. <code>scheduleTimeZone</code> is the platform zone the schedule is evaluated in, as currently set. An instant before the grant was created returns 404. **Authorization**: requires scope <code>admin.tenant.capability-grant.read</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      at - The instant asked about, RFC 3339; now when omitted. (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

    • listCapabilityGrantPolicyAssignmentsCall

      public okhttp3.Call listCapabilityGrantPolicyAssignmentsCall(@Nonnull UUID tenantId, @Nonnull UUID grantId, ApiCallback _callback) throws ApiException
      Build call for listCapabilityGrantPolicyAssignments
      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

    • listCapabilityGrantPolicyAssignments

      public List<CapabilityGrantPolicyAssignment> listCapabilityGrantPolicyAssignments(@Nonnull UUID tenantId, @Nonnull UUID grantId) throws ApiException
      List the Constraint Policy versions a Capability Grant has been pinned to The grant's assignments in order, from the pin it was created with to the one in force now. Each names the version, when it took effect, who pinned it and the assignment it replaced; a version governs the grant from its <code>assignedAt</code> until the next assignment's. A grant created without a policy and never re-pinned has none. The history of a revoked or used-up grant stays readable. **Authorization**: requires scope <code>admin.tenant.capability-grant.read</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      Returns:
      List<CapabilityGrantPolicyAssignment>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • listCapabilityGrantPolicyAssignmentsWithHttpInfo

      public ApiResponse<List<CapabilityGrantPolicyAssignment>> listCapabilityGrantPolicyAssignmentsWithHttpInfo(@Nonnull UUID tenantId, @Nonnull UUID grantId) throws ApiException
      List the Constraint Policy versions a Capability Grant has been pinned to The grant's assignments in order, from the pin it was created with to the one in force now. Each names the version, when it took effect, who pinned it and the assignment it replaced; a version governs the grant from its <code>assignedAt</code> until the next assignment's. A grant created without a policy and never re-pinned has none. The history of a revoked or used-up grant stays readable. **Authorization**: requires scope <code>admin.tenant.capability-grant.read</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      Returns:
      ApiResponse<List<CapabilityGrantPolicyAssignment>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • listCapabilityGrantPolicyAssignmentsAsync

      public okhttp3.Call listCapabilityGrantPolicyAssignmentsAsync(@Nonnull UUID tenantId, @Nonnull UUID grantId, ApiCallback<List<CapabilityGrantPolicyAssignment>> _callback) throws ApiException
      List the Constraint Policy versions a Capability Grant has been pinned to (asynchronously) The grant's assignments in order, from the pin it was created with to the one in force now. Each names the version, when it took effect, who pinned it and the assignment it replaced; a version governs the grant from its <code>assignedAt</code> until the next assignment's. A grant created without a policy and never re-pinned has none. The history of a revoked or used-up grant stays readable. **Authorization**: requires scope <code>admin.tenant.capability-grant.read</code>.
      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 - Key ID to filter by: matches a basic grant naming it in assetKids and a REENCRYPT or RESIGN grant naming it as either end of a key pair (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 a grant that names the key: as its `assetKids` entry, or as the source or the target of one of its `keyPairs`. 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 - Key ID to filter by: matches a basic grant naming it in assetKids and a REENCRYPT or RESIGN grant naming it as either end of a key pair (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 a grant that names the key: as its `assetKids` entry, or as the source or the target of one of its `keyPairs`. 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 - Key ID to filter by: matches a basic grant naming it in assetKids and a REENCRYPT or RESIGN grant naming it as either end of a key pair (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 a grant that names the key: as its `assetKids` entry, or as the source or the target of one of its `keyPairs`. 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 - Key ID to filter by: matches a basic grant naming it in assetKids and a REENCRYPT or RESIGN grant naming it as either end of a key pair (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 REENCRYPT or RESIGN grant names its keys as ordered `keyPairs`, and each pair end 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 REENCRYPT or RESIGN grant names its keys as ordered `keyPairs`, and each pair end 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 REENCRYPT or RESIGN grant names its keys as ordered `keyPairs`, and each pair end 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

    • replaceCapabilityGrantPolicyVersionCall

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

    • replaceCapabilityGrantPolicyVersion

      public CapabilityGrantPolicyAssignment replaceCapabilityGrantPolicyVersion(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull ReplaceCapabilityGrantPolicyVersionRequest replaceCapabilityGrantPolicyVersionRequest) throws ApiException
      Re-pin a Capability Grant to another Constraint Policy version Pins the grant to the named Constraint Policy version, which governs it from the next request on. Any version of any Constraint Policy of the tenant may be named: a later or an earlier version of the grant's own policy, a version of another policy, or a first policy for a grant that had none. The grant's capabilities, keys, Exchange Context and owner are unchanged, and the pin is recorded as a new assignment in the grant's history (<code>listCapabilityGrantPolicyAssignments</code>), which is never rewritten. **Usage counting.** The grant keeps the uses already counted against it, and the new version's <code>maxUsage</code> is applied to that count: a grant with 8 counted uses re-pinned to a version with <code>maxUsage</code> 5 is refused on its next request. Uses made while no limit was pinned (no <code>maxUsage</code> and no <code>revokeOnUse</code>) are not counted, so they do not count toward a limit pinned later: a grant re-pinned from an unlimited version to <code>maxUsage</code> 5 admits 5 further uses. **Refusals** (409 <code>capability-grant-repin-refused</code>, nothing changed, the cause in <code>extensions.reason</code>): the grant was used up (<code>CONSUMED</code>) or revoked (<code>REVOKED</code>), so a re-pin never revives a grant; it is already pinned to the version (<code>SAME_VERSION</code>); the version is not a version of a live Constraint Policy of this tenant (<code>VERSION_NOT_IN_TENANT</code>); the grant belongs to an Internal Crypto Use Case, whose renewal re-pins its grants (<code>OWNED_BY_USE_CASE</code>), or to the marketplace plan, whose tier change re-pins them (<code>OWNED_BY_MARKETPLACE</code>). Every re-pin emits one signed audit event, <code>capability-grant.policy-version-replaced</code>, naming the grant, the previous and the new version, and the previous and new value of each limit and schedule field that changed. The operation is refused under a support-access impersonation session, like <code>createCapabilityGrant</code>: a re-pin can widen what the grant authorizes after the session ends. **Authorization**: requires scope <code>admin.tenant.capability-grant.repin</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      replaceCapabilityGrantPolicyVersionRequest - (required)
      Returns:
      CapabilityGrantPolicyAssignment
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • replaceCapabilityGrantPolicyVersionWithHttpInfo

      public ApiResponse<CapabilityGrantPolicyAssignment> replaceCapabilityGrantPolicyVersionWithHttpInfo(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull ReplaceCapabilityGrantPolicyVersionRequest replaceCapabilityGrantPolicyVersionRequest) throws ApiException
      Re-pin a Capability Grant to another Constraint Policy version Pins the grant to the named Constraint Policy version, which governs it from the next request on. Any version of any Constraint Policy of the tenant may be named: a later or an earlier version of the grant's own policy, a version of another policy, or a first policy for a grant that had none. The grant's capabilities, keys, Exchange Context and owner are unchanged, and the pin is recorded as a new assignment in the grant's history (<code>listCapabilityGrantPolicyAssignments</code>), which is never rewritten. **Usage counting.** The grant keeps the uses already counted against it, and the new version's <code>maxUsage</code> is applied to that count: a grant with 8 counted uses re-pinned to a version with <code>maxUsage</code> 5 is refused on its next request. Uses made while no limit was pinned (no <code>maxUsage</code> and no <code>revokeOnUse</code>) are not counted, so they do not count toward a limit pinned later: a grant re-pinned from an unlimited version to <code>maxUsage</code> 5 admits 5 further uses. **Refusals** (409 <code>capability-grant-repin-refused</code>, nothing changed, the cause in <code>extensions.reason</code>): the grant was used up (<code>CONSUMED</code>) or revoked (<code>REVOKED</code>), so a re-pin never revives a grant; it is already pinned to the version (<code>SAME_VERSION</code>); the version is not a version of a live Constraint Policy of this tenant (<code>VERSION_NOT_IN_TENANT</code>); the grant belongs to an Internal Crypto Use Case, whose renewal re-pins its grants (<code>OWNED_BY_USE_CASE</code>), or to the marketplace plan, whose tier change re-pins them (<code>OWNED_BY_MARKETPLACE</code>). Every re-pin emits one signed audit event, <code>capability-grant.policy-version-replaced</code>, naming the grant, the previous and the new version, and the previous and new value of each limit and schedule field that changed. The operation is refused under a support-access impersonation session, like <code>createCapabilityGrant</code>: a re-pin can widen what the grant authorizes after the session ends. **Authorization**: requires scope <code>admin.tenant.capability-grant.repin</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      replaceCapabilityGrantPolicyVersionRequest - (required)
      Returns:
      ApiResponse<CapabilityGrantPolicyAssignment>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • replaceCapabilityGrantPolicyVersionAsync

      public okhttp3.Call replaceCapabilityGrantPolicyVersionAsync(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull ReplaceCapabilityGrantPolicyVersionRequest replaceCapabilityGrantPolicyVersionRequest, ApiCallback<CapabilityGrantPolicyAssignment> _callback) throws ApiException
      Re-pin a Capability Grant to another Constraint Policy version (asynchronously) Pins the grant to the named Constraint Policy version, which governs it from the next request on. Any version of any Constraint Policy of the tenant may be named: a later or an earlier version of the grant's own policy, a version of another policy, or a first policy for a grant that had none. The grant's capabilities, keys, Exchange Context and owner are unchanged, and the pin is recorded as a new assignment in the grant's history (<code>listCapabilityGrantPolicyAssignments</code>), which is never rewritten. **Usage counting.** The grant keeps the uses already counted against it, and the new version's <code>maxUsage</code> is applied to that count: a grant with 8 counted uses re-pinned to a version with <code>maxUsage</code> 5 is refused on its next request. Uses made while no limit was pinned (no <code>maxUsage</code> and no <code>revokeOnUse</code>) are not counted, so they do not count toward a limit pinned later: a grant re-pinned from an unlimited version to <code>maxUsage</code> 5 admits 5 further uses. **Refusals** (409 <code>capability-grant-repin-refused</code>, nothing changed, the cause in <code>extensions.reason</code>): the grant was used up (<code>CONSUMED</code>) or revoked (<code>REVOKED</code>), so a re-pin never revives a grant; it is already pinned to the version (<code>SAME_VERSION</code>); the version is not a version of a live Constraint Policy of this tenant (<code>VERSION_NOT_IN_TENANT</code>); the grant belongs to an Internal Crypto Use Case, whose renewal re-pins its grants (<code>OWNED_BY_USE_CASE</code>), or to the marketplace plan, whose tier change re-pins them (<code>OWNED_BY_MARKETPLACE</code>). Every re-pin emits one signed audit event, <code>capability-grant.policy-version-replaced</code>, naming the grant, the previous and the new version, and the previous and new value of each limit and schedule field that changed. The operation is refused under a support-access impersonation session, like <code>createCapabilityGrant</code>: a re-pin can widen what the grant authorizes after the session ends. **Authorization**: requires scope <code>admin.tenant.capability-grant.repin</code>.
      Parameters:
      tenantId - (required)
      grantId - (required)
      replaceCapabilityGrantPolicyVersionRequest - (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

    • revokeCapabilityGrantCall

      public okhttp3.Call revokeCapabilityGrantCall(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull RevokeCapabilityGrantRequest revokeCapabilityGrantRequest, ApiCallback _callback) throws ApiException
      Build call for revokeCapabilityGrant
      Parameters:
      tenantId - (required)
      grantId - (required)
      revokeCapabilityGrantRequest - Carries the single required member `reason`: why the operator acts, free text, not blank, at most 1000 UTF-8 bytes (a character outside ASCII counts two to four bytes). It is recorded verbatim on the audit event of the act and signed with it, and is never interpreted by the server. (required)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object

    • revokeCapabilityGrant

      public void revokeCapabilityGrant(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull RevokeCapabilityGrantRequest revokeCapabilityGrantRequest) throws ApiException
      Revoke a Capability Grant Revokes the grant: its authorization ends at once, and the grant stays readable as revoked. A new grant at the same dimensions can be created later; it pins the current policy version and starts a fresh consumption count. The operator's `reason` is required and is recorded verbatim on the grant's audit event, signed with it. A grant composed by a live Cryptographic Exchange is revoked through that exchange instead (409).
      Parameters:
      tenantId - (required)
      grantId - (required)
      revokeCapabilityGrantRequest - Carries the single required member `reason`: why the operator acts, free text, not blank, at most 1000 UTF-8 bytes (a character outside ASCII counts two to four bytes). It is recorded verbatim on the audit event of the act and signed with it, and is never interpreted by the server. (required)
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • revokeCapabilityGrantWithHttpInfo

      public ApiResponse<Void> revokeCapabilityGrantWithHttpInfo(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull RevokeCapabilityGrantRequest revokeCapabilityGrantRequest) throws ApiException
      Revoke a Capability Grant Revokes the grant: its authorization ends at once, and the grant stays readable as revoked. A new grant at the same dimensions can be created later; it pins the current policy version and starts a fresh consumption count. The operator's `reason` is required and is recorded verbatim on the grant's audit event, signed with it. A grant composed by a live Cryptographic Exchange is revoked through that exchange instead (409).
      Parameters:
      tenantId - (required)
      grantId - (required)
      revokeCapabilityGrantRequest - Carries the single required member `reason`: why the operator acts, free text, not blank, at most 1000 UTF-8 bytes (a character outside ASCII counts two to four bytes). It is recorded verbatim on the audit event of the act and signed with it, and is never interpreted by the server. (required)
      Returns:
      ApiResponse<Void>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body

    • revokeCapabilityGrantAsync

      public okhttp3.Call revokeCapabilityGrantAsync(@Nonnull UUID tenantId, @Nonnull UUID grantId, @Nonnull RevokeCapabilityGrantRequest revokeCapabilityGrantRequest, ApiCallback<Void> _callback) throws ApiException
      Revoke a Capability Grant (asynchronously) Revokes the grant: its authorization ends at once, and the grant stays readable as revoked. A new grant at the same dimensions can be created later; it pins the current policy version and starts a fresh consumption count. The operator's `reason` is required and is recorded verbatim on the grant's audit event, signed with it. A grant composed by a live Cryptographic Exchange is revoked through that exchange instead (409).
      Parameters:
      tenantId - (required)
      grantId - (required)
      revokeCapabilityGrantRequest - Carries the single required member `reason`: why the operator acts, free text, not blank, at most 1000 UTF-8 bytes (a character outside ASCII counts two to four bytes). It is recorded verbatim on the audit event of the act and signed with it, and is never interpreted by the server. (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