Skip to content

Latest commit

 

History

History
121 lines (76 loc) · 4.69 KB

101.md

File metadata and controls

121 lines (76 loc) · 4.69 KB
Raw
FATIP Title Status Category Author Created
101 FAT Factom Digital Identity Implementation Accepted Core Devon Katz <devonk@dbgrow.com> 8-17-2018

Summary

This document describes the standardized implementation of Factom based digital identities in the FAT ecosystem. Identities are needed for signing and authentication of data.

Motivation

As a data-only protocol, FAT necessitates signing authorities to issue tokens, perform coinbase transactions, and many other operations. Digital identities are a means to authenticate that a creation, or balance altering event is valid, and originated from a trusted source.

Specification

This standard utilizes Factom Digital Identities, which are implemented in the Factom Authority Set to link ANO's real world identities to their servers.

To summarize the features of the implemented Factom identity solution:

  • An authority party privately generates a digital identity on a secure computer, creating a number of ed25519 key pairs.
  • The public parts of the Identity are registered by the authority party on Factom to attest to it's existence.
  • The authority party "claims" the digital identity by publicly linking to it. Verification of ownership can be obtained by signing of arbitrary, unique data using the identity's private keys.

Cryptographic Material

For something to be signed and authenticated by a digital identity (i.e. issuance, coinbase transaction, new tokens), several pieces data are specified:

Data

The data to sign. It should be unique so as to produce a unique signature. It's recommended to structure the data being signed so as to prevent signature replay attacks. For example, in FATIP-0 where FATIP-101 is extended, the data to sign is concatenated with the chain ID the signature resides on, so as to prevent cross chain replay.

The data to sign may not always be explicitly stored. It's up to the implementing spec to define how to derive the data and if it's necessary to include it. If it is included in JSON, it should be under the field name data.

Identity Root Chain ID

The Factom chain ID of the identity that will sign data. It's required to know the root chain ID of the identity in any implementing standard so that the signed data can be verified. It's not required to specify the signing identity's root chain ID explicitly in JSON, however, it must be known through some means. For example, FATIP-0 includes the root chain ID as part of it's chain ID derivation scheme(FATIP-101), so it is known already. If it is desired to specify the signing identity's root chain ID in JSON, it should be under the field issuer.

IDKey

The IDKey is the preimage of the signing identity's identity key. It is used to verify signatures of the signing identity. The IDKey can be found as the 4th ExtID in the Identity's registration entry. The registration entry is expected to be the second entry in the identity's root chain.

The IDKey is implicit based on the context, and should not be explicitly included in any datastructures of inheriting specifications. Inheriting specifications should denote the signing identity's root chain ID so that applications can determine the signer's IDKey using Factom's digital identity protocol.

For example, in FATIP-0's implementation of FATIP-100, the issuer's ID is integrated into the derivation of the token's chain IDs.

Signature

The signature is the output of the ed25519 signature function. It's inputs are the Identity's first ed25519 private key (SK1), and the Nonce. It's output is the binary signature of the digital identity. It can be verified using the publicly available IDKey, Signature, and Nonce.

The signature is always stored as raw binary data under the last External ID of the entry containing relevant data/signing material.

Example Entry

Entry Content:

{
	"data": "7d6920cecc97a105a93763800c692afaf40a87d42c4f505b4a226c0f0e5a7a43",
	"issuer":"888888dd9e60c1f0216f753caf5c9b5be4c9ca69db27a6c33d30dce3fe5ee709"
}

Entry External IDs:

ExtIDS[ExtIDS.length - 1] = < Binary 1 8 0 0 211 74 47 ... 9 182 >
  • content.data - The data to sign
  • content.issuer The root chain ID of the singing identity
  • ExtIDS[ExtIDS.length - 1] - The raw binary ed25519 signature output of content.data

Implementation

No implementation notes

Copyright

Copyright and related rights waived via CC0.