discernible-io

Posted on Jan 10 • Edited on Nov 10

Rich Online Digital Tokens Whitepaper

#rodit #api #blockchain #nearprotocol

Executive Summary

This whitepaper introduces Rich Online Digital Tokens (RODiT), a novel approach to authentication, configuration, and licensing for online services leveraging non-fungible tokens on blockchain. RODiT address several key challenges compared to traditional methods like digital certificates and public key cryptography:

Simplified configuration, licensing, and authentication processes
Prevention of rogue credential issuers
Streamlined issuing and secure delivery of credentials
Seamless key rotation independent of license expiration
Robust protection against man-in-the-middle attacks

RODiT embed metadata like configuration settings, license terms, and authentication claims into unique blockchain tokens. This allows seamless integration of these processes when purchasing online services. The paper provides an overview of RODiT and their implementation on the NEAR blockchain protocol.

Key benefits of RODiT include reduced complexity/cost, enhanced security, scalability, flexibility in licensing models, support for reselling and white-labeling services. RODiT can enable new solutions across sectors like finance, healthcare, government, telecommunications, and industrial IoT applications requiring strict security.

Introduction

The technology explained in this whitepaper builds on existing technologies and a simple idea: Blockchain-based non-fungible tokens are unique and can´t be cloned, therefore they can be used as authentication keys, ensuring that only the key holder can access what is protected.

Please note there is no relation between our use of non-fungible tokens and what is popularly known as NFTs (expensive unique tokens that have a URL pointing to some digital asset), except using the same underlying technology.

Thin and Rich Credentials

Most authentication methods have two parts, an ID and a credential (a password, a token, etc) but don’t carry any associated info, like configuration or licensing options, claims or addresses, they are what we could call Thin Credentials. Adding or associating configuration or licensing, claims or addresses is performed in separate registration, configuration and licensing processes per Service Provider (a cloud service, a website, a system), in order to gather all the necessary information to provide the service. Using an email address as a credential ID is a very frequent practice that makes thin credentials ever so slightly richer.

If we had credentials that could carry all the configuration, licensing, claims or addresses necessary to interact with Service Providers, that we can call Rich Credentials, that would make registration, configuration and licensing processes simpler or even unnecessary. Instead of having all this information permanently stored by the Service Provider, parts of it contained in the Rich Credential could be shared only when necessary.

Among the several techniques used for authentication, the one that most closely resembles a Rich Credential is the Digital Certificate. It can carry for example Subject Alternative Names, like IP addresses or domain names. In practice, there are few implementations if any that carry configuration or licensing options.

In 1988 the International Telecommunication Union (ITU) published the first version of the X.509 standard for Digital Certificates, which defined the format and syntax of digital certificates. Back in the day continuous and ubiquitous access to the Internet was not common, so one of the requirements in the design was to be able to validate the Digital Certificate while offline. While this requirement is still available as originally designed, some modern features of Public Key Infrastructure (the governance framework for Digital Certificates) can only be used online, for example OCSP. Digital Certificates have not been updated significantly since 2008 (or 1999 you may argue), coincidentally the year of the publication of “Bitcoin: A Peer-to-Peer Electronic Cash System”.

Rich Online Digital Tokens

In this paper we introduce the use of Rich Online Digital Tokens (RODiT), custom non-fungible-tokens that can carry configuration, licensing, claims, and addresses information, as a practical and modern alternative to digital certificates that can be used for mutual authentication, configuration of endpoints and licensing of online services, among other use cases.

Audience

This paper will be of interest for anyone who designs online services (Service Providers).

Problem Statement

There are several problems that can be addressed using RODiT:

