dyne · matteo-cristino · Jan 5, 2023 · Dec 29, 2022 · Dec 30, 2022 · Dec 30, 2022
diff --git a/Makefile b/Makefile
@@ -39,8 +39,8 @@ populate-remote-sandbox: ## Generate random DIDs in remote sandbox (RR_SCHEMA, R
 	zenroom -z client/v1/sandbox/create-identity-pubkeys.zen \
 			> /tmp/new-id-pubkeys.json 2>/dev/null
 	@jq --arg value $$(($$(date +%s%N)/1000000)) '.timestamp = $$value' /tmp/new-id-pubkeys.json > /tmp/new-id-pubkeys-tmp.json && mv /tmp/new-id-pubkeys-tmp.json /tmp/new-id-pubkeys.json
-	zenroom -z client/v1/sandbox/pubkeys-request.zen \
-			-a /tmp/new-id-pubkeys.json -k /tmp/controller-keyring.json \
+	zenroom -a /tmp/new-id-pubkeys.json -k /tmp/controller-keyring.json \
+			-z client/v1/sandbox/pubkeys-request.zen \
 			> /tmp/pubkeys-request.json 2>/dev/null
 	./restroom-test -s ${RR_SCHEMA} -h ${RR_HOST} -p ${RR_PORT} -u v1/sandbox/pubkeys-accept.chain -a /tmp/pubkeys-request.json | jq .
 
@@ -77,4 +77,4 @@ update-npm:
 clean: ## Clean all NodeJS dependencies
 	$(info Cleaning all dependencies - need a new install-deps)
 	@rm -rf node_modules package-lock.json
-	@rm -rf restroom/node_modules restroom/package-lock.json
+	@rm -rf restroom/node_modules restroom/package-lock.json
diff --git a/README.md b/README.md
@@ -18,39 +18,35 @@ Users need not to run a DID, but can use our official instance at https://did.dy
 To run a local instance however, make sure npm is installed and use:
 ```
 make install-deps
-make setup-local
 make run-local
 ```
 
-To generate DID documents one needs a registered EDDSA public key to be listed as admin did, i.e: `did:dyne:operator`
+To generate DID documents one needs registered ECDH and EDDSA public keys to be listed inside an admin DID document, i.e: `did:dyne:DID-spec.A` or `did:dyne:admin`.
 
-To run simple tests one can generate a fake key: `zenroom -z private_contracts/fake_keygen.zen > client_keyring.json`
+To run simple tests one can generate a fake keyring:
+```
+zenroom -k client/v1/did-setting.json -z client/v1/sandbox/sandbox-keygen.zen > sandbox-admin-keyring.json`
+```
+that is associated to the DID document whose DID id [did:dyne:sandbox.A:8REPQXUsFmaN6avGN6aozQtkhLNC9xUmZZNRM7u2UqEZ](/data/sandbox/A/8REPQXUsFmaN6avGN6aozQtkhLNC9xUmZZNRM7u2UqEZ).
 
-This fake key is able to write inside `did:dyne:sandbox` for testing purposes (saved data will be lost once in a while!)
+This fake keyring is able to write inside `did:dyne:sandbox` for testing purposes (saved data will be lost once in a while!)
 
 To test the creation of a DID document on the local running instance:
 ```
