import type { RpcTransport } from '@protobuf-ts/runtime-rpc';
import type { ServiceInfo } from '@protobuf-ts/runtime-rpc';
import type { GenerateExternalPartyTopologyResponse } from './party_management_service.js';
import type { GenerateExternalPartyTopologyRequest } from './party_management_service.js';
import type { UpdatePartyIdentityProviderIdResponse } from './party_management_service.js';
import type { UpdatePartyIdentityProviderIdRequest } from './party_management_service.js';
import type { UpdatePartyDetailsResponse } from './party_management_service.js';
import type { UpdatePartyDetailsRequest } from './party_management_service.js';
import type { AllocateExternalPartyResponse } from './party_management_service.js';
import type { AllocateExternalPartyRequest } from './party_management_service.js';
import type { AllocatePartyResponse } from './party_management_service.js';
import type { AllocatePartyRequest } from './party_management_service.js';
import type { ListKnownPartiesResponse } from './party_management_service.js';
import type { ListKnownPartiesRequest } from './party_management_service.js';
import type { GetPartiesResponse } from './party_management_service.js';
import type { GetPartiesRequest } from './party_management_service.js';
import type { GetParticipantIdResponse } from './party_management_service.js';
import type { GetParticipantIdRequest } from './party_management_service.js';
import type { UnaryCall } from '@protobuf-ts/runtime-rpc';
import type { RpcOptions } from '@protobuf-ts/runtime-rpc';
/**
 * This service allows inspecting the party management state of the ledger known to the participant
 * and managing the participant-local party metadata.
 *
 * The authorization rules for its RPCs are specified on the ``<RpcName>Request``
 * messages as boolean expressions over these facts:
 *
 * 1. ``HasRight(r)`` denoting whether the authenticated user has right ``r`` and
 * 2. ``IsAuthenticatedIdentityProviderAdmin(idp)`` denoting whether ``idp`` is equal to the ``identity_provider_id``
 *    of the authenticated user and the user has an IdentityProviderAdmin right.
 *
 * If `identity_provider_id` is set to an empty string, then it's effectively set to the value of access token's 'iss' field if that is provided.
 * If `identity_provider_id` remains an empty string, the default identity provider will be assumed.
 *
 * The fields of request messages (and sub-messages) are marked either as ``Optional`` or ``Required``:
 *
 * 1. ``Optional`` denoting the client may leave the field unset when sending a request.
 * 2. ``Required`` denoting the client must set the field to a non-default value when sending a request.
 *
 * A party details resource is described by the ``PartyDetails`` message,
 * A party details resource, once it has been created, can be modified using the ``UpdatePartyDetails`` RPC.
 * The only fields that can be modified are those marked as ``Modifiable``.
 *
 * @generated from protobuf service com.daml.ledger.api.v2.admin.PartyManagementService
 */
