Organization
Signature Request Invite
Signature Request
Witness
Organization Link
Organization Member
Price Oracle
- About Price Oracle
- GETGet Median MXN/USD
- GETList Median MXN/USD
- GETGet Daily MXN/USD
- GETList Daily MXN/USD
- GETGet Weekly MXN/USD
- GETList Weekly MXN/USD
- GETGet Monthly MXN/USD
- GETList Monthly MXN/USD
- GETGet Median USDC/USD
- GETList Median USDC/USD
- GETGet Daily USDC/USD
- GETList Daily USD/USDC
- GETGet Weekly USDC/USD
- GETList Weekly USDC/USD
- GETGet Monthly USDC/USD
- GETList Monthly USDC/USD
- GETGet Median USDC/MXN
- GETList Median USDC/MXN
- GETGet Daily USDC/MXN
- GETList Daily USDC/MXN
- GETGet Weekly USDC/MXN
- GETList Weekly USDC/MXN
- GETGet Monthly USDC/MXN
- GETList Monthly USDC/MXN
Signature Request Invite Definition
A signature request invite belongs to a signature request and is used to invite a subject to sign the request.
A signature request invite is an invite to sign a signature request. It links a signature request to a subject and it stores its corresponding signature and the link to the certificate that the signature belongs to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
API is enabled for the organization.
The amount of grouped NOM151 certificates available to the organization.
The amount of NOM151 certificates available to the organization.
Policies of the Organization.
Defines the policies for signatureRequests.
Type of conservation strategy to use by default at signature request readiness (ie. when draft is false).
NOM151, MERKLEIZED, WITNESS_CO Witness that attest the content using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
API is enabled for the organization.
The amount of grouped NOM151 certificates available to the organization.
The amount of NOM151 certificates available to the organization.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
Address of the initial claiming subject.
The chain ID where the claim is authorized.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The raw content.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
Policies of the Organization.
Witness that attest the content using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
Combined merkleized conservation strategy.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Invites to sign the content.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
The transaction chain ID.
The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 Witness conservation strategy.
The timestamp issued by the provider.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
Combined merkleized conservation strategy.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Invites to sign the content.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The raw content.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
Policies of the Organization.
Witness that attest the content using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
Combined merkleized conservation strategy.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Invites to sign the content.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
The subject this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The hash of the issuer's certificate.
The name of the certificate authority.
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
AWS S3 URI path to the issuer certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Email address of the issuer.
Street address of the issuer.
Postal code of the issuer.
"Country" of the issuer.
"Entidad Federativa" of the issuer.
"Municipio/Delegación" of the issuer.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
Address of the initial claiming subject.
The chain ID where the claim is authorized.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
The transaction chain ID.
The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 Witness conservation strategy.
The timestamp issued by the provider.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
The subject this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The hash of the issuer's certificate.
The name of the certificate authority.
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
AWS S3 URI path to the issuer certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Email address of the issuer.
Street address of the issuer.
Postal code of the issuer.
"Country" of the issuer.
"Entidad Federativa" of the issuer.
"Municipio/Delegación" of the issuer.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The raw content.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
Policies of the Organization.
Witness that attest the content using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
Combined merkleized conservation strategy.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Invites to sign the content.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
The subject this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The hash of the issuer's certificate.
The name of the certificate authority.
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
AWS S3 URI path to the issuer certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Email address of the issuer.
Street address of the issuer.
Postal code of the issuer.
"Country" of the issuer.
"Entidad Federativa" of the issuer.
"Municipio/Delegación" of the issuer.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
Address of the initial claiming subject.
The chain ID where the claim is authorized.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
The transaction chain ID.
The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 Witness conservation strategy.
The timestamp issued by the provider.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
The BigInt scalar type represents non-fractional signed whole numeric values.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
The BigInt scalar type represents non-fractional signed whole numeric values.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The hash of the issuer's certificate.
The name of the certificate authority.
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
AWS S3 URI path to the issuer certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Email address of the issuer.
Street address of the issuer.
Postal code of the issuer.
"Country" of the issuer.
"Entidad Federativa" of the issuer.
"Municipio/Delegación" of the issuer.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The hash of the issuer's certificate.
The name of the certificate authority.
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
AWS S3 URI path to the issuer certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Email address of the issuer.
Street address of the issuer.
Postal code of the issuer.
"Country" of the issuer.
"Entidad Federativa" of the issuer.
"Municipio/Delegación" of the issuer.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
Witness that attest the content using a merkle proof
Invites to sign the content.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
The subject this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
Combined merkleized conservation strategy.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
API is enabled for the organization.
The amount of grouped NOM151 certificates available to the organization.
The amount of NOM151 certificates available to the organization.
Policies of the Organization.
Defines the policies for signatureRequests.
Type of conservation strategy to use by default at signature request readiness (ie. when draft is false).
NOM151, MERKLEIZED, WITNESS_CO A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The hash of the issuer's certificate.
The name of the certificate authority.
The issuer's certificate public key. This is the public key that identifies messages the issuer has signed a certificate for a subject.
AWS S3 URI path to the issuer certificate's PEM data.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC of the issuer.
Name of the organization or company. "Razón Social" in Spanish.
Name of the unit within the organization. "Unidad Organizacional" in Spanish.
Email address of the issuer.
Street address of the issuer.
Postal code of the issuer.
"Country" of the issuer.
"Entidad Federativa" of the issuer.
"Municipio/Delegación" of the issuer.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Invite for the subject to sign Plumaa own terms and conditions.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
Witness that attest the content using a merkle proof
Invites to sign the content.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
The subject this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The certificate's serial number, as a hexadecimal string. This is a unique identifier for the certificate, and is assigned by the issuer.
The certificate's issuer. This is the entity that issued the certificate, and is a Certificate Authority certified by Banxico.
The earliest date at which the certificate is valid.
The latest date at which the certificate is valid.
The certificate's subject. This is the entity that the certificate is attesting to, and is typically a person or organization ("persona fÃsica o moral" in spanish).
The certificate's public key. This is the public key that identifies messages signed by its corresponding private key.
The version of the X.509 standard that the certificate conforms to.
SHA256 message digest of the issuer's certificate.
AWS S3 URI path to the certificate's PEM data.
Whether the certificate has been revoked by the issuer.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
Combined merkleized conservation strategy.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
The push notification token associated with the certificate. Used for sending notifications to the user.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
Address of the initial claiming subject.
The chain ID where the claim is authorized.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The raw content.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The name of the Organization. This is the name that will be displayed to users when interacting with signature requests from this organization.
The logo of the Organization. This is the logo that will be displayed to users when interacting with signature requests from this organization.
Email address of the organization. Updates and notifications will be sent to this address, as well as the billing information.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Quotas of the Organization.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
API is enabled for the organization.
The amount of grouped NOM151 certificates available to the organization.
The amount of NOM151 certificates available to the organization.
Witness that attest the content using a merkle proof
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
Address of the initial claiming subject.
The chain ID where the claim is authorized.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
The transaction chain ID.
The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 Witness conservation strategy.
The timestamp issued by the provider.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Invites to sign the content.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The signature request this invite is linked to.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Whether the document is a draft or not. A draft signature request won't allow invites to sign and will skip processing notifications.
Whether the document is finalized or not. A finalized request won't allow new invites and won't process any new notifications.
Custom name for the signature request.
The content data to be signed.
Key for sharing the sharing the signature request. Can be used to access the signature request without authentication.
The organization requesting the signature.
Witness that attest the content using a merkle proof
Invites to sign the content.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
The subject this invite is linked to.
The status of the signature request invite.
PENDING, SIGNED, WITNESSED, REJECTED A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The certificate this invite was signed with.
The signature from the certificate as a hexadecimal string.
The OCSP response from checking the certificate against the CA. ASN1 encoded as a hexadecimal string.
Witness that attest the signature using a merkle proof
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.
Amount of invites that have signed the content.
Amount of invites that have not signed the content.
Amount of invites that have rejected the content.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Date when the signature request was rejected. Only present if rejected.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
The transaction chain ID.
The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 Witness conservation strategy.
The timestamp issued by the provider.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
The BigInt scalar type represents non-fractional signed whole numeric values.
A subject is a person or an organization ("persona fÃsica o moral" in Spanish) identified by a certificate.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
The BigInt scalar type represents non-fractional signed whole numeric values.
A witness is an entity representing a proof that a document existed at the time. It is used to comply with the law requirement of data conservation.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Hash of the document to witness.
The algorithm used for hashing the document.
SHA256 Organization that created the witness.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Subject designed as the first in the endorsement chain. Only a member of the operating organization can set this field. Once set, our on-chain relayer will submit a proof of endorsement to the Witness contract so that the corresponding token can be minted by the user later on the application.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
Name of the subject.
CURP of the subject. It is a unique identifier for people in Mexico.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
EVM address of the subject.
Each account is a smart account that includes a single signer contract deterministically created from a factory deployed through xdeployer so that every signer contract has the same address in all EVM networks. This signer contract is an implementation of a custom ERC-1271 interface that allows the RSA key to sign on-chain. Signers can be deployed trustlessly by anyone since they're controlled by the account owner.
The smart account is created from the Safe{Wallet} factory and includes a setup call to the RSA signer factory, deploying the signer contract who'll own the account. The account factory is already deployed on all networks with the same address so that the account can be created deterministically in all EVM networks too
This setup allows the following properties:
- The signer contract factory can create the same signer contract in all EVM chains for the same RSA key
- The account can be created deterministically in all EVM chains because it depends on the signer contract address and the RSA public key
In this way, the EVM address is completely abstracted from the EVM network, so we just need to keep a single address.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Country of the subject.
Email address of the subject.
Certificate of the subject.
Invite for the subject to sign Plumaa own terms and conditions.
The push notification token associated with the certificate. Used for sending notifications to the user.
Information required to claim a document in the Endorser contract. It is only present if the witness is processed and restricted to the initial owner.
A field whose value conforms with the standard mongodb object ID as described here: https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId. Example: 5e5677d71bdc2ae76344968c
The address that signed the authorization to claim the document. Needs to have privileges within Plumaa ID's AccessManager contract.
Authorization signature. It's an EIP-712 signature of the hash of the claim and the initial claiming address.
- Domain Separator:
EIP712Domain(string name,string version,uint256 chainId,address verifyingContract) - EIP-712 Type:
MintRequest(bytes32 leaf,address to)
Address of the initial claiming subject.
The chain ID where the claim is authorized.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
If the witness has been claimed by the initial owner.
Signature Request the witness is associated with. May not be present if the witness was via the API.
Individual NOM151 conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The provider that issued the timestamp.
CINCEL Combined merkleized conservation strategy.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
The transaction hash. Any transaction that includes an operation with this hash is valid. It could be either a transaction to another service (eg. The Witness contract), but it may be upgraded in the future.
The transaction chain ID.
The proof that the root existed at the time of the transaction.
Merkle root included in the transaction. It should be the same as the one computed from the merkle proof and the leaf hash.
The NOM 151 provider that issued the timestamp for the merkle root.
CINCEL Algorithm for hashing the internal nodes. The document hash is also re hashed using this algorithm to avoid second pre-image attacks. See https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
SHA256 Witness conservation strategy.
The timestamp issued by the provider.
The index of the leaf to be verified in the tree.
The left range of the proof.
The right range of the proof.
The root of the tree the proof is being verified against.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.
Date at which the signature request invite was rejected. Only present if rejected.
Date at which the signature request invite was signed. Only present if signed.