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.
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 :
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:
{"id":"0aaaaa3b","name":"Example","description":"Example of proof schema","version":"0.1.0","namespace":"archipels.io","hash_algorithm":"SHA256","inputs": ["input_1","input_2","input_3",null ],"input_definitions": {"input_1": {"description":"Description of input_1","standardization_function":"<standardization_function>" },"input_2": {"description":"Description of input_2","standardization_function":"standardization_function" },"input_3": {"description":"Description of input_3","standardization_function":"<standardization_function>" } },"metadatum_definitions": {"input_1": {"id":"i1","description":"Description of input_1","mandatory":true,"publication_flag":"searchable" },"input_2": {"id":"i2","description":"Description input_2","mandatory":true,"publication_flag":"searchable" },"input_3": {"id":"i3","description":"Description of input_3","mandatory":true,"publication_flag":"public" } },"matching_conditions": {"and": ["input_1","input_2" ] }}
Create a .json file (example.json for example) containing your proof schema.
There is the code to create the schema in the Trust Registry :
POST /schemas -H 'Content-Type: application/json' --data '@example.json’Host : "<yourLocalApiInstanceUrl>"
If the schema already exists you’ll get :
{"status":409,"message":"ProofSchemaExisting"}
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 :
{"id":"0aaaaa3b","name":"Example","version":"0.1.0","hash_algorithm":"SHA256","tree_height":2,"description":"Example of proof schema","owner":null,"namespace":"archipels.io","inputs": ["input_1","input_2","input_3",null ],"input_definitions": {"input_1": {"description":"Description of input_1","standardization_function":"<standardization_function>" },"input_2": {"description":"Description of input_2","standardization_function":"<standardization_function>" },"input_3": {"description":"Description of input_3","standardization_function":"<standardization_function>" } },"metadatum_definitions": {"input_1": {"id":"i1","description":"Description of input_1","mandatory":true,"publication_flag":"searchable" },"input_2": {"id":"i2","description":"Description input_2","mandatory":true,"publication_flag":"searchable" },"input_3": {"id":"i3","description":"Description of input_3","mandatory":true,"publication_flag":"public" } },"matching_conditions": {"and": ["input_1","input_2" ] }}
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 :
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 :
"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 :
POST /proofs/revoke -H 'Content-Type: application/json' --data '{ "nullifier":"<nullifier>","secret":"<12_characters_optional_secret>","message":"<reason_for_revocation>"}'Host : "<yourLocalApiInstanceUrl>"
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:
POST /proofs/revoke -H 'Content-Type: application/json' --data '{"nullifier":"ea3fa1672a240f69a0a0240be9c161f8631d2c5b2a2f9829d68329047bff7051","secret":"secret_secret_secret" }'Host : "<yourLocalApiInstanceUrl>"
