Everything you need to know about ORG.ID

ORG.ID is a global decentralized business registry that streamlines the burdensome process of verifying identities between business entities.

It’s similar to government-maintained registries except for the whole “government” thing. ORG.ID has no central authority, as it’s completely decentralized and governed by its users. By connecting organizations directly to each other, ORG.ID eliminates both the bureaucracy and the hassle of navigating dozens of different business registries worldwide, each with different standards, languages, and trustworthiness.

The decentralized, peer-to-peer approach allows for more rapid and accurate data exchange about organizations, which makes the Know-Your-Business (KYB) processes cheaper, faster, more accurate, and more secure. It’s all automated, with complete permission controls and built-in security, such as AML compliance.

ORG.ID is governed by a few key principles:

CONTROL. Users maintain complete control of their data. No one except the owner of the data can modify or delete that data. TRANSPARENT. Users can always connect directly to the platform without relying on third parties. This keeps the platform clean and transparent. OPEN SOURCE. ORG ID is based on open standards. It isn’t dependent on any proprietary standards, software, or algorithms.

Here’s the who, why, what, and how of ORG.ID.

WHO: Winding Tree

The ORG.ID project is operated under the umbrella of the Winding Tree Foundation, a non-profit based in Switzerland. The foundation develops software projects, data exchange standards, and infrastructure with the goal of advancing the travel industry, and then taking those applications to other industries as well.

The flagship product, Winding Tree, is a blockchain-based open-source travel distribution platform that makes travel cheaper for users and more profitable for suppliers by connecting supply and demand more efficiently.

To learn more about what’s ahead, check out our road map.

WHY: To streamline global business identity verification

As we were building out our original product, the Winding Tree travel marketplace, we experienced the problem that ORG.ID solves; the time-intensive and extremely frustrating process of applying for API access and having to independently verify our identity over and over again. Each time, it was a different set of standards and requirements, creating a tangled web of verifications that sucked valuable time away from developing our core product.

So we built ORG.ID to solve those frustrations for other developers — and also for the organizations, which often struggled to enable API access in a reasonable timeframe while also supporting developers in their work. With ORG.ID, organizations can verify each other, with complete confidence that the other entity is who they say they are and that their claims have been verified. No more fraud, no more back and forth.

We also experienced uneven verification processes across different departments in the same company. So we built ORG.ID to also support subsidiaries (or sID), which can be branched off the main account (or mID). These subsidiaries can then take advantage of the mID’s trust profile while also benefiting from more control over its individual profile and relationships with other entities.

A few examples of how the main/subsidiary relationships look.

WHAT: The components/mechanics of the ORG.ID platform

To understand more about how the platform functions, let’s nerd out a bit. ORG.ID has the following core technical components:

0xORG

The 0xORG standard is the smart contract interface that governs relationships between entities on the ORG.ID platform. Any smart contract that implements that interface can be a part of the ORG.ID ecosystem.

0xORG does the following:

It gives an organization (mID) and all of its functional units (sIDs) unique identifiers (e.g. 0xa13c0e29da46c822045ab0fecde41e1d3d29c11c). These unique IDs are what we call the ORG.ID. It points to the relevant ORG.JSON (more below), which stores the bulk of data. We do this because it’s too expensive to store a lot of data on the blockchain. It keeps track of ORG.JSON changes by storing its ORG.JSON’s hash. If hashes don’t match, then the information in the ORG.JSON considered outdated or compromised, and won’t be taken into account. It stores the keys that the organization uses to authenticate itself with other companies on the platform. This supports encrypted signatures and messaging between entities. It includes any governance rules that resemble real-life use-cases. For example, an LLC owned by two equal partners can be represented by an ORG.ID owned by two Ethereum accounts via a multi-signature wallet.

Find our 0xORG canonical implementation on our GitHub.

A diagram showing the flow of 0xORG. Read more about Winding Tree smart contracts.

ORG.JSON

If 0xORG is a functional piece of an ORG.ID, ORG.JSON is the actual information record. It’s how we store and publish organizational data and trust information.

Each organization has its own file that contains each organization’s information (name, address, etc) as well as all verifiable claims and credentials. This file can be stored anywhere it can be accessed by other marketplace participants (e.g. via HTTP, FTP, Swarm, IPFS, etc.). The benefit of keeping this data off of the blockchain is cost-savings: it can be expensive to store this information on the blockchain!

To learn more, find our full ORG.JSON specification here.

DAO

The role of a Decentralized Autonomous Organization (DAO) is to govern ecosystems that do not have a central authority. It’s a smart contract that encompasses the entire ecosystem. We affectionately call ours “Thing.”

