A standardized communication protocol is always crucial for interoperability but also crucial for DID based, highly secure data exchanges/communication.
To support all features of decentralized identifiers (DIDs) we require that communication is based on:
- established cross-industry standards (JWS, JWE, JSON-WT, etc)
- message-based to secure transfer of claims (such as authorization information) between parties
- multiple different synchronous and asynchronous communication protocols
Available communication protocols:
- Websocket on port 2012 (not encrypted on reference system)
- WebServices API JSON via the JSON Namepace
- HTTP Post via http://coin.codeb.io/post.aspx (not encrypted on reference system)
- DNS (on request)
- SMPP (on request)
JSON Syntax
Submitted JSON Objects have to follow JSON-WT specifications.
JSON Signatures (JWS) and JSON Encryption (JWE) are used to authenticate and secure the data.
Bearer Token are required for authorization. Read more here: https://blog.codeb.io/bearer-token-generation/
Examples
We created a testkey with the address 0x9166b9fEC04DB238C6f11752a3cC2DA7348305C6 on the testnode. Its private key is encrypted with the password aloaha123.
If you send the following JSON (for example via websocket: http://coin.codeb.io/websocket.aspx)
{
“@type”: “specs/jwt”,
“@id”: “bdcf4f1e-bfc1-41f8-a497-72ede83c0302”,
“ktype”: “1”,
“authentication”: {
“type”: “passwordauth”,
“thid”: “bdcf4f1e-bfc1-41f8-a497-72ede83c0302”,
“username”: “0x9166b9fEC04DB238C6f11752a3cC2DA7348305C6”,
“password”: “aloaha123”
}
}
Note: The username and password field can be passed as encrypted JSON Web Token. The JSON Namespace offers helper function EncryptedPasswordJSONToken to construct the JSON
You will receive the following answer:
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImFkZHJlc3MiOiIweGE1QUZFNUMxQ0JkYzgzODIwQzRDZDRBOEI4RDhBMzRGMWEwOGQzYmIiLCJlY2NwdWIiOiJSVU5MTVNBQUFBQ1dINXRiX0NEOEUyZzQ0amlOUlQ2TDRvWXdrTXlZTTNJaDRNR2FvR29HTUR2VWFtUW1kZ0lZdnRLVUlieVlzdGVpcEVpZ21KZGRSQ1NVUDdpMGY5WTQifQ.eyJsb2dnZWRJbkFzIjoiMHg5MTY2YjlmRUMwNERCMjM4QzZmMTE3NTJhM2NDMkRBNzM0ODMwNUM2IiwiaWF0IjoiMTU5Nzc2OTU5NCIsIn50aHJlYWQiOnsidGhpZCI6ImJkY2Y0ZjFlLWJmYzEtNDFmOC1hNDk3LTcyZWRlODNjMDMwMiJ9LCJAaWQiOiJjYmFkNDNiMS0wYTFjLTQwMzgtYjZiMS1lNjM0MjJjNDY5OWIifQ.6VbOgIkXBWGpGkr0Qi3SswvsRzCV_6YCHYXpeJVEP9X81cJN7_9aHhAEa9eUHQETJdAX5iGs_QGrJ8Nl6sGlhA
As you can see that are three base64 encoded blocks representing header, payload and signature.
You can validate that payload with any JSON-WT library, or websocket or online via: https://coin.codeb.io/json.asmx?op=DecodeJWT or https://jwt.io/
Here the decoded header is:
{
“alg”: “ES256”,
“typ”: “JWT”,
“address”: “0xa5AFE5C1CBdc83820C4Cd4A8B8D8A34F1a08d3bb”,
“eccpub”: “RUNLMSAAAACWH5tb_CD8E2g44jiNRT6L4oYwkMyYM3Ih4MGaoGoGMDvUamQmdgIYvtKUIbyYsteipEigmJddRCSUP7i0f9Y4”
}
The header contains the address of the signer and its public key as ECCPublicKeyBlog
The decoded payload is:
{
“loggedInAs”: “0x9166b9fEC04DB238C6f11752a3cC2DA7348305C6”,
“iat”: “1597769594”,
“~thread”: {
“thid”: “bdcf4f1e-bfc1-41f8-a497-72ede83c0302”
},
“@id”: “cbad43b1-0a1c-4038-b6b1-e63422c4699b”
}
The payload confirms that 0x9166b9fEC04DB238C6f11752a3cC2DA7348305C6 successfully logged into the node and unlocked its private key for the given timespan.
Kindly note that the payload can contain more attributes such as verifiable claims, etc.