-make run-local
+make generate-sandbox-did-local
 ```
 
 ## DID document specs
 
-We call "DID spec" any word following the `did:dyne:` namespace. DID specs are governed by specific [contracts subdirectories](/contracts) carrying the same name.
+We call "DID spec" any word following the `did:dyne:` namespace. DID specs are governed by specific [contracts subdirectories](/api/v1) carrying the same name.
 
-Our DID implementation makes available some base DID specs to enable authenticated operators (`did:dyne:operator`) to register generic DID documents (`did:dyne:generic`).
+Any "DID spec" has one or more admins that have the permission to create, update or delete the DID document under their "DID spec". These admins can be recognized from their DID, indeed it will be of the from `did:dyne:DID-spec.A:` and they will govern all the DID documents whose DID starts with `did:dyne:DID-spec:`.
 
-We have also project specific implementations that introduce ad-hoc schemas like `did:dyne:zenflows`) manages DIDs for the `did:dyne:ifacer` namespace.
+For example `did:dyne:zenflows.A` manages DIDs for the `did:dyne:zenflows:` namespace.
 
-So far we have:
-
-| did spec | admin spec |
-|:--------:|:----------:|
-| generic  | operator   |
-| ifacer   | zenflows   |
-| sandbox  | (fake)     |
-
-The special `did:dyne:elohim` spec is the one governing all admin specs and can create, update and delete admins.
+The special `did:dyne:admin` spec is the one governing all admin specs and can create, update and delete admins.
 
+<!-- Controller has no more a keyring! can be eliminated or it will be usefull when notarization will be back?
 ## Controller Keyring (setup once)
 
 Inside the [private_contracts](private_contracts) are the scripts to generate the primary controller keyring whose ECDH key will be used to sign all DID documents and whose ECDH public key can be used to verify their integrity.
@@ -77,5 +73,5 @@ The keyring has to be stored into: `contracts/keyring.json`
 
 The public keys should be generated with: `zenroom -z private_contracts/create_pub_keys.zen`
 and stored in `contracts/public_keys.json`
-
+-->
 
diff --git a/data/sandbox/.keep b/data/sandbox/.keep
diff --git a/docs/README.md b/docs/README.md
@@ -10,18 +10,18 @@ In this documentation, we will provide an overview of the decentralized identity
 
 Thank you for choosing our decentralized identity solution. We hope that it empowers you to take control of your own identity and personal data.
 
-## Our W3C DID implementation supports: 
+## Supported fields
+Our W3C DID implementation supports:
 * A list of API endpoints, as an array “serviceEndpoint”.
-* Geolocation fiels as “Country” and “State”
+* Geolocation fields as “Country” and “State”
 * Public keys for:
   * Secp256k1 ECDSA, widely used for single signatures
   * ED25519 EDDSA widely used for single signatures
   * BLS381 [“Reflow”](https://medium.com/think-do-tank/reflow-crypto-material-passports-for-the-circular-economy-d75b3aa63678) [[REFLOW]], for multisignature and advanced zero-knowledge proof operations
   * Dilithium2, for [quantum-proof signatures](https://medium.com/think-do-tank/quantum-proof-cryptography-e23b165b3bbd)
   * Ethereum public addresses (“blockchainAccountId”), following the eip155 standard 
-* The DID whose document contains the txId on Ethereum-based blockchain ganache where the DID document was stored, stored in the string “alsoKnownAs”
-* The JWS signature of the DID Document operated by the [Controller](https://did.dyne.org/docs/) inside the "proof"
+* The JWS signature of the DID Document operated by an admin inside the "proof" field in order to ensure data integrity.
 
-To have more information about the specification of our DID method you can jump to the [Specification Section](specification.md?id=specification). 
+To have more information about the specification of our DID method you can jump to the [Specification Section](/specification#specification).
 
-If you are more interested in understanding what type of keys we have used inside the DID document you can visit our [Security Vocabulary](security.md).
+If you are more interested in understanding what type of keys we have used inside the DID document you can visit our [Security Vocabulary](/specification#dyne-org-s-w3c-did-security-vocabulary).
diff --git a/docs/index.html b/docs/index.html
@@ -264,6 +264,29 @@
                     publisher: 'IETF',
                     id: 'multibase',
                 },
+                RFC3986: {
+                    title: 'Uniform Resource Identifier (URI): Generic Syntax',
+                    date: 'January 2005',
+                    href: 'https://www.rfc-editor.org/rfc/rfc3986',
+                    authors: [ 
+                        'T. Berners-Lee',
+                        'R. Fielding',
+                        'L. Masinter'
+                    ],
+                    status: 'Internet Standard',
+                    publisher: 'IETF'
+                },
+                RFC5234: {
+                    title: 'Augmented BNF for Syntax Specifications: ABNF',
+                    date: 'January 2008',
+                    href: 'https://www.rfc-editor.org/rfc/rfc5234',
+                    authors: [ 
+                        'D. Crocker, Ed',
+                        'P. Overell',
+                    ],
+                    status: 'Internet Standard',
+                    publisher: 'IETF'
+                }
             },
         };
 

diff --git a/docs/security.md b/docs/security.md
@@ -2,8 +2,8 @@
 
 ## Classes
 
-### EcdsaSecp256k1VerificationKey_b64
-This class represents a linked data signature verification key. It is implemented as stated [here](https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/) with the only difference that accepts base 64 encoded public key with the proprerty [**publicKeyBase64**](#publickeybase64).
+### ReflowBLS12381VerificationKey
+This class represents a linked data signature verification key. See [reflow-BLS12381 paper](https://arxiv.org/pdf/2105.14527.pdf) for more details.
 
 **Status**:  
 *Stable*  
@@ -14,15 +14,16 @@ This class represents a linked data signature verification key. It is implemente
 
 ```json
 {
-	"id": "did:example:123#key1",
-	"type": "EcdsaSecp256k1VerificationKey_b64",
+	"id": "did:example:123#reflow_public_key",
+	"type": "ReflowBLS12381VerificationKey",
 	"controller": "did:example:123",
-	"publicKeyBase64": "BMryTzTcMC42F4dOWdXM5mVAZr0dvS0jV84oBt/SQBePhxH2p3/NilU9siTfdNWv7iPcViIPDtz3JxFiQY/Gu5s="
+	"publicKeyBase58": "9kPV92zSUok2Do2RJKx3Zn7ZY9WScvBZoorMQ8FRcoH7m1eo3mAuGJcrSpaw1YrSKeqAhJnpcFdQjLhTBEve3qvwGe7qZsam3kLo85CpTM84TaEnxVyaTZVYxuY4ytmGX2Yz1scayfSdJYASvn9z12VnmC8xM3D1cXMHNDN5zMkLZ29hgq631ssT55UQif6Pj371HUC5g6u2xYQ2mGYiQ6bQt1NWSMJDzzKTr9y7bEMPKq5bDfYEBab6a4fzk6Aqixr1P3"
 }
 ```
 
-### ReflowBLS12381VerificationKey_b64
-This class represents a linked data signature verification key. See [reflow-BLS12381 paper](https://arxiv.org/pdf/2105.14527.pdf) for more details.
+<!-- Old base64 public keys
+### EcdsaSecp256k1VerificationKey_b64
+This class represents a linked data signature verification key. It is implemented as stated [here](https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/) with the only difference that accepts base 64 encoded public key with the proprerty [**publicKeyBase64**](#publickeybase64).
 
 **Status**:  
 *Stable*  
@@ -34,12 +35,15 @@ This class represents a linked data signature verification key. See [reflow-BLS1
 ```json
 {
 	"id": "did:example:123#key1",
-	"type": "ReflowBLS12381VerificationKey_b64",
+	"type": "EcdsaSecp256k1VerificationKey_b64",
 	"controller": "did:example:123",
-	"publicKeyBase64": "AoD1VmYjfBP0L26CpsYRnzEkaslI91uBIknP/3bqWEq4S6JdjWIomIe3CfypCCe/Cz3Lsodx/rBlxIxXktpKBYYddjNgwUCWJ4jGUryLNSoBA2WcdY360FV2bu/fUABhC3oQHFSlwwpmltWvoSrMBqZ/6R5UvX2iC+lkI3966jcB3zhJ0dBsIrVkftGhvr3EFHgHafua/XL+IaqbmJ+fIhhq60yjnJ/i3riAcO3+aZX3fcFBkGH/de5NPCyunSeD"
+	"publicKeyBase64": "BMryTzTcMC42F4dOWdXM5mVAZr0dvS0jV84oBt/SQBePhxH2p3/NilU9siTfdNWv7iPcViIPDtz3JxFiQY/Gu5s="
 }
 ```
 
+### ReflowBLS12381VerificationKey_b64
+
+
 ### SchnorrBLS12381VerificationKey_b64
 This class represents a linked data signature verification key. It has been implemented following the [bitcoin-specification](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) with the only difference that it is implemented over BLS12381 instead of Secp256k1.
 
@@ -102,3 +106,4 @@ The following example demonstrates the expression of a public key in base64 form
 	"publicKeyBase64": "BMryTzTcMC42F4dOWdXM5mVAZr0dvS0jV84oBt/SQBePhxH2p3/NilU9siTfdNWv7iPcViIPDtz3JxFiQY/Gu5s="
 }
 ```
+-->