Identificação de participantes

Todo participante de um documento é um usuário do Signer. Quando você cria um documento, o Signer procura um usuário que já existe para cada participante. Se não encontra, cria um usuário novo.

Esta página explica como essa busca funciona. Ela ajuda a entender, por exemplo, por que uma assinatura saiu com o nome de outra pessoa ou por que a API respondeu EmailAlreadyBeingUsed.

Configurações da instância

As configurações citadas nesta página valem para a instância inteira, e não para uma organização. Se você usa o Signer em nuvem (SaaS), peça a alteração ao suporte da Lacuna. Se a instância é sua, veja Configurações do Signer.

O que identifica uma pessoa

O Signer usa dois dados para identificar uma pessoa:

• O e-mail.
• O identificador, um documento de identidade. Por padrão, o identificador é o CPF.

O login no Signer passa por um serviço de identidade separado, o GrantID. O GrantID guarda a conta da pessoa, com e-mail e CPF. O Signer guarda uma cópia desses dados.

Modos do identificador

O modo de um identificador diz se ele é obrigatório e se duas pessoas podem ter o mesmo valor.

Modo	Obrigatório	Duas pessoas com o mesmo valor
Unique	Sim	Não
NonUnique	Sim	Sim
Nullable	Não	Sim
NullableUnique	Não	Não

O modo padrão do CPF é Unique. A configuração IdentifierModes da seção IdentifierScope define o modo de cada tipo de identificador. Por exemplo, Cpf=NullableUnique torna o CPF opcional, mas ainda único.

Como o Signer encontra o usuário

O Signer segue estes passos para cada participante, nesta ordem:

1. Se a requisição traz o id de um usuário, o Signer usa esse usuário.
2. Se a configuração DisableGrantIdIdentifierSync está ligada, o Signer procura só pelo e-mail.
3. Se o participante tem identificador, e o modo do identificador é Unique ou NullableUnique, o Signer procura pelo identificador.
4. Nos outros casos, o Signer procura pelo e-mail.
5. Se a busca não encontra ninguém, o Signer cria um usuário novo com o nome, o e-mail, o telefone e o identificador informados.

No passo 3, o Signer não procura pelo e-mail depois de uma busca sem resultado. Ele cria um usuário novo. A exceção é a instância com vários identificadores por usuário: nela, se a busca pelo identificador não encontra ninguém, o Signer procura também pelo e-mail.

Exemplo

O CPF está no modo Nullable. Você cria um documento para Ana, com o e-mail contato@empresa.com.br e o CPF dela. Esse e-mail já pertence ao usuário Bruno. Como o modo Nullable não é único, o Signer procura pelo e-mail, encontra Bruno e usa o cadastro dele. A assinatura sai com o nome e o CPF de Bruno.

Dados de um usuário que já existe

Se o Signer encontra um usuário, ele usa os dados guardados desse usuário, e não os dados da requisição:

• O nome do participante vira o nome guardado. A tela mostra o aviso O nome informado não foi utilizado, pois o usuário já está cadastrado no sistema com outro nome.
• Um identificador diferente vira o identificador guardado.
• O e-mail vira o e-mail guardado, a menos que a configuração AllowSetFlowActionEmail esteja ligada. Ela vem ligada por padrão e deixa o participante ter um e-mail só para aquele documento.

Criar um documento nunca altera o nome ou o e-mail de um usuário que já existe.

Unicidade de e-mail e CPF

O Signer não verifica se um e-mail é único. Quem faz essa verificação é o GrantID. Por isso, as regras de unicidade dependem dos dois sistemas:

Dado	No Signer	No GrantID
CPF único	Modo Unique ou NullableUnique	O dado CPF marcado como único
CPF obrigatório	Modo Unique ou NonUnique	O dado CPF marcado como obrigatório
E-mail único	Não verifica	A opção RequireUniqueEmail, ligada por padrão
Login		Por e-mail ou por CPF (UsernameType)

As configurações dos dois sistemas precisam combinar. Se você muda só o Signer, o GrantID ainda pode recusar um e-mail ou um CPF repetido.

Vários identificadores e signatários estrangeiros

A partir da versão 2.11, uma instância pode aceitar outros tipos de identificador além do CPF. Isso permite cadastrar um signatário estrangeiro que não tem CPF.

Tipo	País	Desde
Cpf	Brasil
EcuadorBceId	Equador	2.11
ParaguayCedulaIdentidad, ParaguayRuc, ParaguayPassport	Paraguai	2.11
Passport	Qualquer país	2.20.0
Ssn, Itin, Ein	Estados Unidos	3.0.0

Estas configurações da seção IdentifierScope controlam o recurso:

• EnableMultipleIdentifiersPerUser: liga o recurso. Um usuário pode ter, por exemplo, um CPF e um passaporte.
• AllowedIdentifierTypes: os tipos aceitos na instância.
• DefaultIdentifierType: o tipo usado quando a requisição não informa um tipo.
• IdentifierModes: o modo de cada tipo, como Cpf=Nullable,Passport=NullableUnique.

Com o recurso ligado, observe estas regras:

• O GrantID guarda um único identificador por usuário. Por isso, o Signer só procura no GrantID pelo tipo padrão. Para os outros tipos, ele procura pelo e-mail.
• O Signer nunca usa o SSN para procurar um usuário.
• A instância não inicia se o login do GrantID é feito pelo CPF.

Para cadastrar um estrangeiro sem ligar o recurso, use para o CPF um modo que não é obrigatório, como Nullable ou NullableUnique. O participante fica sem identificador.

Para a causa e a solução de erros como EmailAlreadyBeingUsed, CpfAlreadyBeingUsed e DuplicateUser, veja Resolver erros de cadastro de participantes.

Login único (SSO)

O Signer tem um único serviço de login por instância, o GrantID. O login por uma conta externa, como a Microsoft (Microsoft Entra ID), é configurado no GrantID, e não em cada organização do Signer.

O GrantID aceita um provedor Microsoft por instância. Por isso, duas organizações da mesma instância não podem usar SSO com tenants diferentes do Microsoft Entra ID.

Em cada login, o Signer atualiza o CPF e o telefone do usuário com os dados da conta no GrantID.