Évaluation des règles de transaction

Avant de signer une transaction, le calcul multipartite l'évalue par rapport aux règles de transaction de votre instance. Ce document décrit les règles évaluées, le cycle de vie d'une règle, ce qu'une règle peut vérifier et pourquoi une transaction est refusée.

Comment une transaction est-elle évaluée ?

Une règle de transaction est une seule instruction permit ou forbid Cedar. Lorsqu'un signataire appelle CreateTransaction, l'instance décode la transaction non signée dans Transaction.payload avec l'analyseur pour Transaction.schema et évalue chaque règle appliquée par rapport à la transaction avant d'utiliser un partage de clé. Une règle est appliquée lorsque son état est ACTIVE ou PENDING_DISABLED. Pour en savoir plus, consultez Cycle de vie des règles.

La décision suit trois règles :

  1. Refuser par défaut Une transaction n'est autorisée que si au moins une règle permit lui correspond. Sans règles appliquées, toutes les transactions sont refusées.
  2. "Forbid" l'emporte. Si une règle forbid correspond, la transaction est refusée, même si des règles permit correspondent également.
  3. Une règle dont l'évaluation échoue ne correspond pas. Par exemple, une règle qui lit un attribut de contexte facultatif que la transaction n'a pas ne peut pas être évaluée. L'instance enregistre l'erreur, ignore cette règle et prend une décision en fonction des autres règles appliquées. Cela s'applique également aux règles forbid. Par conséquent, écrivez des règles forbid qui ne peuvent pas échouer en cas d'attribut manquant. Pour obtenir un exemple, consultez le scénario 8 et le scénario 9.

Une transaction contenant plusieurs transferts, comme une transaction Solana avec plusieurs instructions de transfert, est évaluée une fois pour chaque transfert. La transaction n'est autorisée que si chaque transfert est autorisé. Si un transfert est refusé ou ne peut pas être décodé, l'ensemble de la transaction est refusé.

Chaque évaluation, qu'elle soit autorisée ou refusée, produit un enregistrement d'évaluation qui est renvoyé lors de la transaction dans Transaction.policyEvaluationRecord.

La décision détermine si l'instance peut signer la transaction sans attendre d'autres signataires :

  • PERMIT : si la requête CreateTransaction comporte déjà suffisamment d'autorisations de signataire pour répondre à la stratégie de clé du trousseau de clés, la transaction passe immédiatement à l'état SIGNING. Sinon, elle est créée dans PENDING_AUTHORIZATION et attend d'autres signataires.
  • DENY : l'instance ne signe pas automatiquement la transaction. La transaction est créée dans PENDING_AUTHORIZATION avec policyEvaluationRecord.decision défini sur DENY. Les signataires peuvent examiner l'enregistrement d'évaluation et refuser la transaction (RecordSignerDecision avec DENY) ou l'autoriser quand même (AUTHORIZE). La transaction n'est signée que si un nombre suffisant de signataires l'autorisent à respecter la stratégie de clé.

Une règle de transaction est un garde-fou pour la signature automatique, et non un blocage pour les signataires : les signataires peuvent autoriser une transaction que les règles refusent. Le PolicyEvaluationRecord d'origine reste associé à la transaction à des fins d'audit.

Cycle de vie des règles

Les règles de transaction ne peuvent pas être modifiées. TransactionPolicy n'a pas de méthode de mise à jour et son rule est immuable. Pour modifier une règle, désactivez la stratégie avec DisableTransactionPolicy et créez-en une autre avec CreateTransactionPolicy.

