| Summary || Products || Cryptography || Fusion || KeeeX.Js || Verifier || KeeeX Chain || Digital Identity Management |
¶ Digital identity and keypair
KeeeX does not provide a full architecture for digital identity management, as this often comes with specialized constraints that are heavily tied to regulation and usage scenarios.
Our tooling, however, integrates well with existing systems.
We also provide a minimal service that can be deployed on premises for customers to manage their own keys and identities in a self-controlled, secure, and provable manner.
¶ Integrating with existing digital identity solutions
The only requirement, as far as KeeeX tooling is concerned, is having the ability to use one of the digital signature algorithms supported by KeeeX Fusion.
Beyond that, our tools have no concern regarding where the key pair comes from, or how the digital signatures are created.
Here's a generic possible implementation considering the separation between digital identity management and KeeeX tooling:
And here is the associated verification process leading to the trust in the digital identity used to keeex the file in the first place:
Such a solution is completely independant of the third-party identity mechanism, as long as it can provide with public key informations and produce suitable signatures.
¶ Providing one's own identity
While KeeeX provides the tools to integrate multiple digital signatures up to individual actors, some solutions require a more corporate approach, where only some digital identities need to be known by third parties.
Although such requirements can also be implemented by a full-fledged identity service, KeeeX provides a lightweight solution that allows an online entity to leverage existing sources of trust, such as existing TLS certificates used for public-facing websites, to publish their own list of known identities.
This tool takes a list of known identities based on the key's "address" and generates a set of files designed to be hosted on a standard HTTPS service.
The path used to serve these files always starts with ".well-known/keex/identity" to avoid potential conflicts.
Each address is associated with a basic digital identity consisting of a name, an optional link URL, and an optional logo URL.
Each individual "identity" is represented by a JSON structure:
{
"type": "certificate",
"version": 1,
"subject": {},
"key": {
"type": "bitcoin",
"address": "…",
},
"issuer": {},
}
The subject is based on the following:
{
"name": "KeeeX SAS",
"url": "https://keeex.me",
"imageUrl": ""
}
To ensure that these identity files are valid, they are all keeexed, and expose their issuer.
Multiple modalities are supported, but the simplest way is to reference the "authority" for this generated address book:
{
"type": "certificate",
"certificateAddress": "<issuer's certificate's address>",
"revokeUrl": ""
}
Among the files served, the authority's one is used as the issuer for all other provided identities.
Using this structure, it is possible to embed in keeexed files the domain of the identity provider, and when verifying files, such a provided domain can be queried for each signatory in a keeexed file.
Assuming a valid certificate is present, a keeexed file verifier could display a message indicating the actual identity name, and the trusted domain that provided said digital identity.