Each claim in the Po.et Network MUST be signed by its issuer so that the system can later validate ownership of any given claim.
An issuer MUST be an existing identity claim in the Po.et Network.
Po.et uses the Linked Data Signature specification to sign claims. There are some very specific elements to be noted in this specification:
creatorURI that SHOULD dereference to the appropriate public key. In order to implement that here, the Po.et protocol uses the link to the issuer’s identity claim to dereference the public key, which ensures a permanent retrieval of this specific public key.
The signature block (or proof) is a Linked Data Signature object that includes the following fields:
type- A URI that identifies the digital signature suite that was used to create the signature. Often, just the signature suite name (e.g., Ed25519Signature2018) is required from developers to initiate the creation of a signature. Po.et will use the Ed25519Signature2018 signature suite.
creator- A URI that identifies the public key of the public/private key pair associated with the signature. In the Po.et Network, the creator is a
po.et://entities/<identity claim id>link for the public/private key pair. The URI SHOULD be a URL that can be dereferenced to obtain a Linked Data document that contains a link identifying the entity that owns the key pair. In the Po.et Network, this would only be true if the Identity Claim also contains a profile URL.
proofValue- The signature, signing the entire claim, excluding the
signaturefields, and including the
created- The string value of an ISO8601 combined date and time string generated by the signature suite.
nonce?- Optional, but strongly recommended. A string value that is included in the digital signature and MUST only be used once for a particular domain and window of time. This value is used to mitigate replay attacks.
domain?- A string value specifying the restricted domain of the signature. Also to be included in the document prior to signing.
All claims in the Po.et Network must be signed with an existing Identity Claim. The only claims that can be self-signed are Identity Claims meant to represent an Identity Provider. This provider can then generate other identity claims.
To self-sign an Identity Claim, use the URI data schema:
IMPORTANT For a user to export an identity claim, they must also be able to retrieve the private key associated with the Identity Claim. This is true for wallets providing key custody.
Note that the first 4 steps involve creating the document to be signed from the raw document. A signature for a claim should be constructed as follows:
Canonical Form, or normalized form, is the formal method of expressing a document to yield isomorphic results, regardless of serialization.
The algorithm for serializing/deserializing JSON-LD documents to RDF is described here.
The current results of the test suite against the standard is here.
Many of the signature suites contain both the signing and hashing algorithms as part of the suite. Selecting such a suite may handle hashing the canonical document during the signing process.
Steps 1-5 involve recreating the actual document that was signed. Step 6 is the standard verification of a signed document given the recreated signed document, the signing algorithm, and the public key.