L'activation ou la désactivation d'une règle nécessite l'approbation d'un quorum d'auteurs de règles (utilisateurs disposant d'un rôle POLICY_AUTHOR actif dans User.roleStatuses). Chaque auteur de règle signe un TransactionPolicySigningPayload qui nomme la règle (ou, pour CreateTransactionPolicy, l'instance), l'action (ACTIVATE ou DISABLE) et rule.cedarDocument. La demande qui propose une modification compte comme la première approbation. Les autres auteurs de règles approuvent avec ApproveTransactionPolicy. Le nombre d'approbations nécessaires est indiqué dans activationInfo.requiredApprovals et deactivationInfo.requiredApprovals. Si l'instance ne nécessite qu'une seule approbation, la modification prend effet immédiatement.

Le tableau suivant décrit chaque état de règle et indique si les règles dans cet état sont appliquées :

État Signification Appliquée ?
PENDING_ACTIVE La règle a été proposée et est en attente d'approbation par les auteurs de règles. Non
ACTIVE La règle comporte activationInfo.requiredApprovals approbations. Oui
PENDING_DISABLED Un auteur de stratégie a demandé la désactivation de la stratégie, et la demande est en attente d'approbation. Oui, jusqu'à ce que la demande ait reçu deactivationInfo.requiredApprovals approbations
DISABLED La règle a été désactivée ou retirée avant de devenir active. Les règles désactivées sont conservées à des fins d'audit. Non

Une stratégie passe par ces états dans une seule direction :

  • PENDING_ACTIVE à ACTIVE : l'activation a reçu suffisamment d'approbations.
  • PENDING_ACTIVE à DISABLED : un auteur de stratégie retire la stratégie avec DisableTransactionPolicy avant qu'elle ne devienne active.
  • ACTIVE à PENDING_DISABLED : un auteur de stratégie appelle DisableTransactionPolicy.
  • PENDING_DISABLED à DISABLED : la demande de désactivation a reçu suffisamment d'approbations.

Une stratégie passe par chaque état d'attente au maximum une fois. Une règle désactivée ne peut pas être réactivée. Créez-en une autre à la place.

Pour savoir qui peut appeler ces méthodes, consultez Rôles utilisateur.

Version de l'ensemble de règles

L'ensemble de règles est l'ensemble des règles appliquées (ACTIVE ou PENDING_DISABLED) à un moment donné. Chaque fois qu'une activation ou une désactivation est terminée, l'instance attribue à cette transition le numéro suivant dans un compteur de l'instance et l'enregistre dans activationInfo.transitionSequence ou deactivationInfo.transitionSequence. Ce numéro correspond à la version de l'ensemble de règles produite par la transition.

Le tableau suivant montre comment la version de l'ensemble de règles change au cours d'une séquence d'événements :

Événement Séquence de transition Règles appliquées
La règle A est activée. A: activationInfo.transitionSequence = 1 A
La règle B est activée. B: activationInfo.transitionSequence = 2 A, B
La règle C est proposée (PENDING_ACTIVE), puis retirée. Aucun A, B
Une demande de désactivation de la règle A est approuvée. R : deactivationInfo.transitionSequence = 3 B

Le retrait d'une règle PENDING_ACTIVE ne modifie jamais l'ensemble des règles appliquées. Il n'entraîne donc aucune séquence de transition et ne modifie pas la version de l'ensemble de règles. Lorsqu'une transition est en attente d'approbation, son champ transitionSequence n'est pas défini.

Chaque évaluation lit les règles, les KeyLists et les clés à partir de la transaction createTime, et enregistre la séquence de transition terminée la plus élevée à ce moment-là dans policyEvaluationRecord.policySetVersion. Si deux évaluations ont la même version d'ensemble de règles, elles ont utilisé les mêmes règles.

La requête Cedar

Une requête Cedar comporte un principal, une action, une ressource et un contexte. Exemple :

permit (
  principal == User::"alice@example.com",
  action == Action::"buy_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.principal_keyring == "institutional-treasury" &&
  context has fiat_amount && context.fiat_amount <= 10000
};

Comment un utilisateur est mappé au principal Cedar

Le compte principal est l'initiateur de la transaction : l'utilisateur dont l'principal correspond à l'identité authentifiée de l'appelant de CreateTransaction. Cet utilisateur doit disposer d'un rôle SIGNER actif. Dans Cedar, le compte principal est une entité User dont l'ID est le champ principal de l'utilisateur, par exemple User::"alice@example.com".

L'instance ne transmet aucune donnée d'entité à Cedar. Une entité User n'a ni attributs, ni parents. Par conséquent :

  • principal == User::"alice@example.com" correspond aux transactions initiées par Alice.
  • principal in Team::"treasury" ne correspond jamais. Pour limiter les utilisateurs autorisés à signer avec une clé, utilisez la stratégie de clé du trousseau de clés. Pour limiter la portée d'une règle à un groupe de clés, cochez context.principal_keyring.
  • Une règle qui lit un attribut de principal, tel que principal.team, ne parvient pas à s'évaluer.

L'principal d'un utilisateur ne peut pas être modifié. Par conséquent, une règle qui nomme un compte principal fait toujours référence à la même identité.

Action et ressource

  • action : valeur de Transaction.action dans la requête CreateTransaction, formatée en tant qu'entité Cedar Action. CreateTransaction accepte les actions suivantes :

    Action Utilisation
    Action::"buy_transaction" Transaction qui acquiert un élément.
    Action::"sell_transaction" Transaction qui supprime un élément.
    Action::"internal_transfer_transaction" Transfert d'un élément, tel qu'un paiement ou un balayage entre des clés.

    L'initiateur choisit l'action. Le calcul multipartite ne la déduit pas de la charge utile. Une règle peut correspondre à une action (action == Action::"buy_transaction"), à une liste d'actions (action in [Action::"buy_transaction", Action::"sell_transaction"]) ou laisser action sans contrainte pour correspondre à chaque action.

  • resource : toujours Resource::"transaction_management" pour les évaluations de transactions. Une règle peut vérifier resource == Resource::"transaction_management" ou laisser resource sans contrainte.

Attributs de contexte

Le contexte contient les attributs vérifiés par les règles. Elles proviennent de deux sources :

  • La charge utile de la transaction et la clé de signature. L'instance décode Transaction.payload et ajoute les ID de la clé de signature et de son trousseau de clés. Ces attributs sont principal_keyring, principal_key, blockchain, schema, secondary_key, amount_token_scaled, token_symbol, contract_address, chain_id, max_fee_atomic, payload et time_stamp. Pour obtenir le tableau complet et le comportement de chaque blockchain, consultez Règles de transaction d'écriture.
  • Le champ metadata de la transaction,que l'initiateur définit dans CreateTransaction.

Le tableau suivant décrit les attributs de métadonnées :

Champ Transaction.metadata Attribut Cedar Type Cedar Valeur
fiatAmount context.fiat_amount Long Valeur de la transaction en dollars américains (google.type.Money). currencyCode doit être USD, units doit être supérieur ou égal à zéro, et nanos doit être 0.
validity context.validity Long Durée de validité de la transaction (google.protobuf.Duration), en secondes entières. La valeur doit être supérieure à 0 seconde, sans fraction de seconde.
principalValue1 context.principal_value1 String Toute valeur que vous définissez, jusqu'à 256 caractères (par exemple, un trading desk ou un centre de coûts).
principalValue2 context.principal_value2 String Toute valeur que vous définissez, jusqu'à 256 caractères, par exemple un ID de ticket ou de contrepartie interne.

Les règles suivantes s'appliquent aux métadonnées :

  • Les champs non définis ne sont pas inclus dans le contexte. Si une transaction n'a pas de fiatAmount, context.fiat_amount n'existe pas et une règle qui la lit ne peut pas être évaluée. Recherchez d'abord l'attribut avec has, comme dans context has fiat_amount && context.fiat_amount <= 10000.
  • Si les métadonnées ne sont pas valides, la requête échoue. Si un champ ne respecte pas les règles du tableau précédent, par exemple un fiatAmount dans EUR ou avec un nanos non nul, un validity de 0 seconde ou un principalValue1 de plus de 256 caractères, CreateTransaction échoue avec INVALID_ARGUMENT et aucune règle n'est évaluée.
  • L'instance ne vérifie pas les métadonnées par rapport à la transaction. fiatAmount est la valeur de la transaction indiquée par l'initiateur. Les autres signataires voient les métadonnées dans Transaction.metadata et policyEvaluationRecord.evaluationContext avant de les autoriser. Pour limiter les montants on-chain indépendamment des métadonnées, vérifiez context.amount_token_scaled et context.contract_address.
  • Les métadonnées ne peuvent pas être modifiées une fois la transaction créée.

Trousseaux

Un KeyRing regroupe des clés. Le contexte de chaque transaction comporte principal_keyring et principal_key. Une règle peut donc s'appliquer à chaque clé d'un trousseau, y compris les clés créées ultérieurement, et un trousseau peut être une entrée dans une KeyList. Pour en savoir plus et obtenir un exemple de règle, consultez KeyRings.

KeyLists

Une KeyList est une liste nommée d'adresses de blockchain auxquelles les règles peuvent faire référence, par exemple en tant que liste d'autorisation de destinations. Chaque entrée est l'une des suivantes :

  • Une entrée manuelle (manualEntry) : une adresse que l'instance ne gère pas, avec des champs source et reason facultatifs.
  • Une clé de l'instance (key) : correspond aux adresses de la clé.
  • Un trousseau de clés dans l'instance (keyRing) : correspond aux adresses de chaque clé active du trousseau de clés, y compris les clés créées après l'ajout de l'entrée.

Les KeyLists peuvent changer après l'approbation d'une règle. Lorsque vous ajoutez ou supprimez une entrée avec AddKeyListEntries ou RemoveKeyListEntries, chaque stratégie qui fait référence à la KeyList utilise les nouvelles entrées de l'évaluation suivante, sans nouvelles approbations de l'auteur de la stratégie. Une KeyList ne peut pas être supprimée avec DeleteKeyList tant qu'une règle PENDING_ACTIVE, ACTIVE ou PENDING_DISABLED y fait référence.

KeyLists dans le contexte Cedar

Au moment de l'évaluation, l'instance développe chaque KeyList en une Set plate d'adresses de blockchain String : les entrées manuelles, ainsi que les adresses dérivées de chaque entrée de clé et de KeyRing. Chaque ensemble est transmis à Cedar en tant que context.key_lists["<var>KEY_LIST_ID</var>"], où KEY_LIST_ID est l'ID {keyList} dans le nom de ressource de la KeyList, par exemple trusted-destinations pour projects/my-project/locations/us-central1/instances/my-instance/keyLists/trusted-destinations.

Une règle teste l'appartenance avec l'opérateur Cedar contains par rapport à l'adresse de destination décodée, context.secondary_key. Par exemple, pour n'autoriser les transferts que vers les adresses de la KeyList trusted-destinations :

// Assuming you created a KeyList with ID "trusted-destinations":
permit (principal, action, resource)
when { context.key_lists["trusted-destinations"].contains(context.secondary_key) };

Pour refuser les transferts vers n'importe quelle adresse de la KeyList blocked-addresses :

// Assuming you created a KeyList with ID "blocked-addresses":
forbid (principal, action, resource)
when { context.key_lists["blocked-addresses"].contains(context.secondary_key) };

Tenez bien compte des éléments suivants :

  • Utilisez la syntaxe entre crochets, et non la syntaxe avec un point, pour l'ID KeyList. La syntaxe par point de Cedar (context.key_lists.trusted-destinations) ne parvient pas à analyser l'ID lorsqu'il contient un trait d'union, que Cedar interprète comme une soustraction, ou lorsqu'il commence par un chiffre, comme un UUID généré par le serveur. La syntaxe entre crochets, context.key_lists["<var>KEY_LIST_ID</var>"], fonctionne pour tous les ID.
  • key_lists est toujours présent, et une règle peut y lire directement une KeyList. CreateTransactionPolicy vérifie que chaque KeyList à laquelle la règle fait référence existe, et DeleteKeyList refuse de supprimer une KeyList tant qu'une règle y fait référence. N'utilisez context.key_lists has "<var>KEY_LIST_ID</var>" que lorsqu'une règle fait référence à une KeyList qui n'existe peut-être pas encore.
  • Les adresses sont comparées en tant que chaînes. secondary_key utilise le format décrit dans Écrire des règles de stratégie de transaction pour chaque blockchain, par exemple le format de somme de contrôle EIP-55 mixte pour Ethereum. Ajoutez des entrées manuelles au même format.
  • Le secondary_key d'un transfert de jeton Solana est le compte de jeton de destination, et non le portefeuille du propriétaire. Pour autoriser un portefeuille, ajoutez son compte de jeton pour chaque mint que vous autorisez.

Chaque évaluation résout l'appartenance à la KeyList à partir de la valeur createTime de la transaction, en même temps que les règles, et enregistre le résultat dans policyEvaluationRecord.keyListMemberships : la KeyList, l'adresse testée, s'il s'agissait d'un membre et l'entrée correspondante.

Étant donné qu'une KeyList modifie ce qu'une règle autorise, limitez les personnes autorisées à la modifier. Les méthodes KeyList nécessitent roles/mpc.admin. Pour en savoir plus, consultez Autorisations IAM.

Motifs de refus

Lorsque policyEvaluationRecord.decision est défini sur DENY, policyEvaluationRecord.denyReason indique pourquoi. Le tableau suivant décrit chaque motif de refus :

Motif du refus Quand Déterminer les règles
FORBID_RULE_MATCHED Au moins une règle forbid appliquée correspond. Les forbid règles correspondantes.
NO_PERMIT_RULE_MATCHED La charge utile a été décodée, aucune règle forbid ne correspond, aucune règle n'a échoué à l'évaluation et aucune règle permit ne correspond. Aucun
EVALUATION_ERROR Aucune règle permit ou forbid ne correspond, et l'évaluation d'au moins une règle a échoué, par exemple parce qu'elle lit un attribut facultatif qui n'est pas dans le contexte. Aucune. evaluationErrors répertorie les erreurs.
UNRECOGNIZED_PAYLOAD L'instance n'a pas pu décoder Transaction.payload ni le projeter dans un contexte, par exemple en raison d'octets incorrects, d'une instruction ou d'une opération de contrat non compatibles, ou d'une transaction Bitcoin avec plusieurs destinataires. Aucune règle n'est évaluée. Aucune. evaluationErrors liste l'erreur de l'analyseur.

Les motifs sont déterminés dans l'ordre suivant :

  1. Si la charge utile ne peut pas être décodée ou projetée dans un contexte, la décision est DENY avec UNRECOGNIZED_PAYLOAD.
  2. Sinon, toutes les règles appliquées sont évaluées. Si une règle forbid correspond, la décision est DENY avec FORBID_RULE_MATCHED, même si des règles permit correspondent également ou si d'autres règles n'ont pas pu être évaluées.
  3. Sinon, si au moins une règle permit correspond, la décision est PERMIT. Les erreurs provenant d'autres règles sont toujours enregistrées dans evaluationErrors.
  4. Sinon, la décision est DENY avec EVALUATION_ERROR si l'évaluation d'une règle a échoué, ou NO_PERMIT_RULE_MATCHED si toutes les règles ont été évaluées sans correspondance.

Les erreurs sont enregistrées même lorsque la décision est PERMIT. Vérifiez donc l'enregistrement d'évaluation pour les règles qui ne correspondent jamais, car elles échouent toujours.

Scénarios

Dans les scénarios 1 à 9, Alice (User::"alice@example.com") crée un transfert Ethereum valide avec action défini sur Action::"internal_transfer_transaction" et ces métadonnées, sauf indication contraire dans le scénario :

"metadata": {
  "fiatAmount": {"currencyCode": "USD", "units": "5000"},
  "principalValue1": "treasury-desk"
}

La transaction n'a pas de validity ni de principalValue2.

Le tableau suivant récapitule chaque scénario :

Scénario Règles appliquées ou charge utile Décision Motif du refus
1 Aucun DENY NO_PERMIT_RULE_MATCHED
2 Un permit correspondant PERMIT
3 Un permit ne correspond pas DENY NO_PERMIT_RULE_MATCHED
4 Deux permit, une correspondance PERMIT
5 Un permit et un forbid qui correspondent tous deux DENY FORBID_RULE_MATCHED
6 Un permit qui lit un attribut manquant DENY EVALUATION_ERROR
7 Le même permit, avec has DENY NO_PERMIT_RULE_MATCHED
8 Un forbid qui lit un attribut manquant et un permit qui correspond PERMIT
9 Un forbid qui nécessite un attribut DENY FORBID_RULE_MATCHED
10 Une charge utile qui ne peut pas être décodée DENY UNRECOGNIZED_PAYLOAD

Scénario 1 : Aucune règle appliquée

L'instance ne comporte aucune règle ACTIVE ni PENDING_DISABLED.

Décision : DENY, NO_PERMIT_RULE_MATCHED. Sans règle permit correspondante, toutes les transactions sont refusées. Dans une nouvelle instance, aucune transaction n'est signée automatiquement tant que les auteurs de règles n'ont pas activé une règle permit. Les signataires doivent autoriser chaque transaction.

Scénario 2 : Une seule autorisation correspondante

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Décision : PERMIT. Le montant, 5 000, est inférieur ou égal à 10 000. determiningPolicyIds liste cette règle.

Scénario 3 : Une autorisation qui ne correspond pas

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 1000 };

