List Certificates

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.

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 public key's modulus, as a hexadecimal string.

The public key's exponent, as a hexadecimal string.

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.

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.

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.

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.

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.

Witness conservation strategy.

Earliest date when the hash was witnessed by any strategy. Unspecified if the witness is not processed.

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.