Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

How to Certify ?

After having registering you in our Trust Registry as a Trusted Source, you can now certify proofs

Certify Digital Document proofs

Certify your own proofs

Revoke proof

Create your own proof schema

1) Certify digital documents

a) Presentation of the digitalDocument schema

The digitalDocument schema is already anchored. Here is how it was built:

{
    "id": "c42e2516",
    "name": "DigitalDocument",
    "description": "An electronic file or document",
    "version": "0.9.0",
    "namespace": "archipels.io",
    "hash_algorithm": "SHA256",
    "matching_conditions": {
        "or": [
            "sha256"
        ]
    },
    "inputs": [
        "sha256",
        "dateCreated",
        "expires",
        "creator",
        "category",
        "description",
        null,
        null
    ],
    "input_definitions": {
        "sha256": {
            "description": "The SHA-2 SHA256 hash of the content of the item.",
            "standardization_function": "hexadecimal"
        },
        "dateCreated": {
            "description": "The date on which the CreativeWork was created or the item was added to a DataFeed.",
            "standardization_function": "formatDateTime"
        },
        "expires": {
            "description": "Date the content expires and is no longer useful or available.",
            "standardization_function": "formatDateTime"
        },
        "creator": {
            "description": "The creator/author of this CreativeWork.",
            "standardization_function": "replaceDiacritics.capitalize"
        },
        "category": {
            "description": "A category for the item. Greater signs or slashes can be used to informally indicate a category hierarchy.",
            "standardization_function": "digitalDocumentCategory"
        },
        "description": {
            "description": "A description of the item.",
            "standardization_function": ""
        }
    },
    "metadatum_definitions": {
        "sha256": {
            "id": "i1",
            "description": "The SHA-2 SHA256 hash of the content of the item.",
            "mandatory": true,
            "publication_flag": "searchable"
        },
        "dateCreated": {
            "id": "i2",
            "description": "The date on which the CreativeWork was created or the item was added to a DataFeed.",
            "mandatory": true,
            "publication_flag": "public"
        },
        "expires": {
            "id": "i3",
            "description": "Date the content expires and is no longer useful or available.",
            "mandatory": true,
            "publication_flag": "public"
        },
        "creator": {
            "id": "i4",
            "description": "The creator/author of this CreativeWork.",
            "mandatory": true,
            "publication_flag": "public"
        },
        "category": {
            "id": "i5",
            "description": "A category for the item. Greater signs or slashes can be used to informally indicate a category hierarchy.",
            "mandatory": true,
            "publication_flag": "public"
        },
        "description": {
            "id": "i6",
            "description": "A description of the item.",
            "mandatory": true,
            "publication_flag": "public"
        }
    }
}

See the next part 2. b. i. Create your proof schema to know more about *"*matching_conditions*"*, *"*standardization_function*",* *"*mandatory*"* and *"*publication_flag*"*.

b) Create a digitalDocument proof

Now you know how the schema is built, you can certify digital documents. First you must hash with SHA 256 your document using the following command to obtain the"document_hash" of your document.

There are the data you need to create a proof :

WARNING : make sure to put “0x” before the "document_hash" of your document.

The secret is used to generate a nullifier. You can create a proof without filling in a secret, but one will be returned after each creation. Please keep these secrets as they are the only data allowing someone to nullify a proof. WARNING : The secretmust be a random number generated separately and kept safe as this is required to revoke the proof we've just created. A good secret should have a high entropy level. For example : a good secret can be generated as an UUID, a hash or a password generated by a password manager. For the same proof, making requests one after the other without secret will trigger the creation of a proof twice and generate a new ID every calls. Now you know how to structure a digitalDocument proof, you will find how to certify your proof in the 2. Certify your own proof part in the .

2) Certify you type of proofs

a) Create your own proof schema

If you're creating a new type of proof, you have to create the schema first.

In the production environment, your proof schema will be created by the Archipels team after discussing of your use cases.

In the sandbox environment you’ll need the following information to create a proof schema.