Décision : DENY, NO_PERMIT_RULE_MATCHED. Le montant, 5 000, est supérieur à 1 000, et aucune autre règle n'autorise la transaction.

Scénario 4 : Deux permis, un seul correspond

Règle A :

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 1000 };

Règle B :

permit (
  principal == User::"alice@example.com",
  action == Action::"internal_transfer_transaction",
  resource == Resource::"transaction_management"
)
when {
  context has fiat_amount && context.fiat_amount <= 25000 &&
  context has principal_value1 && context.principal_value1 == "treasury-desk"
};

Décision : PERMIT. La règle A ne correspond pas, mais la règle B correspond. Une seule règle permit correspondante suffit. determiningPolicyIds ne liste que la règle B.

Scénario 5 : Une interdiction remplace une autorisation

Règle A :

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Règle B :

forbid (principal, action, resource)
when { context has principal_value1 && context.principal_value1 == "treasury-desk" };

Décision : DENY, FORBID_RULE_MATCHED. Les deux règles correspondent, et forbid l'emporte. determiningPolicyIds ne liste que la règle B.

Scénario 6 : Une autorisation lit un attribut manquant

permit (principal, action, resource)
when { context.validity <= 3600 };

Décision : DENY, EVALUATION_ERROR. La transaction n'a pas de validity, donc context.validity n'existe pas et la règle ne peut pas être évaluée. Aucune autre règle n'autorise la transaction. evaluationErrors liste l'erreur.