Configuration, Licensing and Authentication Complexity and Cost. Both Digital Certificates and Thin Credentials in use require separate registration, configuration and licensing processes that can be become costly and complex in scenarios with strict security requirements.
Rogue Issuers: There is no current fail proof mechanism to prevent the unauthorized issuance of certificates by Certificates Authorities. Participants in Certificate Transparency can monitor and detect unauthorized issuance, but can´t prevent it. Generally speaking Service Providers that use Digital Certificates don´t currently have an effective mechanism to declare which Certificate Authorities (Issuers) they trust, opening the door to well known vulnerabilities in the use of digital certificates (See [1], [2] [3] [4] and [5]). RODiT uses a mechanism whereas domains used by Service Providers must declare what Issuers (that are smart contracts) are trusted to issue valid RODiT for them.
Issuing and Delivering Credentials: When implementing mutual authentication with Digital Certificates, the workflow has several steps that require endpoint access and file transfer of a CSR file between the endpoint and the CA, and a Digital Certificate file between the CA and the endpoint. In order to simplify digital certificate generation and distribution, some implementations generate the CSR and Digital Certificate in a central point, instead of generating the key pairs in the endpoints, which make the private keys far more likely to be compromised. Using RODiT there are no file transfers, as the RODiT is sent to a blockchain address. The impact of using RODiT and its simple issuing and delivery workflow becomes highly significant as the number of participant endpoints grows.
Key Rotation: With Digital Certificates, key rotation requires issuing, transferring and installing a new digital certificate when the key is due to be rotated, regardless of the expiration date of the service being secured with the digital certificate. Expiring digital certificates have caused major incidents worldwide (See [6] and [7]). Using RODiT, key rotation is decoupled from license expiration, as it does not require issuing a new RODiT. Besides, key rotation can be performed independently for every endpoint, without any coordination between endpoints, greatly simplifying management of key rotation. Again, the impact of using RODiT and its simple key rotation workflow becomes highly significant as the number of participant endpoints grows.
Man in the middle (MiTM): This type of attack occurs when a malicious third-party intercepts and alters messages between two unsuspecting parties, potentially stealing confidential information or making unauthorized changes. Despite the risks, mutual authentication is not widely used because of the perceived security provided by other methods and the practical difficulties associated with implementation of mutual authentication for large number of endpoints or large user bases. Using RODiT mutual authentication is simple to implement, providing strong protection against MiTM attacks.

Overview of RODiT

Let’s spell R.O.Di.T out.

RODiT are Rich because they have configuration and licensing information (not meta information) that is immediately useful.
RODiT are Online, because they are used while connected to the internet, unlike traditional digital certificates that can operate offline.
RODiT are Digital to remind you that they are similar in functionality to Digital certificates, and finally;
RODiT are Tokens because they are unique and they can be bought and sold.

RODiT address, among other features, the following problems:

Configuration, Licensing and Authentication Complexity and Cost

RODiT tokens follow a default structure detailed in Appendix I, and can accommodate extra data fields as necessary for each use case. By including configuration and licensing info in the RODiT, when you purchase a subscription to an online service, at the same time you get your authentication mechanism and your configuration.

Providing a RODiT to an endpoint handles as a unit the licensing, configuration and authentication processes, great simplifying the complexity and costs associated with large user bases with high security requirements.

Rogue Issuers

In a triangle of trust, Issuers of credentials trust Service Providers, Service Providers trust Issuers and Users trust them both. RODiT uses a simple mechanism based in DNS so trust can be determined, Service Providers indicate if they trust particular Issuers, Issuers can indicate if they trust Service Providers, and Service Providers can indicate if they trust user credentials. If a Issuer misbehaves, Service Providers can withdraw trust, if a Service Provider misbehave, Issuers can withdraw trust, and if a User misbehaves, Services Providers can withdraw trust.

Service Providers must have an associated domain name, and in order to issue RODiT using a particular smart contract, they have to authorize explicitly the Issuer blockchain account that controls the smart contract; otherwise the endpoints will reject the RODiTs issued. This is a DNS entry for the domain authorizing the smart contract controlled by the rodit-org.near wallet (for example) to issue RODiT for the discernible.io Service Provider (for example):

rodit-org.near.smartcontract.discernible.io TXT “whatever”

Issuing and Delivering Credentials

The process takes the following steps in a commercial setting:

Service Providers use a RODiT minter service to generate as many RODiT as necessary for their systems, sent to an address which will distribute them later from the RODiT Point of Sale.
Endpoints generate locally key pairs, and initialize them in the blockchain.
Endpoints present the public key upon purchase of a RODiT in the Point of Sale, and obtain the RODiT that is sent to the blockchain address (the public key) in exchange for payment.

