Skip to content

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


KayTrust mostly relies on well-known schemas, such as the great work done by the 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.