export interface IPartyManagementServiceClient {
    /**
     * Return the identifier of the participant.
     * All horizontally scaled replicas should return the same id.
     * daml-on-kv-ledger: returns an identifier supplied on command line at launch time
     * canton: returns globally unique identifier of the participant
     *
     * @generated from protobuf rpc: GetParticipantId
     */
    getParticipantId(input: GetParticipantIdRequest, options?: RpcOptions): UnaryCall<GetParticipantIdRequest, GetParticipantIdResponse>;
    /**
     * Get the party details of the given parties. Only known parties will be
     * returned in the list.
     *
     * @generated from protobuf rpc: GetParties
     */
    getParties(input: GetPartiesRequest, options?: RpcOptions): UnaryCall<GetPartiesRequest, GetPartiesResponse>;
    /**
     * List the parties known by the participant.
     * The list returned contains parties whose ledger access is facilitated by
     * the participant and the ones maintained elsewhere.
     *
     * @generated from protobuf rpc: ListKnownParties
     */
    listKnownParties(input: ListKnownPartiesRequest, options?: RpcOptions): UnaryCall<ListKnownPartiesRequest, ListKnownPartiesResponse>;
    /**
     * Allocates a new party on a ledger and adds it to the set managed by the participant.
     * Caller specifies a party identifier suggestion, the actual identifier
     * allocated might be different and is implementation specific.
     * Caller can specify party metadata that is stored locally on the participant.
     * This call may:
     *
     * - Succeed, in which case the actual allocated identifier is visible in
     *   the response.
     * - Respond with a gRPC error
     *
     * daml-on-kv-ledger: suggestion's uniqueness is checked by the validators in
     * the consensus layer and call rejected if the identifier is already present.
     * canton: completely different globally unique identifier is allocated.
     * Behind the scenes calls to an internal protocol are made. As that protocol
     * is richer than the surface protocol, the arguments take implicit values
     * The party identifier suggestion must be a valid party name. Party names are required to be non-empty US-ASCII strings built from letters, digits, space,
     * colon, minus and underscore limited to 255 chars
     *
     * @generated from protobuf rpc: AllocateParty
     */
    allocateParty(input: AllocatePartyRequest, options?: RpcOptions): UnaryCall<AllocatePartyRequest, AllocatePartyResponse>;
    /**
     * Alpha 3.3: Endpoint to allocate a new external party on a synchronizer
     *
     * Expected to be stable in 3.5
     *
     * The external party must be hosted (at least) on this node with either confirmation or observation permissions
     * It can optionally be hosted on other nodes (then called a multi-hosted party).
     * If hosted on additional nodes, explicit authorization of the hosting relationship must be performed on those nodes
     * before the party can be used.
     * Decentralized namespaces are supported but must be provided fully authorized by their owners.
     * The individual owner namespace transactions can be submitted in the same call (fully authorized as well).
     * In the simple case of a non-multi hosted, non-decentralized party, the RPC will return once the party is
     * effectively allocated and ready to use, similarly to the AllocateParty behavior.
     * For more complex scenarios applications may need to query the party status explicitly (only through the admin API as of now).
     *
     * @generated from protobuf rpc: AllocateExternalParty
     */
    allocateExternalParty(input: AllocateExternalPartyRequest, options?: RpcOptions): UnaryCall<AllocateExternalPartyRequest, AllocateExternalPartyResponse>;
    /**
     * Update selected modifiable participant-local attributes of a party details resource.
     * Can update the participant's local information for local parties.
     *
     * @generated from protobuf rpc: UpdatePartyDetails
     */
    updatePartyDetails(input: UpdatePartyDetailsRequest, options?: RpcOptions): UnaryCall<UpdatePartyDetailsRequest, UpdatePartyDetailsResponse>;
    /**
     * Update the assignment of a party from one IDP to another.
     *
     * @generated from protobuf rpc: UpdatePartyIdentityProviderId
     */
    updatePartyIdentityProviderId(input: UpdatePartyIdentityProviderIdRequest, options?: RpcOptions): UnaryCall<UpdatePartyIdentityProviderIdRequest, UpdatePartyIdentityProviderIdResponse>;
    /**
     * Alpha 3.3: Convenience endpoint to generate topology transactions for external signing
     *
     * Expected to be stable in 3.5
     *
     * You may use this endpoint to generate the common external topology transactions
     * which can be signed externally and uploaded as part of the allocate party process
     *
     * Note that this request will create a normal namespace using the same key for the
     * identity as for signing. More elaborate schemes such as multi-signature
     * or decentralized parties require you to construct the topology transactions yourself.
     *
     * @generated from protobuf rpc: GenerateExternalPartyTopology
     */
    generateExternalPartyTopology(input: GenerateExternalPartyTopologyRequest, options?: RpcOptions): UnaryCall<GenerateExternalPartyTopologyRequest, GenerateExternalPartyTopologyResponse>;
}
/**
 * This service allows inspecting the party management state of the ledger known to the participant
 * and managing the participant-local party metadata.
 *
 * The authorization rules for its RPCs are specified on the ``<RpcName>Request``
 * messages as boolean expressions over these facts:
 *
 * 1. ``HasRight(r)`` denoting whether the authenticated user has right ``r`` and
 * 2. ``IsAuthenticatedIdentityProviderAdmin(idp)`` denoting whether ``idp`` is equal to the ``identity_provider_id``
 *    of the authenticated user and the user has an IdentityProviderAdmin right.
 *
 * If `identity_provider_id` is set to an empty string, then it's effectively set to the value of access token's 'iss' field if that is provided.
 * If `identity_provider_id` remains an empty string, the default identity provider will be assumed.
 *
 * The fields of request messages (and sub-messages) are marked either as ``Optional`` or ``Required``:
 *
 * 1. ``Optional`` denoting the client may leave the field unset when sending a request.
 * 2. ``Required`` denoting the client must set the field to a non-default value when sending a request.
 *
 * A party details resource is described by the ``PartyDetails`` message,
 * A party details resource, once it has been created, can be modified using the ``UpdatePartyDetails`` RPC.
 * The only fields that can be modified are those marked as ``Modifiable``.
 *
 * @generated from protobuf service com.daml.ledger.api.v2.admin.PartyManagementService
 */
