Get subject
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Query Parameters
Response
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.
Country of the subject.
RFC of the subject. It is a unique identifier for persons and organizations in Mexico.
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.
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.