

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.
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
ORG.JSON Schema
ORG.JSON is a data format based on the json-schema specification used for describing organizations of all types: commercial firms, NGOs, even organizations that aren't incorporated (like W3C, 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 smart contract.
Examples
Usage
NPM package
npm i @windingtree/org.json-schema
const orgJsonSchema = require('@windingtree/org.json-schema');
Using multiple versions of schema
Define packages in your package.json
file like following:
{
"dependencies": {
"org.json-schema-0.3.1": "npm:@windingtree/org.json-schema@0.3.1",
"org.json-schema-0.3.2": "npm:@windingtree/org.json-schema@0.3.2"
}
}
and then use in your application:
const orgJsonSchema1 = require('org.json-schema-0.3.1');
const orgJsonSchema2 = require('org.json-schema-0.3.2');
JSON Schema Specification
This will generate a JSON Schema specification file in the dist
directory:
npm run build
ORGiD Ecosystem
- Winding Tree DAO controls ORGiD Registry smart contract and some Directories (including their rules)
- ORGiD Registry contains records of all organizations and organizational units
- ORG.JSON Schema (you are here)
- ORGiD Resolver is an application for resolving ORGiD data in W3C DID format
- ORGiD Directories are curated lists of organizations
- Arbor can be used to look up an ORGiD, and also to create and manage your own ORGiD