Comment on page
Outline of the trust model
The foundation of Ontology's trust mechanism is based on a verifiable credential system.
Entities issue credentials and sell them to their customers, and this gives rise to a verification scenario. The closed loop of issuing requests, creation, and consumption of credentials is what makes up the trust mechanism. All entities can make and verify claims.
Here are the parties that are involved in the process.
- Credential owner - has an
ONT ID. This entity acquires a verifiable credential issued by another entity that is referred to as the
credential issuer. This entity is able to manipulate credentials, with anonymous credential technology, and provide the credentials to the
credential consumer. Thus, they play the role of a trust seller.
- Credential issuer - has an
ONT ID. This entity issues credentials to endorse a target entity for certain qualifications or credentials. The category of credential Issuer includes trust anchors, i.e. the partners or entities that provide authentication services in the Ontology ecosystem. Trust anchors could be government agencies, universities, banks, third-party authentication services, bio-metric technology companies, etc. Credential issuers provide multi-dimensional authentication for entities that are part of the trust network. The authentication process and result are recorded on the Ontology blockchain with data privacy protection. Credential issuers provide a standardized and credible authentication method for credential consumers to verify the credentials. Credential issuers play the role of a trust endorser.
- Credential consumers - accept the user's verifiable credentials and initiate the credential verification process for the respective credentials. This includes many different scenarios, e.g., the employers who need to verify the interviewer's identity information/degree/industry skills. They the play the role of trust buyer.
Credential Verification Process
It is clear from the workflow illustrated above that the process involves three major actions:
- 1.Credential request
- 2.Credential issue
- 3.Credential verification
The issuing process involves two parties, the credential issuer and the entity that owns the ONT ID.
A verifiable credential includes the contents of the credential (that would vary depending upon the system), the digital signatures, and blockchain attestation records. Some of the records are:
- Credential ID: Unique identifier for credentials
- Credential content: Specific credentials or information, for instance a degree certificate
- Credential metadata-
- Created time: Timestamp for when the credential was created
- Issuer: ONT ID of the issuer
- Recipient: ONT ID of the recipient party
- Expiration time: UNIX timestamp for the credential automatically expires
- Revocation mechanism: Use the revocation list or record the revocation information directly in the attestation contract
- Blockchain proof
- Public key of the issuer
- Signature value
For centralized ONT ID systems, the first step in the workflow might differ in terms of the request that is sent to the credential issuer, since the owners will have delegated another body with access to their ONT ID and credentials. The request may not necessarily be sent by the owner themselves. The delegated body may also initiate and authorize credentials.
The issuance process involves four main steps:
- 1.The ONT ID owner initiates the process by sending a request to the credential issuer.
- 2.The credential issuer generates a verifiable credential and transmits it to the recipient using a secure method. The credential is encrypted using the recipient's public key.
- 3.The owner (or the delegate) signs the credential and sends it back to the credential issuer.
- 4.The credential issuer finally completes the signing process and sets the status of the credential to attested. Next, the credential is transmitted to both the Ontology blockchain and the owner (or the delegate).
This whole process basically covers Steps 1~3 in the credential workflow illustrated above.
There are three major actions involved in verifying a credential and they correspond to the steps 4 ~ 5 in the workflow illustrated above.
- Verifying whether the credential is in the blockchain
- Verifying the signature and whether it has expired
- Checking whether the credential has been revoked
It is necessary to verify whether the record of the verifiable credential is present on the blockchain. In case the node is not fully synchronized with the Ontology blockchain, merkle proof can be used to verify the verifiable credential transaction.
Merkle proof consists of an array, and each element contains two data items, direction and hash.
- Direction: Represents branch of the merkle tree the particular array element is in. There are two possible values.
- Hash: Represents hash value of the element data.
The algorithm using which the merkle proof is verified is as follows:
- 1.Check if transaction is included in block indexed by
proof.BlockHeight. If not, return
p <- GetBlockHash(proof.BlockHeight).
- 3.For each element in
e.Direction == "Left",
p <- H(e.TargetHash, p);
p <- H(p, e.TargetHash).
pequals to the
proof.MerkleRoot. Otherwise, return
false.In addition, it is also necessary to verify the status of the credential attestation. This can be carried out by calling the inquiry interface
GetStatus()of the attestation contract with the address
proof.ContractAddr. If the status is
not attested, an error would be returned.
When verifying the signature, the public key ID needs to be used to fetch the public key value and its current status. The verification algorithm is then called to carry out the verification process.
The format of the pubic key ID is
The public key ID is used to call the ONT ID smart contract method that queries the status of the public key.
GetPublicKeyStatus(byte ontId, byte pkId)
The response contains the following:
- publicKey: Public key value (hex)
- status: Two possible values:
Three possible results of signature verification:
- Signature is invalid
- Signature is valid
- Signature is valid and the public key is
Next, the expiration time can be verified by checking whether the timeout period has expired.
Currently there are two revocation modes available- revocation list and revocation inquiry interface.
Here's an example of the revocation list credential request. It contains the
URLof the list.
Using the revocation inquiry interface as an example, if the revocation information is placed in the attestation contract, when calling the inquiry interface
GetStatusof attest contract, revocation verification will return
successif and only if the returned status field is
attested. It will return
failif the status field is
attest has been revoked.
The revocation list mainly includes the unique identifier and the revocation time of the revoked verifiable credential.
The fundamental structure of the token consists of three parts:
The standard JWT attributes are used to a great extent while in certain special cases custom attributes are defined.
The standard JWT format is augmented by appending the blockchain proof at the end, a typical verifiable credential has the following layout:
blockchain_proofis not required in some cases, and is thus optional.
headerdefines the format, the signature scheme, and the ID of the public key used to verify the signature on the credential.
The credential ID, credential content and the metadata are packaged into a
JSONobject which then acts as the payload. It will use some of the registered credential names specified in the
JWTspecification, such as
"Name": "Bob Dylan",
Next, to issue a credential, a JSON object needs to be constructed that would contain the credential ID, the content, and the metadata. The JSON object can then be serialized using the standard serialization method. One of the issuer's private keys is then used to sign the binary data of the payload and the header.
After serialization, the payload would look something like-
"Name": "Bob Dylan",
After the header and payload of the request are constructed the signature is computed according to the JWS standard. Full description of the standard can be found in the RF 7515 Section 5.1 of the IETF documentation.
The process is as follows:
- 1.Calculate the signing input as serialization of the header and payload according to JWS specification.
sig := sign(Base64URL(header) || . || Base64URL(payload))
- 1.Compute the JWS signature using the specified method for the particular signature scheme being used for the signing input.
- 2.Encode the signature.
signature := Base64URL(sig)
The general format of a proof object is as follows:
The MerkleProof is encoded in the following manner:
Hence, a complete verifiable credential is created. The final structure is as follows:
BASE64URL(Header) || '.' || BASE64URL(Payload) || '.' || BASE64URL(Signature) '.' || BASE64URL(MerkleProof)
The attestation contract of a verifiable credential provides attestation service and record availability information, that is, whether or not it has been revoked.
The available methods are described below:
- Commit Attestation
bool Commit(byte claimId, byte committerOntId, byte ownerOntId);
In the attestation contract,
claimIDserves as the unique identifier for a credential. It is the first parameter; The
committerOntIdis the ONT ID of the attester. The
ownerOntIdis the ONT ID of the owner.
This method will return
trueif and only if the credential is not attested, and the method has been called by the committer; Otherwise, it will return
After the attestation is done, the status of the credential will be updated to attested.
- Revoke credential
bool Revoke(byte claimId, byte revokerOntId);
This method will return
trueif and only if the credential is attested, and the
revokerOntIdis the same as the attester's
ONT ID; Otherwise, it will return
- Attestation Inquiry method
byte GetStatus(byte claimId);
This method returns the status of the credential. The response contains two parts of information:
Attest has been revoked;
- ONT ID of the attester.
Currently supported signature schemes are:
Last modified 3yr ago