An overview of the ORG.ID protocol, which includes smart contracts and ORG.JSON.

Thing is the governing assembly that has the capability to upgrade and change the rules of Kleros Court (see next section), Entrypoint, and Líf Stake smart contracts, as well as itself. Since a successful DAO vote is always required to make changes to the Thing, the platform will always be decentralized and controlled by its participants.

Some key terms:

ENTRYPOINT. Entrypoint is a smart contract that stores a list of all the business directories in the ecosystem. A Thing DAO vote is required to add or remove business directories to the list.

LÍF. This is our staking mechanism, based on our Líf token. Each ORG.ID can stake its account in a special smart contract, which signals legitimacy, limits spam, and prevents bad actors from flooding the platform with many entities. It also allows accounts to participate in DAO votes and powers our dispute resolution process, which is covered in the next section.

LÖG TOKENS. Lög tokens allow you to create proposals and participate in DAO votes. Staking Líf also provides DAO access. Whenever you stake a minimum of Líf, A certain number of Lög tokens will be sent to the owner or agent of the ORG.ID.

BUSINESS DIRECTORIES. These are curated registries of businesses of the same type, e.g. hotels, airlines, travel agencies. Anyone can deploy a new business directory with a DAO vote. Each directory also has its own set of rules.

HOW: Managing IDs, verifying data and handling disputes

One of the biggest headaches of navigating through the account setup and API access process is having to create accounts with each potential partner. There are different interfaces and experiences, each with its own unique profile requirements. We eliminate these headaches by streamlining identity management with Arbor, our ORG.ID management tool.

Arbor is where you’ll manage everything ORG. ID. Within just a few minutes, you can create a new ID and get your company verified and live on the platform. You can also take advantage of other account benefits, such as:

edit your profile data

see your profile as others see it

manage your encrypted communications between businesses so you can establish that all messages and documents are valid and from a verified ORG.ID.

add or remove your OR. ID from a segment directory (where we organize related businesses together)

Arbor is also where you’ll add claims or credentials for verification — a critical piece of building a verifiable and verified ORG.ID. The authenticity of information associated with each profile is proven with claims and credentials:

CLAIMS are self-sufficient assertions, such as proof that the ORG.ID is associated with a certain website. These claims can be verified directly, such as by DNS record or a text file in the root directory.

CREDENTIALS are provided by a third party, such as a government or a certification authority. These will be cryptographically-signed verifications of a fact about a specific ORG.ID. The issuer of these credentials must be a trusted entity.

We’ve also built the Kleros dispute resolution tool right into the platform. Kleros provides a trustworthy, secure, and decentralized way to manage disputes, eliminating the need to have a central authority that would typically resolve these issues. This boosts trust in the platform, increases speed to resolution, and reduces costs associated with disputes. Read more on our Kleros integration.

Here’s how the dispute resolution process works, which can only be changed with a successful DAO vote.

The applicant has to make sure that their sID is compliant with the rules of the business directory they want their sID to be listed by. The applicant submits their sID by filling out a form and submitting a deposit of Líf. If no one challenges that submission during a certain time period, it means that it meets the business directory criteria, and the sID is added to the directory and the LIF deposit stays in the court’s smart contract. Anyone can challenge the submission during the challenge period or after registration. Challenger must submit a deposit to initiate the challenge process, along with the reasoning for removing the sID from the register. If the challenge process is initiated, one of ORG.ID owners must submit an arbitration fee in order to proceed to the next stage; otherwise, the challenger wins by default. This must be done within a specific time period. After the evidence collection period ended, if both challenger and applicant have submitted their arbitration fees, the deliberation process starts. The jury consists of three jurors who must cast their votes within a specific time frame in order to avoid penalties. If the challenger wins, they collect the application deposit, and their arbitration fee is refunded. The sID gets deregistered from the directory. If the applicant wins, they get their arbitration fees reimbursed, along with the challenger’s deposit. The sID stays During a challenge, the current state (submitting/registered) is kept. The submitter may unregister their registered ORG.ID, getting their LIF deposit back. This takes 1h (to avoid this to be used to front-run challengers).

Arbor is where you’ll find other businesses as well. Once you’re logged in, you’ll be able to search other businesses in a user-friendly way, making it much simpler to identify potential partners for your product or service. Businesses will be organized in segment directories, so it will be simple to browse ORG.IDs related do your specific segment.

Further knowledge

That’s the full primer for all things ORD.ID. To dive into the technical details of ORG.ID, here are our open-source resources:

***

Sign up to our newsletter to stay up-to-date with the latest. We have many exciting announcements coming in the next few months!