OLD PoC Docs
Overview
Development Environment
The OBADA development environment in AWS includes the OBADA "TestChain" blockchain simulator, API's for decentralized permissioning of users, and APIs for asset management and data storage, currently being maintained by OBADA staff.
Founding Stakeholders: Requirements & Funding
The Pilot Program requires a shared ecosystem to be tested. Founding Stakeholders will each need:
A hosted development environment to test the APIS
A technical resource capable of connecting predefined APIs with their internal systems. Phase 1 does not require any specific "blockchain knowledge". It is simply to connect APIs using standard web interfaces. Future phases may (or may not) require more complex technical capabilities.
Total implementation time 4-8 hours + test & debug.
To share in paying for OBADA costs associated with developing and maintaining the APIS and development infrastructure.
Pilot Program Phases
Phase 1 of the Pilot Program is a "horizontal approach" to "connect" registrars and users using these APIS to create the foundational permissions layer needed for future phases. Phase 2 will be to add the "asset layer" to manage the devices, and in Phase 3 an "events layer" will connect the organizations servicing of these devices. Proceeding with this horizontal approach is far more efficient than the previous approach of developing disconnected "Vertical pilots" on different steps and timelines.
Second Pilot Program (2020)
Once the environment for the ecosystem is established, a new pilot will extend the functionality to include the use of Digital Assets to enable Sustainability Initiatives such as an "e-waste offset", and to enable service providers to charge transaction fees, a small portion of which can be collected to run the ecosystem.
Intellectual Property
All OBADA work is open-sourced and standards based. Nothing is confidential. If any Pilot Participant has actual knowledge of a confidential information or a patent claim which the individual believes is related, they must disclose the information or recuse themselves from the group.
Primary Use Case for Phase 1
The main "use case" for the first pilot is to implement API's compliant with the "Proof of Concept" (PoC) project of US Customer and Border Protection.
Founding Stakeholders ASCDI and World Data Products (WDPI) are long standing members of the Commercial Customs Operations Advisory Committee (COAC), a stakeholders group advising US Customs Border Protection (CBP). The CBP PoC is a pilot program to verify an importer rights at the border using blockchain.
The current phase of the CBP PoC implements APIs using emerging standards to allow entities to verify and supply credentials to one another, which aligns with OBADAs Pilot Program. Although the CBP plan is confidential and under NDA with lead pilot participants, this foundational layer is based on standards so the framework developed for this phase of the PoC can use the same code as the OBADA Protocol, and can be shared with all OBADA participants.
Pilot Roadmap
Phase 1: Identity Management (people & organizations)
July 2019
Development Environment Established (done)
API's created and documented (in process)
Initial participants meeting the above requirements are identified and given information and credentials to access the dev environment. (in process)
August 2019
Pilot Participants install code and test APIs against OBADA TestChain
Phase 2 plans developed
Phase 2: Asset Management (physical things)
September/October 2019
Similar to Phase 1 (tbd)
Phase 3: Tracking Events (what happens to these things)
Q4 2019
Similar to Phase 1 (tbd)
Phase 4: Compliance & Reporting
2020
tbd
FUTURE: Sustainability Initiatives, Fungible Device Handling, Smart Contracts, etc..
2020-2025
Roles & Participants
Three roles are needed for the permissions layer; the Registrar who maintains a "list of their users". Their users which form the second role, the Owner of a device. The Owner needs to obtain an OBADA Compliance Credential from the registrar in order to use the OBADA Blockchain. The final role is the Verifier, any person or utility that needs to verify the Owner's identity and/or OBADA Compliance Credential. The Validator could be an individual, an outside blockchain (such as CBP or BiTA), or the OBADA Blockchain itself.
The above terminology comes from OBADA. The proposed standards and CBP each use different terminology as shown:
Terminology: OBADA / "W3C" / "CBP"
OBADA Development
Contact: Rohi Sukhia, Developer: Andrii Tarykin
Registrar / "Issuer" / "Rights Holder" Role
Primary Stakeholder
ASCDI , Del Rey Beach, FLA (contact: Joe Marion, developer: Dennis Hurst)
Other Stakeholders
e-Reuse.org, Barcelona, Catalonia, Spain
TechBroker, Saratoga Springs, NY
The Broker Site, Breda, Netherlands
Tradeloop, Boston, MA
Reverse Logistics Association
SERI
Potential Stakeholders
Backmarket (NYC)
BrokerBin (MN)
Electronics REcyling.org (Jason Linnel) ?
ERN (Electronics Reuse Network) (Chicago)?
Free ICT Europe (Netherlands)?
ITAD Coalition (Washington, DC)?
Repair.org (NY)?
SDD Africa (Sustainable Digital Development) ?
Owner* / "Holder" / "Importer" Role *"e.g. device owner" - is there a better name?
Primary Stakeholders
WDPI (contact: Neil Vill, developer: Nevin Lee )
Other Stakeholders
Good Point Recycling (Vermont)
VIG Computers (Canada)
Potential Stakeholders
Any other OBADA "user" can participate as an owner. (ITADs,Recyclers, etc)
Validator (general function)
Main Partipant
OBADA TestChain endpoint
CBP PoC endpoint (ASCDI/WDPI only)
Founding Stakeholder
Brennick endpoint
Phase 1 Architecture Diagram
Business Logic - Functional Steps for Verifying a Credential (in order)
1. Establish DID Identifiers for all parties
OBADA establishes an 'Issuer DID on "some blockchain"
Owner establishes a DID on "some blockchain"
Registrar establishes an 'Issuer DID on "some blockchain"
1b. All parties store their Link Secrets in a Wallet
2. OBADA authorizes Registrar
OBADA issues a Verified Credential to Registrar
Registrar accepts and stores Verified Credential in Wallet
Notes:
This step is likely a "one time" job to set up each Registrar.
It will be possible to later implement a method so OBADA can revoke the Registrar's Verified Credential
3. Registrar authorizes Owner
Registrar issues a Verified Credential to Owner using process above.
Owner needs to store Link Secret in Wallet
Credential simple indicates is_approved
Later, additional information can be added by defining different "statuses"
4. Verifier approves Owner
Owner signs Verified Credential (with Link Secret) and supplies Signed Verified Credential to Verifier
Verifier checks DID's/Signatures and approves or denies
Implications
Owner does not need to reveal their identity to Verifier. They can be verified as "complaint" while still remaining anonymous.
Owner could prove their contact info via optional information supplied by the Registrar.
Technical Details
Standards and Languages
Phase 1 APIs will adhere to the emerging W3C standards for Decentralized Identifiers (DiDs) and the Verified Credentials Data Model.
Specs
Specs and software will be made available shortly for test, either here or in Github, linked from here.
The only libraries and practical examples available for the these standards are written in javascript, so the first OBADA SDK is in javascript. Data will be transferred according to the standard JSON-LD data format.
Use of a SSI Network (Self-Sovereign Identity Network)
DiD's typically rely on a blockchain known as a "SSI Network" to store the DiD and return a proof document and several public utilities have been formed for this purpose. For the Pilot Program, we will define a simple namespace in the OBADA TestChain as the "OBADA DiD Network"
Eventually, the OBADA Technical Working Group and OBADA Governance will need to decide if OBADA should enable our own DiD Network, should utilize a public utility, or should institute a best practice to require entities to choose their own complaint DID Network.
Last updated