The proof schema is the proof’s architecture. It is composed from :

  • "id" : the proof schema identifier

  • "name" : the name of the proof schema

  • "description" : the description of the proof schema

  • "version" : the version of the proof schema

  • "namespace" : “archipels.io”

  • "hash_algorithm" : “SHA256”

  • "inputs" : the inputs you need to create and characterize a proof. For example : “input_1”. Note that the number of inputs must be equal to a power of 2. If you don’t have enough inputs you need to complete it with null rows to complete it up to the higher power of 2.

  • "input_definitions" : for each input, you need to complete :

    • "standardization_function":

      • capitalize

      • digitalDocumentCategory

      • formatDate

      • formatDateTime

      • hexadecimal

      • removeSpaces

      • replaceDiacritics

  • "metadatum_definitions" :

    See the References for more details about the "id", the "mandatory" and the "publication_flag" inputs.

    • "id": identifier for the place of the Merkle tree where the input is. "i" identify the first stage, "n"is the second. When creating your schema, alway put "i", Archipels can change it after exploring your use case.

    • "mandatory": "true" or "false", it defines if the input is mandatory or not when creating a proof

    • "publication_flag":

      • "searchable": the input is a key for the proof verification, you can use it to identify the proof in the Archipels blockchain

      • "public": the input is disclosed when the proof verification is OK

      • "private": the input is not disclosed when the proof verification is OK

  • "matching_conditions" : a boolean combination of inputs needed to make a proof verification OK

You can see an example of an existing proof schema in the part 1. Presentation of the digitalDocument schema in or in the example below with two inputs:

Create a .json file (example.json for example) containing your proof schema.

There is the code to create the schema in the Trust Registry :

If the schema already exists you’ll get :

If it doesn’t, the Trust Registry will send you a 201 response with the details of your schema. The response for the example before is :

Once you have created your proof schema, you can certify proofs using this schema on the Archipels Trust Registry.

b) Certify your own proof

The data you need to create a proof are the inputs for which mandatoryis true.

There is the an example based on the "0aaaaa3b"proof schema created in the part before.

The secret given is used to generate a nullifier. You can create a proof without giving a secret, but one will be returned after each creation. Please keep these secrets as they are the only data allowing someone to nullify a proof.

WARNING : The secretmust be a random number generated separately and kept safe as this is required to revoke the proof we've just created. A good secret should have a high entropy level. For example : a good secret can be generated as an UUID, a hash or a password generated by a password manager.

For the same proof, making requests one after the other without secret will trigger the creation of a proof twice and generate a new ID every calls.

If one of your inputs is a document hash, you can use the command below to compute the sha256 of your document :

Then, the input would be

WARNING : make sure to put “0x” before the "sha256" of your document.

The command you need to create a proof in the Trust Registry are :

  • if you want to create it from data :

  • if you want to create it from a .json file (example.json for example) :

Here is the example.json file :

And the command :

  • If you want to create a proof directly from a datahash that you computed from a JSON containing all inputs :

WARNING : If .env file doesn't contain an ISSUER_ID, or a PRIVATE_KEYyou will get a message like this A properly set up identity is required in order to create a proof.

If it doesn’t, the Trust Registry will send you a 202 or response with the details of your proof.

For example, if you want to create a proof with the following .json from the digitalDocument schema of "schema_id" : "c42e2516" , here are the inputs :

The Trust Registry will return a code 202 response :

The "status"can be :

  • "pending": Proof saved in the database but is waiting to be registered in our accumulator

  • "registered": Proof saved in our accumulator

  • "included": Proof anchored in the blockchain

The "nullifier" is required along with the "secret" if you choose to revoke a proof.

The "qrCodeBase64"is the url where you can find the QRcode of the proof.

After creating a proof you should verify it. So let’s check the Verify part.

You can aslo revoke it if needed. For that, you can read the next part

3) Revoke proofs

Once revoked, the proof will then be marked as revoked in any future verification. There is the command you need to do it :

Note that the "message" is optional, if it’s missing it will automatically be set as "Proof revoked". If it worked, the response will be a code 200 response.

Here is an example of proof revocation and the Trust Registry response:

Response : Code 200

Mis à jour