KayTrust Specifications
DID methods
KayTrust uses the standard DID protocol for identifiers, and defines a "ev" DID method based on smart contracts.
More DID methods might be defined in the future.
| Specification | Builds on top of | What is it good for? |
|---|---|---|
| "ev" DID method | W3C's DID Specification | Ethereum-based DIDs |
| Proxy contract ERC | Ethereum | Transaction forwarding, on-chain representation, single Ethereum addresses |
| Identity Manager ERC | Ethereum | Flexible controlling logic for Proxy contracts |
Verifiable credentials and Presentations
The point of identifiers is to have credentials associated to them. A credential answers the question "Who are you?" and contains one or more key-value claims (e.g. birth date, name, qualifications, citizenships, etc.) about an entity called subject, issued by another entity called issuer. The Verifiable Credentials Working Group at the W3C is defining a standard data model that KayTrust follows.
Both Verifiable Credentials (VC) and Verifiable Presentations (VP) contain proofs, which is what makes them verifiable. The VC specification doesn't enforce a specific proof algorithm but describes the articulation between a credential/presentation and a specific proof method. Implementers are free to come up with their own proof method or to follow someone else's.
The draft ERC (Ethereum Request for Comments) describes a way for any entity to attest arbitrary content on a smart contract. There is a corresponding proof type that enables to use that attestation registry inside a Verifiable Credential or a Verifiable Presentation.
| Specification | Builds on top of | What is it good for? |
|---|---|---|
| Content Attestation Registry ERC | Ethereum | Attesting any kind of content on-chain |
| Attestation Registry VC proof type | W3C's Verifiable Credentials data model | Using a Content Attestation Registry as proof of a VC or a VP |
Real-world, self-sovereign authentication: "DID Connect"
KayTrust introduces a way for identity owners (a.k.a. subjects) to authenticate on third-party apps. We propose using OpenID Connect, only in a self-sovereign fashion. The trick is to use as Authorization Server the identity owner's own device, as opposed to a predefined AS in traditional services.
| Specification | Builds on top of | What is it good for? |
|---|---|---|
| DIDConnect OIDC Profile | OpenID Connect | Self-sovereign use of OpenID Connect |
Schemas
KayTrust mostly relies on well-known schemas, such as the great work done by the schema.org community. However, when the need arises, additional schemas are defined.
| Schema | Purpose |
|---|---|
| Trusted Credentials | Chain of Trust for Verifiable Credentials |
Why did you need to define anything?
Websites, electronic mail (email), email addresses, TCP connections, IP addresses, URLs, HTML pages, JPEG. Those are known and mature concepts.
Passwords, cryptographic keys, digital signatures, unique identifiers. Also mature concepts.
Likes, tweets, cookies, browser-side scripts, user profiles. Those are a bit younger but also well known.
Blockchain. Verifiable credentials. Digital identity. Now we're talking about something more recent in the history of internet. Those concepts are slowly taking shape, paving their way into users' and developers' minds, and into standards organizations' discussions. RFCs are being written, W3C Working Groups are being set up, blog articles are being cited.
Since digital identity is both a young a wide domain, KayTrust's objective is to bind together the state of the art of digital identity standards and turn them into a usable package for people and for businesses.