export declare class PartyManagementServiceClient implements IPartyManagementServiceClient, ServiceInfo {
    private readonly _transport;
    typeName: string;
    methods: import("@protobuf-ts/runtime-rpc").MethodInfo<any, any>[];
    options: {
        [extensionName: string]: import("@protobuf-ts/runtime").JsonValue;
    };
    constructor(_transport: RpcTransport);
    /**
     * Return the identifier of the participant.
     * All horizontally scaled replicas should return the same id.
     * daml-on-kv-ledger: returns an identifier supplied on command line at launch time
     * canton: returns globally unique identifier of the participant
     *
     * @generated from protobuf rpc: GetParticipantId
     */
    getParticipantId(input: GetParticipantIdRequest, options?: RpcOptions): UnaryCall<GetParticipantIdRequest, GetParticipantIdResponse>;
    /**
     * Get the party details of the given parties. Only known parties will be
     * returned in the list.
     *
     * @generated from protobuf rpc: GetParties
     */
    getParties(input: GetPartiesRequest, options?: RpcOptions): UnaryCall<GetPartiesRequest, GetPartiesResponse>;
    /**
     * List the parties known by the participant.
     * The list returned contains parties whose ledger access is facilitated by
     * the participant and the ones maintained elsewhere.
     *
     * @generated from protobuf rpc: ListKnownParties
     */
    listKnownParties(input: ListKnownPartiesRequest, options?: RpcOptions): UnaryCall<ListKnownPartiesRequest, ListKnownPartiesResponse>;
    /**
     * Allocates a new party on a ledger and adds it to the set managed by the participant.
     * Caller specifies a party identifier suggestion, the actual identifier
     * allocated might be different and is implementation specific.
     * Caller can specify party metadata that is stored locally on the participant.
     * This call may:
     *
     * - Succeed, in which case the actual allocated identifier is visible in
     *   the response.
     * - Respond with a gRPC error
     *
     * daml-on-kv-ledger: suggestion's uniqueness is checked by the validators in
     * the consensus layer and call rejected if the identifier is already present.
     * canton: completely different globally unique identifier is allocated.
     * Behind the scenes calls to an internal protocol are made. As that protocol
     * is richer than the surface protocol, the arguments take implicit values
     * The party identifier suggestion must be a valid party name. Party names are required to be non-empty US-ASCII strings built from letters, digits, space,
     * colon, minus and underscore limited to 255 chars
     *
     * @generated from protobuf rpc: AllocateParty
     */
    allocateParty(input: AllocatePartyRequest, options?: RpcOptions): UnaryCall<AllocatePartyRequest, AllocatePartyResponse>;
    /**
     * Alpha 3.3: Endpoint to allocate a new external party on a synchronizer
     *
     * Expected to be stable in 3.5
     *
     * The external party must be hosted (at least) on this node with either confirmation or observation permissions
     * It can optionally be hosted on other nodes (then called a multi-hosted party).
     * If hosted on additional nodes, explicit authorization of the hosting relationship must be performed on those nodes
     * before the party can be used.
     * Decentralized namespaces are supported but must be provided fully authorized by their owners.
     * The individual owner namespace transactions can be submitted in the same call (fully authorized as well).
     * In the simple case of a non-multi hosted, non-decentralized party, the RPC will return once the party is
     * effectively allocated and ready to use, similarly to the AllocateParty behavior.
     * For more complex scenarios applications may need to query the party status explicitly (only through the admin API as of now).
     *
     * @generated from protobuf rpc: AllocateExternalParty
     */
    allocateExternalParty(input: AllocateExternalPartyRequest, options?: RpcOptions): UnaryCall<AllocateExternalPartyRequest, AllocateExternalPartyResponse>;
    /**
     * Update selected modifiable participant-local attributes of a party details resource.
     * Can update the participant's local information for local parties.
     *
     * @generated from protobuf rpc: UpdatePartyDetails
     */
    updatePartyDetails(input: UpdatePartyDetailsRequest, options?: RpcOptions): UnaryCall<UpdatePartyDetailsRequest, UpdatePartyDetailsResponse>;
    /**
     * Update the assignment of a party from one IDP to another.
     *
     * @generated from protobuf rpc: UpdatePartyIdentityProviderId
     */
    updatePartyIdentityProviderId(input: UpdatePartyIdentityProviderIdRequest, options?: RpcOptions): UnaryCall<UpdatePartyIdentityProviderIdRequest, UpdatePartyIdentityProviderIdResponse>;
    /**
     * Alpha 3.3: Convenience endpoint to generate topology transactions for external signing
     *
     * Expected to be stable in 3.5
     *
     * You may use this endpoint to generate the common external topology transactions
     * which can be signed externally and uploaded as part of the allocate party process
     *
     * Note that this request will create a normal namespace using the same key for the
     * identity as for signing. More elaborate schemes such as multi-signature
     * or decentralized parties require you to construct the topology transactions yourself.
     *
     * @generated from protobuf rpc: GenerateExternalPartyTopology
     */
    generateExternalPartyTopology(input: GenerateExternalPartyTopologyRequest, options?: RpcOptions): UnaryCall<GenerateExternalPartyTopologyRequest, GenerateExternalPartyTopologyResponse>;
}
//# sourceMappingURL=party_management_service.client.d.ts.map