Skip to content

Commit

Permalink
added documentation; updated orgVc schema
Browse files Browse the repository at this point in the history
  • Loading branch information
kostysh committed Nov 16, 2021
1 parent 51d244c commit f3a2fd8
Show file tree
Hide file tree
Showing 10 changed files with 1,013 additions and 134 deletions.
90 changes: 5 additions & 85 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,105 +1,25 @@
![npm](https://img.shields.io/npm/v/@windingtree/org.json-schema) [![NPM Package](https://github.com/windingtree/org.json-schema/actions/workflows/tests.yml/badge.svg)](https://github.com/windingtree/org.json-schema/actions/workflows/tests.yml)

## Version 1.0.0-beta.*
## Documentation

- Updated DID format that now supports multichain ORGiD:

```
did:orgid:4:0x94bf5a57b850a35b4d1d7b59f663ce3a8a76fd9928ef2067cc772fc97fb0ad75
^ network Id
```
> `4` - Ethereum Rinkeby ChainID according to [https://chainlist.org/](https://chainlist.org/)
- Added ORG.JSON VC schema - a cryptographically signed version of ORG.JSON
- ORG.JSON VC schema extended with NFT-specific properties to support ORGiD NFT meta-data feature
- ORG.JSON schema extended with `capabilityDelegation` definition
- `trustAssertions` definition in the ORG.JSON schema is extended with support for Trust Assertion Credential
- Added separate Trust Assertion Credential schema
- Added typescript types which are can be imported from the `types` directory of the package as following

```typescript
import type { ORGJSON } from '@windingtree/org.json-schema/types/org.json';
```

The whole list of available types definitions:

- `/types/org.json`
- `/types/orgVc`
- `/types/vc`
- `/types/nft`
- `/types/trustAssertion`

The whole list of json schemas that can be imported from the package:

- `org`
- `orgVc`
- `vc`
- `nft`
- `trustAssertion`

## Version 0.5.0 new features and updates

This version of the ORG.JSON schema should be used with new version of the ORGiD protocol (2.0).

- `publicKey` property is renamed to `verificationMethod` because of deprecation in the standard
- Added: `verificationMethod.publicKeyJwk` property
- Added: `verificationMethod.blockchainAccountId`

`blockchainAccountId` is a string value of the public key in following format:

```
0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1
^ ^ ^ ^
1 2 3 4
1. account address (public key)
2. delimiter of the key and its standard
3. the standard there described a type of the blockchain and network identifiers. In this case [the Ethereum blockchain](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md)
4. the blockchain network code. According to the standard 1 is the `Ethereum mainnet`
```

- Added property `publicKey.publicKeyRevocation` to add ability of a key revocation handling
- `trust.assertions` moved to the top level as `trustAssertions`
- `trust.credentials` moved to the top level as `credentials`
- Added optional `legalEntity.organizationalUnits` property that be a list of organizational units dids
- Added optional `organizationalUnit.parentOrganization` property that be a link to the parent organization
- Added top-level `person` property to add ORG.JSON ability to handle personal profiles
- Definitions `CryptoETHAddress` and `CryptoBTCAddress` are replaced with single definition `BlockchainAccountId` which is standardised by the DID specification and able to handle all types of blockchain accounts
- From now schema is building from multiple files. VC schemes are moved to separate file
- Along with the schema file now is provided a file with typescript definitions

## Version 0.4.0 breaking change

- `legalEntity.legalIdentifier` is renamed to `legalEntity.registryCode`

If you are want to use an old term you should define s specific `schemaVersion` (0.3.4) in your `org.json` file overwise your `org.json` will throw a warning during validation.

## ORG.JSON Schema

ORG.JSON is a data format based on the [json-schema](http://json-schema.org/specification.html) specification used for describing organizations of all types: commercial firms, NGOs, even organizations that aren't incorporated (like [W3C](https://www.w3.org/Consortium/facts#org), for example).

The goal behind ORG.JSON is to provide correct and truthful snapshot of an organization, sufficient to represent its subject in any online transaction.

An ORG.JSON file may describe a legal entity, an organizational unit, or both at the same time. Legal entity may have zero or any number of units. Units can't exist on their own, they must belong to a legal entity.

While "legal entity" is self-explanatory, "units" may represent a wide range of company's structural parts: departments (accounting or legal department), business locations (in case the same legal entity operates a few different stores), etc. We intentionally made the "unit" concept flexible. Relationship between a legal entity and its units is reflected in the [ORGiD Registry](https://github.com/windingtree/org.id) smart contract.
[ORG.JSON schemas documentation](./docs/index.md).

## Examples

- [legal entity](examples/legal-entity.json)
- [organizational unit](examples/unit.json)
- [real-life examples](https://github.com/windingtree/orgids)

## Usage
## Setup

### NPM package

```sh
npm i @windingtree/org.json-schema
yarn add @windingtree/org.json-schema@1.0.0-beta.5
```
## JSON Schema Specification

This will generate a JSON Schema specification file in the `dist` directory:
This will generate a JSON Schema specification file and Typescript typings in the `dist` directory:

```bash
yarn build
Expand Down
80 changes: 80 additions & 0 deletions docs/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
# Validation schemas

The package `@windingtree/org.json-schema` provides a following set of validation schemas based on [json-schema](http://json-schema.org/specification.html) standard.

- `ORG.JSON`: base ORG.JSON schema
- `ORGiD VC`: generic verifiable credential schema
- `ORG.JSON VC NFT`: verifiable credential with ORG.JSON subject and NFT extension
- `Trust Assertion Credential`: verifiable credential with Trust Assertion subject
- `NFT Metadata`: base NFT metadata schema

## Installing the package

```bash
yarn add @windingtree/[email protected]
```

## Import of schemas

```typescript
import {
org as orgJsonSchema,
vc as verifiableCredentialSchema,
orgVc as orgJsonVcNftSchema,
trustAssertion as trustAssertionSchema,
nft as nftMetaDataSchema
} from '@windingtree/org.json-schema';
```

## Using schema for a data validation

> For the validation the ready-made `validateWithSchemaOrRef` utility from the `@windingtree/org.id-utils` package can used. Under the hood this utility is uses a powerful [`ajv`](https://github.com/ajv-validator/ajv) package.
```typescript
import type { ORGJSON } from '@windingtree/org.json-schema/types/org.json';
import { org as orgJsonSchema } from '@windingtree/org.json-schema';
import { object } from '@windingtree/org.id-utils';

export interface OrgJsonValidatorConfig {
schema: ORGJSON;
path: string;
}

const orgJson = { /* ... */ }; // raw data object

const validationResult = object.validateWithSchemaOrRef(
orgJsonSchema,
'', // empty because we do not use a specific reference from the schema
orgJson as ORGJSON
);

if (validationResult !== null) {
throw new Error(
`Validation error: ${validationResult}`
);
}
```

## Typings

> Each schema definition has a huge subset of children schemas that can be imported as a separate type.
> Below you can see examples of import of major types. To get detailed information about all available types please review types definition files using your IDE.
```typescript
import type { ORGJSON } from '@windingtree/org.json-schema/types/org.json';
import type { ORGiDVC } from '@windingtree/org.json-schema/types/vc';
import type { ORGJSONVCNFT } from '@windingtree/org.json-schema/types/orgVc';
import type { TrustAssertionCredential } from '@windingtree/org.json-schema/types/trustAssertion';
import type { NFTMetadata } from '@windingtree/org.json-schema/types/';
```

## Schemas

- [ORG.JSON schema](org-json.md)
- [ORGiD VC schema](vc.md)
- [ORG.JSON VC NFT schema](org-json-vc-nft.md)





144 changes: 144 additions & 0 deletions docs/org-json-vc-nft.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,144 @@
# ORG.JSON VC NFT schema

DID documents that are built on the base of ORG.JSON specification to be verifiable must be protected from unauthorised changes with the usage of the verifiable credential method.

The ORGiD SDK has a function for the creation of VC (`createVc`) that accepts adding of DID documents as a credential subject for VC. Also, because every ORGiD has to provide NFT metadata to be a valid NFT this VC creation function also provides a method of adding such metadata.

A digital document created by this function will be a valid VC document and NFT metadata source that can be validated using the schema proposed by this package.

The example of the VC with DID document as a credential subject and NFT metadata:

```json
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://raw.githubusercontent.com/windingtree/org.json-schema/feat/new-orgid/src/context.json"
],
"id": "c48aba97-c92b-4189-8546-184112f0ebff", // <-- unique credential Id
"issuer": "did:orgid:4:0x57b...ad94", // <-- credential issuer
"type": [
"VerifiableCredential", // <-- base credential type
"OrgJson" // <-- ORG.JSON VC type
],
"issuanceDate": "2021-06-03T13:20:06.398Z",

// time restrictions (from, until, expire)
"validFrom": "2021-06-04T00:00:00.000Z",
"validUntil": "2021-12-04T00:00:00.000Z",
"expirationDate": "2022-01-01T00:00:00.000Z",

"credentialSubject": { // ORG.JSON as credential subject
"id": "did:orgid:4:0x57b...ad94",
"created": "2021-03-03T13:20:06.398Z",
"updated": "2021-04-03T13:20:06.398Z",
"verificationMethod": [
{
"id": "did:orgid:4:0x57b...ad94#key1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:orgid:4:0x57b...ad94",
"blockchainAccountId": "0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:4"
}
],
"legalEntity": {
"legalName": "Acme, Corp.",
"alternativeName": "Acme",
"registryCode": "US12345567",
"identifiers": [
{
"type": "IATA",
"value": "123456"
}
],
"legalType": "GmBH",
"registeredAddress": {
"country": "CZ",
"subdivision": "71",
"locality": "Jihlava",
"postalCode": "71354",
"streetAddress": "3150 Main St.",
"premise": "STE 100"
},
"locations": [
{
"name": "Main Office",
"description": "This is our main office",
"address": {
"country": "CZ",
"subdivision": "71",
"locality": "Jihlava",
"postalCode": "71354",
"streetAddress": "3150 Main St.",
"premise": "STE 100",
"gps": "50.087070,14.417210",
"geocodes": [
{
"type": "olc",
"value": "3CQ9+F2 Prague"
},
{
"type": "what3words",
"value": "printers.torn.images"
}
]
},
"openingHours": [
{
"weekDay": "mon,tue,wed",
"hours": "9:00-18:00"
},
{
"weekDay": "fri",
"hours": "10:00-16:00"
}
],
"contacts": [
{
"function": "Reception",
"name": "John Smith",
"phone": "+1234567890",
"email": "[email protected]",
"messengers": [
{
"type": "whatsapp",
"value": "+1234567890"
},
{
"type": "telegram",
"value": "acme.ny.reception"
},
{
"type": "viber",
"value": "+1234567890"
}
]
}
]
}
],
"contacts": [
{
"function": "Customer Service",
"name": "John Smith",
"phone": "+1234567890",
"email": "[email protected]"
}
]
}
},

// NFT metadata
"name": "Acme",
"description": "Acme, Corp.",
"image": "https://examle.com/path/to/image.png",
"external_url": "https://examle.com",

// VC proof
"proof": {
"type": "EcdsaSecp256k1Signature2019", // <-- proof signature cryptographic suite
"created": "2021-06-03T13:20:06.398Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:orgid:4:0x57b...ad94#key1", // <-- verification method
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..." // <-- proof signature
}
}
```
Loading

0 comments on commit f3a2fd8

Please sign in to comment.