Endpoint access or file transfers are unnecessary, and the private key is generated in the locally endpoint with the obvious security implications.

Key Rotation

The process takes the following steps:

Endpoint generates a new key pair, and initialize it in the blockchain.
Endpoint sends the RODiT to the newly generated blockchain address (public key).
Optionally, the old key pair can be deleted.

Key lifetime is independent of the duration licensed for the service, can happen with whatever frequency that is adequate for the use case, and does not need to be synchronized with the key rotation of any other endpoint.

Man in the middle attack (MiTM)

When using RODiT, mutual authentication if the default mode, thanks to the scalability and simplicity associated with being able to set up endpoints independently and rotate key pairs asynchronously. In combination with mutual authentication (RODiT are digitally signed), local generation of key pairs, and compulsory authorization of the smart contract used to issue RODiT makes MITM extremely hard, if not impossible, to achieve.

Each side of every communication performs the following checks on the other end:

Are we presented with a Live or Revoked RODiT
Is the RODiT Genuine, is the peer`s signed with the same private key our own RODiT was signed with.
Is the peer endpoint in Possession of the RODiT at this point in time.
Is the RODiT Issuer Live or Revoked.
Is the subscription Active or Expired.
The RODiT can inform about additional use cases like scopes/permissions, authorized networks, locations, transactions per second, bandwidth, etc.

These checks, plus the implementation of the triangle of trust, and mutual cryptographic authentication and implementation of the Noise protocol framework provide a very effective protection against man in the middle attacks.

NEAR Protocol

NEAR Protocol is a blockchain platform designed to simplify the user experience and make blockchain technology more accessible. It aims to achieve this through several key strategies:

Chain Abstraction: NEAR Protocol simplifies the complex workings of blockchain technology into more understandable layers, making it accessible to developers, users, and stakeholders. These layers include the protocol layer, network layer, data layer, and smart contract layer.
Sharding: NEAR Protocol uses sharding to process transactions in parallel, enhancing scalability and making the blockchain’s complexity transparent to users. The blockchain is divided into four shards, each capable of processing 1,000 transactions per second.
Dynamic Resharding: This feature allows for the creation and destruction of shards based on demand, ensuring scalable and efficient network performance.
Human- Readable Account Names: NEAR Protocol uses easy-to-remember account names instead of complex addresses, simplifying transactions and interactions on the blockchain.
Access Keys with Permissions: Users can grant specific permissions to DApps, improving security and usability.

NEAR Protocol is the blockchain selected for the RODiT implementation, driven by a combination of technical, economic, and strategic advantages that the protocol offers, among them:

Developer- Friendly. NEAR provides a robust and user-friendly development environment, which simplifies the process for developers to build, deploy, and maintain applications. This ease of development can accelerate the creation and enhancement of the RODiT platform.
Affordable Token Creation. The cost of creating tokens on NEAR is significantly lower compared to other blockchains. This makes it economically viable for users to mint and manage tokens without prohibitive fees, encouraging wider adoption and usage.
Zero Cost of Token Verification. Verifying ownership and control of tokens on NEAR is essentially free, which helps in maintaining transparency and trust without additional costs.
Reliability and Minimal Downtime. NEAR Protocol is designed for high reliability, ensuring minimal downtime. This means that applications built on NEAR, including RODiT, can offer consistent and dependable service to their users.
Incentives for Network Health. NEAR incentivizes its participants to maintain the health and functionality of the blockchain. This ensures a robust and active network, supporting the continuous and stable operation of the RODiT platform.
Scalability and High Performance. NEAR is built to handle a high volume of transactions efficiently, ensuring that the RODiT platform can scale as its user base grows without compromising on performance.
Decentralization and Resilience. Being a decentralized platform, NEAR operates without a central authority. This ensures that the RODiT implementation cannot be easily shut down or censored, providing resilience and autonomy to its operations.
Jurisdictional Independence. NEAR’s decentralized nature means it operates beyond specific jurisdictions, reducing the risk of regulatory interference and providing a global reach for the RODiT platform.
Proof of Stake (PoS) instead of Proof of Work (PoW). NEAR Protocol operates on a Proof of Stake consensus mechanism, which is more energy-efficient compared to Proof of Work. This makes NEAR an environmentally friendly option, reducing the carbon footprint associated with blockchain operations.
Accessible Token/Cryptocurrency. NEAR’s tokens are easy to purchase and manage, ensuring that users can seamlessly participate in the RODiT ecosystem without facing barriers related to acquiring or using the native cryptocurrency.

By leveraging these advantages, the NEAR Protocol provides a strong foundation for implementing RODiT, ensuring it is cost-effective, reliable, secure, and scalable, while also being environmentally conscious and user-friendly.

Technical Details of Mutual Authentication

Endpoints determine if they are presented with a Live or Revoked RODiT by checking if there is a match for the RODiT and a DNS entry following this format: roditID.revoked.serviceproviderdomain. If the entry exists, the authentication fails.
Endpoints determine if the RODiT is Genuine, by checking if the peer`s RODiT signature found in the serviceprovidersignature was signed with the same private key the endpoint`s own RODiT was signed with. If it does not match, the authentication fails.
Endpoints determine if the peer endpoint is in Possession of the RODiT by checking if the RODiT ID signature provided has been signed with the key pair that owns the peer`s RODiT in the blockchain at this point in time. If it does not match, the authentication fails.
Endpoints determine if the peer`s RODiT Issuer is Live or Revoked by checking if there is a match for the RODiT and a DNS entry following this format: issuerdomain.near.smartcontract.serviceproviderdomain . If the entry does not exist, the authentication fails.
Endpoints determine if the subscription Active or Expired by checking if the current time is between the notafter and notbefore fields of the peer`s RODiT, unless the fields are nul, indicated by the value 1/1/1970. If not Active, the authentication fails.
The RODiT can inform about additional use cases like scopes/permissions, authorized networks, locations, transactions per second, bandwidth, etc.