Scénario 7 : Même autorisation, avec "has"

permit (principal, action, resource)
when { context has validity && context.validity <= 3600 };

Décision : DENY, NO_PERMIT_RULE_MATCHED. context has validity est défini sur "false". Par conséquent, la règle renvoie la valeur "false" au lieu d'échouer. La transaction est toujours refusée, mais la raison indique que la règle a été évaluée et qu'elle ne correspond pas.

Scénario 8 : Une interdiction lit un attribut manquant

Règle A :

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Règle B :

forbid (principal, action, resource)
when { context.principal_value2 == "sanctioned-counterparty" };

Décision : PERMIT. La transaction n'a pas de principalValue2. Par conséquent, la règle B ne peut pas être évaluée et est ignorée. La règle A correspond. determiningPolicyIds liste la règle A et evaluationErrors liste l'erreur de la règle B.

Scénario 9 : Interdiction nécessitant un attribut

La règle A est la règle permit du scénario 8. Règle B :

forbid (principal, action, resource)
unless { context has fiat_amount };

Décision : PERMIT pour la transaction dans ces scénarios, qui a un fiatAmount. Si Alice omet fiatAmount, la décision est DENY, FORBID_RULE_MATCHED: context has fiat_amount est faux, de sorte que la règle forbid correspond. L'évaluation de cette règle ne peut pas échouer, car elle n'utilise que has.

Pour combiner un attribut obligatoire avec une vérification de sa valeur dans une règle forbid, vérifiez d'abord l'attribut :

forbid (principal, action, resource)
unless { context has fiat_amount && context.fiat_amount <= 10000 };

Scénario 10 : Une charge utile ne peut pas être décodée

Alice crée une transaction dont le payload ne peut pas être décodé par l'analyseur pour Transaction.schema, par exemple des octets RLP tronqués, une PSBT Bitcoin avec plusieurs destinataires ou une transaction Solana avec une instruction non compatible.

Décision : DENY, UNRECOGNIZED_PAYLOAD. Aucune règle n'est évaluée. evaluationErrors liste l'erreur de l'analyseur et determiningPolicyIds est vide.

Enregistrement d'évaluation

Chaque évaluation produit un PolicyEvaluationRecord qui ne peut pas être modifié. Il est renvoyé dans Transaction.policyEvaluationRecord et comporte les champs suivants :

Champ Valeur
decision PERMIT ou DENY.
denyReason L'un des motifs de refus. Non défini lorsque la décision est PERMIT.
determiningPolicyIds Sur PERMIT, les ID des règles permit qui correspondent. Sur FORBID_RULE_MATCHED, les ID des règles forbid qui correspondent. Sinon, vide.
evaluationErrors Erreurs des stratégies dont l'évaluation a échoué ou erreur de l'analyseur lorsque denyReason est UNRECOGNIZED_PAYLOAD.
evaluationContext Contexte Cedar par rapport auquel les règles ont été évaluées, sous la forme d'un google.protobuf.Struct. Les entiers 64 bits sont stockés sous forme de chaînes décimales pour conserver leur précision.
policySetVersion La version de l'ensemble de règles utilisée pour l'évaluation.
keyListMemberships Appartenances KeyList résolues lors de l'évaluation.
intentDigest Condensé encodé en hexadécimal en minuscules de la charge utile de la transaction qui a été évaluée. Le hachage dépend du schéma de la charge utile : Keccak-256 de la transaction pour ETHEREUM_TX_V2, le sighash de la première entrée pour BITCOIN_TX_V2, SHA-256 du message non signé pour SOLANA_TX_V1 et le condensé de signature EIP-712, keccak256(0x1901 ++ domainSeparator ++ hashStruct(message)), pour EIP712_TYPED_DATA_V1.
evaluationTime Date et heure d'exécution de l'évaluation.