Key features and benefits

Besides the problems addressed, there are some additional benefits from using RODiT tokens, as token holders can:

Sell RODiT at any point during the subscription period to other users. Using other licensing methods selling a partially used subscription is not common or straightforward.
Swap a RODiT with other users for enhanced anonymity.
Dispose of a RODiT sending it to a disposal address.
Renew or a subscription obtaining a discount by returning the previous RODiT, or obtain a rebate for returning an subscription before expiration.

RODiT have some security benefits in comparison to other authentication methods as:

RODiT can`t be shared between users without risk losing them. This leads to less credential sharing among end users of any Service.
If the RODiT`s blockchain account is compromised it is easy to detect, as the only way to keep exclusive control by the attacker is by moving it to a new blockchain address. If the attacker does not move the RODiT, it risks losing it as the RODiT owner can move it to a new blockchain address at any time.

Using RODiT can lead to new commercialization practices by Service Providers as:

Service Providers can delegate sales and distribution to third parties and resellers easily, by providing stocks of RODiT tokens.
Service Providers can let resellers sell the services with their own brand, “white label”.

RODiT metadata is easily extensible and can cater for custom needs around licensing conditions, permissions (scopes), security boundaries like authorized locations or networks, and other business cases that can be complex to implement using separate licensing, authentication and configuration processes.

Reasons to use a Blockchain

The reasons for using a blockchain instead of a database are the following:

User control and privacy: Individuals can have more control over their RODiT than they would have with traditional credentials. They can buy RODiT, exchange them, sell them, and renew them without ever having to reveal their identity.
Decentralization: No single central authority controls the authentication process, reducing the risk of a single point of failure. This also means that small providers can enjoy and high availabilty infrastructure without having to create their own.
Reduced fraud: The fact that RODiT have a cost creates a higher barrier of entry for any potential attackers.
Interoperability: Using inter domain trust relationships, RODiT can be reused across multiple systems and platforms.

Use Cases and Applications

RODiT can be leveraged for may uses cases, particularly when there is a need to cater for strict anonymity or security requirements with large number of endpoints. To name a few:

As a replacement for SSH Certificates
Financial Services APIs: Banking, Payment Processing, Cryptocurrency exchanges
Healthcare APIs: Electronic Health Record (EHR), Medical Device, Telehealth
Government and Legal Services APIs: Identity Verification, Document Management, Tax and Financial Reporting
Telecommunications: Messaging applications
E-commerce APIs: Customer Information, Inventory and Order Management
Cloud Service Provider APIs: Storage, Compute

RODiT are particularly suited for Industrial and Internet of Things (IoT), as there RODiT can be send to endpoints remotely without accessing the endpoints.

Implementing RODiT can have a big impact in the provision of most online services, particularly:

Environments at risk due to government sponsored espionage and sabotage.
Environments where anonymity and security are paramount, like investigative journalism, due to the need to protect whistleblowers and other sources.
Environments where may need strong authentication in peer to peer messaging, as RODiT mutual authentication is suited to peer to peer validation.

Market Analysis

The overall market value for internet and cloud services in the relevant sectors is as follows:

VPN Services: The global VPN market size is expected to reach USD 43.3 billion by 2027, growing at a CAGR of 14.1% from 2022 to 2027.

SSH Certificates: The global SSH market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 12.1% from 2022 to 2027.

Financial Services APIs: Banking, Payment Processing, Cryptocurrency exchanges:

The global banking APIs market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 15.1% from 2022 to 2027.
The global payment processing APIs market size is expected to reach USD 2.1 billion by 2027, growing at a CAGR of 14.3% from 2022 to 2027.
The global cryptocurrency APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 14.5% from 2022 to 2027.

Healthcare APIs: Electronic Health Record (EHR), Medical Device, Telehealth:

The global EHR APIs market size is expected to reach USD 1.3 billion by 2027, growing at a CAGR of 14.2% from 2022 to 2027.
The global medical device APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.4% from 2022 to 2027.
The global telehealth APIs market size is expected to reach USD 1.5 billion by 2027, growing at a CAGR of 15.6% from 2022 to 2027.

Government and Legal Services APIs: Identity Verification, Document Management, Tax and Financial Reporting:

The global identity verification APIs market size is expected to reach USD 1.2 billion by 2027, growing at a CAGR of 13.9% from 2022 to 2027.
The global document management APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.2% from 2022 to 2027.
The global tax and financial reporting APIs market size is expected to reach USD 1.3 billion by 2027, growing at a CAGR of 14.5% from 2022 to 2027.

Telecommunications: Messaging applications:

The global messaging APIs market size is expected to reach USD 2.3 billion by 2027, growing at a CAGR of 14.5% from 2022 to 2027.

E-commerce APIs: Customer Information, Inventory and Order Management:

The global e-commerce APIs market size is expected to reach USD 2.5 billion by 2027, growing at a CAGR of 15.3% from 2022 to 2027.
The global customer information APIs market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 14.1% from 2022 to 2027.
The global inventory and order management APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.4% from 2022 to 2027.

Cloud Service Provider APIs: Storage, Compute; Internet of Things and SCADA systems:

The global cloud storage APIs market size is expected to reach USD 2.2 billion by 2027, growing at a CAGR of 14.8% from 2022 to 2027.
The global cloud compute APIs market size is expected to reach USD 2.5 billion by 2027, growing at a CAGR of 15.5% from 2022 to 2027.
The global IoT APIs market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 14.3% from 2022 to 2027.
The global SCADA APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.2% from 2022 to 2027.

See references [10], [11], [12], [13] and [14]

Future Outlook

RODiT can be used to improve how many online services are provided, for example:

Currently there are not standard methods so users can delegate in AI agents tasks using their online services. Using RODiT can help designing solutions that will cater for this need.
Currently there are no standard methods to validate the identity of someone who is using an online service. Deepfakes can fool us via voice and video. Using RODiT could help creating a mechanism so people presence could be securely validated online.
RODiT could be used so operating systems can validate the hash of any executable before running it by matching it with a published RODiT ID for the specific executable version in a public blockchain.

Some areas need additional work in order to enable the implementation of services that use RODiT:

RODiT data is public in the blockchain. Some use cases will require the encryption of some of the information in the RODiT.
Different operating systems have different secrets store facilities. These could be leveraged to store RODiT controlling key pairs securely.
The triangle of trust can be enhanced with Issuer to Issuer and Service Provider to Service Provider trust handshakes. This could lead to RODiT becoming reusable across services.
RODiT could be implemented for other blockchains with suitable technology besides NEAR Protocol.
As of today, cryptographic wallets don´t display RODiT info and it is limited to the Linux command line. Further development is needed to implement RODiT solutions for other operating systems, and standards need to be agreed so cryptographic wallets can display RODiT information.

Conclusion

Rich Online Digital Tokens (RODiT) represent a significant innovation in how online services can approach authentication, configuration, and licensing. By leveraging blockchain non-fungible tokens to encapsulate these critical elements, RODiT provide a unified, simplified, and secure solution compared to traditional methods.

Key advantages of RODiT include:

Reducing complexity and costs by consolidating authentication, configuration, and licensing into a single token
Preventing rogue credential issuers through a verifiable trust model
Enabling seamless issuing and secure delivery of credentials to endpoints
Allowing independent key rotation decoupled from license expiration
Robust mutual authentication and protection against man-in-the-middle attacks

With a vast array of potential use cases across sectors like finance, healthcare, telecommunications, ecommerce, and industrial systems, RODiT open up new possibilities for innovative online service models prioritizing security, privacy, and seamless user experiences.

Final Thoughts

While this whitepaper focuses on the core concepts and technical implementation, the true potential of RODiT extends far beyond what is covered here. RODiT represent a paradigm shift in how we approach digital authentication, identity, and trusted interactions in an increasingly connected world.

As blockchain technologies and decentralized solutions continue evolving, RODiT could pave the way for new models of digital identity, verifiable credentials, and secure data exchange. The flexible nature of RODiT metadata allows expanding use cases into areas like digitally signing documents, validating software executables, and enabling secure AI delegation models.

Moreover, RODiT’s ability to facilitate new licensing approaches, such as friction less reselling, white-labeling services, and innovative pricing models, could disrupt traditional business models for online services.

Ultimately, RODiT exemplify the power of blockchain to reshape digital ecosystems, offering a glimpse into a future where security, trust, and user experiences are seamlessly intertwined through innovative decentralized solutions. As developers and businesses continue exploring RODiT’s possibilities, we may witness a transformative impact on how we interact, transact, and navigate the digital landscape.

References

Appendix I — RODiT Data Structure

Field Name	Description	X.509 Equivalent	Type and Format	Default value and Valid Range
token_id	Unique ID of the token, must be randomly generated	Serial Number	String	For Service Provider is a String like SMARTCONTRACTID;id=ULIDOFTHESERVICEPROVIDER, For Node is a String like: id=ULID
issuer_name	Your Service Provider Name	Issuer Name	String	No default value / IT CAN BE EMPTY
description_rodit	Description of your Service Provider	Not Applicable	String	No default value / IT CAN BE EMPTY
not_after	Date of Expiration of Service	Not After	ISO 8601 YYYY/MM/DD	Default value one year from today’s day, must be greater than not_before, and must take the value 1970/1/1 for “any”
not_before	Date of Start of Service	Not Before	ISO 8601 YYYY/MM/DD	Default value today’s date, must take the value 1970/1/1 for “any”
subjectuniqueidentifier_url	Service Provider URL	Subject Unique Identifier	URL to guarantee it is unique and controlled by a single entity	No default value, IT CAN NOT BE EMPTY
serviceprovider_id	Service Provider ID	Not Applicable	String likeid=ULID or SMARTCONTRACTID;id=ULID	For Service Provider is: ULIDOFTHESERVICEPROVIDER, For Node is a String like SMARTCONTRACTID;id=ULIDOFTHESERVICEPROVIDER
serviceprovider_signature	Ed25519 digital signature signed with the Private Key in Base58	Certificate Signature	String of length 64	No Default, Ed25519 digital signature (SHA384WITHECDSA), signed with the Private Key in Base58

DEV Community