In the absence of trust . . . opportunities for mutually beneficial cooperation would have to be foregone . . . norms of social behavior, including ethical and moral codes [may be] . . . reactions of society to compensate for market failures. [1] Thus, social preferences such as a concern for the well-being of others and fair procedures remain essential to sustaining society and enhancing the quality of life.
In a world increasingly connected not just by trade in goods but also by the exchange of violence, information, viruses, and emissions, the importance of social preferences in underwriting human cooperation, even survival, may now be greater even than it was among that small group of foragers that began the exodus from Africa 55,000 years ago to spread this particular cooperative species to the far corners of the world. [2]
Humans have become more conscious of a growing interdependence between all parts of the world. The growth of the world economy followed the Great Transformation, the Services Transformation, the ICT revolution, and the adoption of free trade policies, which most countries have named the New Globalization.
A beginning to understand, though dimly, that no country is an island unto itself, but as BahĂĄâuâllĂĄh said: âThe earth is but one country, and mankind its citizens.â [3]
Without a strong guiding moral philosophy, men struggled to respond to the world's new needs as best as they could. It is accepted that the times called for a more just and dignified station for a much wider spectrum of society.
The world is nowadays dominated by a growing divide, a term that reflects the availability or unavailability of Information Technology and Communications (ICT) resources, analysed in terms of economic accessibility. This is called the digital divide.
Questions arise on how human beings can address this look for trust, worldwide, increasing digital inclusion.
The world is still dominated by two extreme visions: one that denies the radical changes in communication patterns that the ICT revolution entails and the other that denies the persistence of an economy based on the physical constraints imposed by location and the material nature of most goods and products.
The problems and opportunities detected are the advent and use of ICT to transform patterns of communication and that businesses are not fully aware of how these technologies should be used to create appropriate communication to be more productive. Communication that is acceptable for people both a customer and a human being.
Victor Frankl, facing the purpose of life, is best cured by going outside, extending the self rather than contracting it, in service to others, in upholding a value, in embracing suffering positively rather than negatively. [4]
Such service can be made more effective the more skills a person has.
Knowledge is as wings to manâs life and a ladder for his ascent. Its acquisition is incumbent upon everyone. To encourage education as much as possible in sciences which will increase the service capacity, as well as moral teachings. [5]
ICT when used properly, can increase productivity, reduce risk, and increase accessibility, specifically when people are faced with distance.
An electronic payment system based on cryptographic proof instead of trust could help when there is distance, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. [6]
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust-based model. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.
Cryptographic proof. Here is the mathematical âmagicâ of the initial Bitcoin Blockchain: the ability to assess the integrity of records and verify new data, instead of relying on the trust of a bank, the state, the law, or the authority of any other institution.
How? Cryptographic hashing is a mathematical phenomenon whereby some data is run through a hashing algorithm, which will then output a string of characters. Only this data run through this particular hashing algorithm will produce that specific string of characters. This means that if the data is tampered with in any way, this can be proven by running it through the hashing algorithm again and checking if the output is the same. Here is a cryptographic proof. [7]
Replacing âtrustâ with cryptographic proof promised to replace the uncertainty of humans and institutions with the certainty of mathematics, yet cryptographic hashing is an area of human endeavour.
Hashing is a discovery of a universal principle that all else can be anchored to; for others, it is an area of research and invention but is also an area of creativity, knowledge sharing, and collaboration amongst peers experimenting and working with the phenomena of this curious universe we live in. [6]
The Double Spending Problem. How does a decentralised network reach a consensus on which transactions are true? The solution to the double spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. [7]
The blockchain and the internet could be applied to different needs of human beings. The first need is for the individual to have agreement with peers and things.
A person as a subject represents himself/herself in various ways in computer networks. The individual may have one digital identity with one identifier, such as a domain name or subdomain, or their email address, and use another for their finances.
Digital identity is considered a challenge and difficult to verify. Proving that someone is who they say they are, especially remotely, through a digital service, is fraught with opportunities for an attacker to impersonate someone successfully. The level of risk of negative impact depends primarily on the type of digital service the person requires, and is higher for financial services, healthcare, insurance, and systems administration, among others.
For example, scenarios that allow interactions through pseudonyms, even using strong authenticators, such as multiple authentication factors, must be supported.
At the same time, the dissemination of identifying information should be minimized, requiring the identity provider (IdP) to support a range of operations to query data, such as ensuring that an individual is older than a certain age instead of querying the full date of birth.
In other cases, some institutions require individuals to be fully identified, even considering cases such as government digital services, where full identification is required. However, they also seek to limit the amount of personal information collected as much as possible.
Ruff in 2018 [8] described the evolution of internet identity.
Well-known and long used with almost all identifiers and credentials such as government ID numbers, passports, identity cards, driving licenses, social network logins, bank and telecommunications services, and many more. All of these are issued by centralized governments or service providers like banks or telecom companies. This centralized model is so prevalent that it can be divided into two types:
- Private companies (financial and telecom firms) provide centralized digital identity services to interact with the government.
- Continental model as in Europe. Governments provide digital identity services to companies allowing interaction with their citizens.
The centralized model is also the original form of internet identity - and the one that, in most cases, we still use today. You establish an identity by registering an account (typically a username and password) with a website, service, or application. This model is called account-based identity.
The main problem is that real You doesn't exist without an account in some centralized system. The real You is permitted to plug into a website, service, or application because the Organization is lending you the credentials that represent you with limited controls and permissions. Those credentials belong to the Organization. If you delete all your accounts at all these providers, your access to services will be revoked. This representation of You will disappear from the Internet. Yet all the data about you will still belong to the Organization, outside of your control. Other problems include the following:
- The burden of remembering and managing all the usernames and passwords.
- Every site enforces its own security and privacy policies.
- None of your identity data is portable or reusable anywhere.
- These centralized databases of personal data have led to some of the biggest breaches in history.
The industry developed a new model called federated identity, to alleviate the pain points of the centralized model. It is based on an identity provider (IDP) between the user and the Organization. You can just have one identity account with the IDP, and it, in turn, can log you in and share some basic identity data with any site, service, or app that uses that IDP. The collection of all sites that use the same IDP (or group of IDPs) is called a federation. Within a federation, each Organization is often called a relying party (RP).
Federated identity management (FIM) also started to catch on in the consumer internet, where it began to be called user-centric identity. Using protocols like OpenID Connect, social login buttons from social networks, and applications are now a common feature on many consumer-facing websites.
The problem with this federated identity is that it has failed to provide an internet identity layer. There are numerous reasons:
- There isn't one IDP that works with all sites, services, and apps. So users need accounts with multiple IDPs. They can forget which IDP they used with each site, service, or app.
- IDPs must have minimum common denominator security and privacy policies to serve so many sites.
- Many users and sites can be uncomfortable with having an IDP for all their relationships that can surveil a user's login activity across multiple sites.
- Large IDPs are some of the targets of cybercrime.
- IDP accounts are no more portable than centralized identity accounts.
- Due to security and privacy concerns, IDPs are not in a position to help users securely share some of their most valuable personal data: passports, government identifiers, health data, financial data, etc.
A new model, inspired by blockchain technology, first surfaced in 2014. This model no longer relied on either centralized or federated identity providers but was fundamentally decentralized. It accelerated rapidly, assimilating new developments in cryptography, distributed databases, and decentralized networks. It began spawning new decentralized identity standards such as verifiable credentials (VCs) and decentralized identifiers (DIDs).
The most important difference in this model is that it is no longer account-based. Instead, it works like identity in the real world; i.e., it is based on a direct relationship between you and another party as peers. Neither of you "provides", "controls", or "owns" the relationship with the other. This is true whether the other party is a person, an organization, or a thing.
In a peer-to-peer relationship, neither peer has an "account" with the other. Rather, you share a connection. Neither of you fully "owns" this connection.
Peer-to-peer connections are inherently decentralized because any peer can connect to any other peer anywhere -- exactly how the internet works.
Available Digital Technologies to Ensure Trust, and How They Are Applied in the Stacks Blockchain - a Bitcoin L2 Blockchain
The following parts describe available digital technologies used to ensure trust among world citizens present on the Internet, and how these technologies are applied in the Stacks Blockchain - a Bitcoin L2 Blockchain.
We must ensure that digital technology maintains a secure, peaceful world without setbacks produced by hackers or identity theft. The evolution of digital identification has been fast progressing from traditional methods to more advanced and secure methods. [9]
Initial Authentication: In the early days of the Internet, identification was primarily an account-based identity on username and password systems. This method was simple but had significant security vulnerabilities.
Since identity fraud grows yearly, organizations and providers have developed additional security measures to prevent it. Three authenticator assurance levels (AALs) were defined by the National Institute of Standards and Technology of the U.S. Department of Commerce (NIST) [10] Authenticator assurance levels (AAL) are associated with interactive sessions and not with the authenticators themselves. This is because combinations of authenticators, used together, can achieve a higher AAL than individually. To satisfy the requirements of a given AAL, a claimant SHALL be authenticated with at least a given level of strength to be recognized as a subscriber. [11]
AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriberâs account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol. By far the most common authenticator at AAL1 is the memorized secret.
AAL2 requires the use of two authentication factors, either (1) a physical authenticator and a memorized secret, or (2) a physical authenticator and a biometric that has been associated with it. Multi-factor authentication can be performed using either a multi-factor authenticator or through the use of two independent authenticators.
AAL3 introduces several new requirements beyond AAL2, the most significant being the use of a hardware-based authenticator. Several additional authentication characteristics are required:
- verifier impersonation resistance,
- verifier compromise resistance, and
- authentication intent.
If a hardware-based authenticator that is not verifier impersonation resistant is used, a software-based authenticator that provides verifier impersonation resistance will satisfy that requirement.
Even though two authentication factors are required at AAL3, one combination of authenticators (Hardware Single-Factor OTP Device plus a Single-Factor Cryptographic Software Authenticator plus a Memorized Secret) consists of three authenticators. This combination stems from the fact that the hardware-based Single-Factor OTP Devices do not provide verifier impersonation resistance, so a Single-Factor Cryptographic Software Authenticator can satisfy that requirement. But since both of those authenticators are something you have, a Memorized Secret is required to satisfy the requirement for two different authentication factors.
There might be additional combinations that work, such as combinations of four or more authenticators to meet all of the AAL3 requirements, but these are unlikely to be used because of the complexity of the user experience.
Blockchain Technology: Blockchain introduced decentralized identity solutions, giving individuals control over their digital identities and leveraging the distributed nature of blockchain for security.
A.1.2 The Internet Infrastructure Integral to the Management, Security, and Credibility of Digital Identities
The Internet infrastructure is integral for digital identity management, security, and credibility.
A domain name is a critical part of an organization's digital identity. It serves as the unique address on the internet, much like a business's storefront [9]. Ensuring that the domain is properly registered and managed is essential for maintaining control over the digital identity [9].
DNS plays a role in the authentication process. When a user tries to access a website, the DNS system resolves the domain name to an IP address [9]. This step is crucial for verifying that the user connects to the correct server, which is part of the broader digital identity verification process.
Protecting the DNS infrastructure is vital for safeguarding digital identities. DNS attacks, such as DNS spoofing or hijacking, can lead to unauthorized access to sensitive information and compromise digital identities1.
A well-maintained DNS infrastructure enhances the trustworthiness and credibility of a digital identity [9]. For example, businesses that use consistent and secure domain names are more likely to be trusted by users and customers [9].
Some digital identity solutions leverage blockchain technology to create decentralized identities [10]. These solutions often use DNS-like systems to manage and verify digital identities securely and transparently.
In summary, DNS infrastructure is integral to digital identity management, security, and credibility. Properly managing DNS can help ensure that digital identities are protected and trusted by users and organizations alike.
The Domain Name System (DNS) is a hierarchical and distributed name service that provides a naming system for computers, services, and other resources on the Internet or other Internet Protocol (IP) networks. It associates various information with domain names (identification strings) assigned to each of the associated entities. Most prominently, the DNS translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. [11]
Names are globally unique and human-readable, but not strongly owned. The system operator has the final say as to what each name resolves to. This requires that client must trust the system, including their administrators as the only ones that can make these changes.
A Domain Name System (DNS) zone file serves several essential purposes within the DNS infrastructure:
Mapping Domain Names to IP Addresses: The primary function of a DNS zone file is to map domain names to their corresponding IP addresses. This allows users to access websites using human-readable names instead of numeric IP addresses.
Defining DNS Records: A zone file contains various DNS records that define different aspects of the domain, such as:
A Records: Map domain names to IPv4 addresses.
AAAA Records: Map domain names to IPv6 addresses.
CNAME Records: Create aliases for domain names.
MX Records: Specify mail servers for email handling.
TXT Records: Provide text information for various purposes, such as verification and security.
NS Records: Indicate the authoritative name servers for the domain.
The zone file contains mappings between domain names, IP addresses, and other resources, organized in the form of text representations of resource records (RR). [12]
Establishing Authority: The zone file designates the authoritative name servers for the domain, which are responsible for answering queries about the domain.
Configuration and Management: The zone file allows administrators to configure and manage the DNS settings for the domain, including setting Time to Live (TTL) values and handling subdomains.
Supporting Redundancy and Load Balancing: By defining multiple DNS records, a zone file can support redundancy and load balancing, distributing traffic across multiple servers to ensure availability and reliability.
In essence, a DNS zone file is a crucial component for managing the relationship between domain names and their associated resources, ensuring that users can reliably and efficiently access websites and services on the internet.
The zone file has to follow an agreed format [13]
An example of a zone file for the domain example.com is the following:
$ORIGIN example.com. ; designates the start of this zone file in the namespace
$TTL 3600 ; default expiration time (in seconds) of all RRs without their own TTL value
example.com. IN SOA ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )
example.com. IN NS ns ; ns.example.com is a nameserver for example.com
example.com. IN NS ns.somewhere.example. ; ns.somewhere.example is a backup nameserver for example.com
example.com. IN MX 10 mail.example.com. ; mail.example.com is the mailserver for example.com
@ IN MX 20 mail2.example.com. ; equivalent to above line, "@" represents zone origin
@ IN MX 50 mail3 ; equivalent to above line, but using a relative host name
example.com. IN A 192.0.2.1 ; IPv4 address for example.com
IN AAAA 2001:db8:10::1 ; IPv6 address for example.com
ns IN A 192.0.2.2 ; IPv4 address for ns.example.com
IN AAAA 2001:db8:10::2 ; IPv6 address for ns.example.com
www IN CNAME example.com. ; www.example.com is an alias for example.com
wwwtest IN CNAME www ; wwwtest.example.com is another alias for www.example.com
mail IN A 192.0.2.3 ; IPv4 address for mail.example.com
mail2 IN A 192.0.2.4 ; IPv4 address for mail2.example.com
mail3 IN A 192.0.2.5 ; IPv4 address for mail3.example.com
The Internet Corporation for Assigned Names and Numbers (ICANN) [14] requires the registry operators to provide bulk access to the zone files of the Generic Top Level Domain (gTLD) at least daily. For gTLDs, a zone file contains information about domain names that are active in that gTLD. In general, Internet users may be able to access and download zone file data at no cost for certain purposes.[15]
The response time of a DNS (Domain Name System) query is quite relevant for several reasons:
User Experience: A faster DNS response time means quicker resolution of domain names to IP addresses, leading to faster website loading times. This can significantly enhance user experience, particularly for users on slow connections or accessing content-rich websites.
Website Performance: Websites with faster DNS response times often have better overall performance. Slow DNS queries can lead to delays in loading web pages, affecting user satisfaction and engagement.
SEO Ranking: Search engines like Google consider page load times as one of the factors in their ranking algorithms. Faster DNS resolution can contribute to better page load times and potentially improve a website's SEO ranking.
Network Efficiency: Efficient DNS queries reduce the time and resources required for network communications, making the overall network more efficient.
Reliability: Faster DNS responses can indicate a more reliable DNS infrastructure, reducing the likelihood of timeouts or failures during the domain resolution process.
Security: Faster DNS responses can also help mitigate certain types of cyber-attacks, such as DNS amplification attacks, by reducing the time an attacker has to exploit DNS queries.
Overall, the response time of a DNS query is an important aspect of web performance, user experience, and network efficiency.
There are several recommendations and best practices to ensure effective DNS routing and zone file management:
Weighted Round Robin (WRR): Distribute traffic among multiple servers based on assigned weights.[16]
Geolocation Routing: Direct traffic based on the geographic location of the user.[16]
Failover Routing: Set up backup servers to take over in case the primary server fails.[16]
Health Checks: Regularly monitor the health of your servers and automatically reroute traffic if a server fails.[16]
Regular Updates: Keep DNS records current to ensure accurate domain resolution.[17]
Redundancy: Use secondary (slave) DNS zones to provide redundancy and improve reliability.[17]
Security: Secure zone transfers to prevent unauthorized access and implement DNSSEC to protect against DNS spoofing.[17]
Monitoring: Regularly monitor DNS zone health to detect and resolve issues promptly.[17]
TTL Management: Set appropriate Time to Live (TTL) values to control how long DNS records are cached.[18]
Access Control: Limit access to DNS zone management to authorized personnel only.[17]
Backup: Regularly back up DNS zone files and store them securely.[18]
Several attempts to use cryptographic names have been tested, from the keys they reference. These names are difficult for most users to remember since they do not carry semantic information relating to their use in the system.
Several types of cryptographic infrastructures are operating on the internet.
This is a framework used to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. It's widely used for secure electronic communication, such as e-commerce and internet banking. [19]
Technologies like Bitcoin and Ethereum are well-known examples. [7] Blockchain provides a decentralized and secure way to record transactions and manage data.
Solutions like SECRIN [20] are designed to protect cryptographic keys in virtualized environments, ensuring secure communication and data protection.
These are physical devices that manage digital keys and provide cryptographic operations. They are often used to meet regulatory requirements and provide high levels of security.[21]
Blockchains tend to offer specific advantages for identity systems. Because blockchains are public databases that are accessible and verifiable by everyone, their identity is public, too. Because identities on the blockchain are ultimately accounts that are manipulated by private keys, identities can be controlled by persons, companies, or objects; they can be traditional identities, simple profiles, blockchain access points, or avatars. Starting, with the Ethereum blockchain bringing programmability. Now identities are not just passive data but more complex computer programs. Now other solutions improve this initial start, bringing programmability to Bitcoin, like the Stacks Blockchain a Bitcoin L2 Blockchain. [22]
There are also challenges to hosting identities on the blockchain. First, because blockchains are anonymous, there are issues when other systems need to recognize accounts, understand their relationships, or check attestations and claims. [22]
Second, because blockchain data is visible to everyone, careful decisions have to be made about which personal data is stored on the blockchain ("on-chain") and which is instead stored elsewhere and linked to from the blockchain ("off-chain"). They can each address the challenges of blockchain identity and do so in ways that are complementary, not exclusive.
Third, the keys for identity need to be managed carefully. They need to be backed up, and provisions must be made to avoid losing identities when keys are lost. Methods such as multi-signatures and key-recovery schemes such as Shamir-s Secret Sharing exist to solve some key management problems.
Building systems with blockchains presents challenges:
⢠Limits on Data Storage: Individual blockchain records are typically on the order of kilobytes and cannot hold much data. Moreover, the blockchainâs log structure implies that all state changes are recorded in the blockchain. All nodes participating in the network need to maintain a full copy of the blockchain, limiting the total size of blockchains to what current commodity hardware can support.
⢠Slow Writes: The transaction processing rate is capped by the blockchainâs write propagation and leader election protocol, and it is pegged to the rate at which new blocks are announced by leader nodes, called miners in many blockchain networks. New transactions can take minutes to a few hours to be accepted.
⢠Limited Bandwidth: The total number of transactions per block is limited by the block size of blockchains. To maintain fairness and to give all nodes a chance to become a leader in the next round, all nodes should receive a newly announced block at roughly the same time. Therefore, the block size is typically limited by an average uplink bandwidth of nodes.
⢠Endless Ledger: The integrity of blockchains depends on the ability of anyone to audit them back to the first block. As the system makes forward progress and issues new blocks, the cost of an audit grows linearly with time, which makes booting up new nodes progressively more time-consuming. This is an endless ledger problem.
Relying on the consensus protocol of the underlying blockchain, there is an opportunity to provide a total ordering for all operations supported by the naming system, like name registrations, updates, and transfers.
This can be done with the separation of the Control and the Data.
Decoupling the security of name registration and name ownership from the availability of data associated with names by separating the control and data planes. The control plane defines the protocol for registering human-readable names, creating (name, hash) bindings, and creating bindings to own cryptographic key pairs.
Today, decentralized applications (Dapps) are all built around private keys, which are used to communicate with smartcontracts and move assets like Bitcoin, Ether, Stacks, among others.
Decentralized Applications (Dappâs) also called Web3 Apps [33] or Stacks applications is the New App that integrates these main functions, authentication, transaction signing, and data storage. All users can run their applications under their own private decentralized space. Web3 users own their data as they are the only ones has access to and/or share with other users their private data through the decentralized application.
It should be considered, if the private key is lost, then all access to the contract and assets is lost. This can be devastating because it means that the identity is effectively lost: there are no second chances in blockchain. Any good blockchain identity system thus needs a complex identity-management scheme that goes beyond the simple use of private keys.
First, identity-management systems must solve the problem of updating permissions without changing the identity. One option is to create separate key-management and identity smart contracts. This way, the key management can be upgraded and evolve without the need to change the on-chain identifying addresses. This allows attached on-chain information such as claims, reputations, and other identifying information to stay unchanged even if the whole system is replaced. Another possibility is to integrate ownership change directly into the smart contract while ensuring that the account's identifying address does not change.
Second, identity-management systems should support robust features such as these:
- Multiple access methods
- Different key types
- Social recovery schemes
The World Wide Web Consortium - (W3C) recommends Decentralized identifiers (DIDs) [34], as a new type of identifier that enables verifiable, decentralized digital identity. A DID [35] refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help discover information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. A DID might provide the means to return the DID subject itself if the DID subject is an information resource such as a data model.
The DIDs for a person, for example, are expressed through a name and an image, sometimes a description, background image, URL, email, password signature, etc. The visual and textual representation of an account, helps users to better recognize their accounts, from the accounts of other users.
The essence of decentralized digital identity: turning physical wallets into digital credentials in digital wallets.
As the decentralized digital identity model started to catch on, it quickly developed the term self-sovereign identity and then the acronym SSI.
The term self-sovereign identity applied to a person, translates to
A person's identity that is neither dependent on nor subjected to any power or state. This type of identity does not compete with government-issued identity. The two are highly complementary. [SSI]
- Self-sovereign identity is self-asserted identity. That is, you are the only one who can make identity assertions about yourself. Nowadays, most of the information about your identity comes from other trusted sources -- that's the reason other parties are willing to rely on it.
- Self-sovereign is very much informed by individuals' needs for security, privacy, and personal data control, the SSI model applies equally for organizations and things. Anything that needs identity on the internet.
The fundamental reason the term self-sovereign identity is grounded: it represents a shift in control.
In the centralized and federated identity models, the locus of control is with the issuers and verifiers in the network. In the decentralized SSI identity model, the locus of control shifts to the individual user, who can now interact with everyone else as a full peer.
SSI is relatively new. At one level, SSI is a set of principles about how identity and personal data control should work across digital networks. At another level, SSI is a set of technologies that build on core concepts in identity management, distributed computing, blockchain, and cryptography. What's new is how these sets of technologies are put together to create a new model for digital identity management. Seven basic building blocks have been identified for SSI as follows:
- Verifiable credentials (digital credentials)
- The trust triangle: issuers, holders, and verifiers.
- Digital wallets.
- Digital agents.
- Decentralized identifiers (DIDs).
- Blockchains and other verifiable data registries.
- Governance frameworks.
The SSI stack was defined as a four-layer model, where the bottom layers are primarily about achieving trust and the two top layers are about achieving human trust.
Layer 1. Identifiers and public keys
Layer 1 is the bottom of the stack, where identifiers and public keys are defined and managed. It is based on a DID Registry and DID method.
Layer 2 is the secure communications, and interfaces between agents, wallets, and hubs.
Layer 3 is sharing credentials between the issuer, holder, and verifier.
Layer 4 is the governance of the SSI.
SSI was born because blockchain technology introduced an exciting new option for implementing a decentralized public key infrastructure (DPKI), as explained previously. Having a DPKI implemented could unlock the power of verifiable credentials (VCs). Most of the DID methods in the W3C DID specification registry are based on blockchains.
Several initiatives like Hyperledger, the Sovrin Foundation, and the Veres One have been developed.
The experience showed that no private data should go into the chain or ledger. Even there are some privacy implications regarding encrypted data just by watching who writes and reads it. Additionally, some other issues with the EU General Data Protection Regulation (GDPR) and other data protection regulations worldwide provide a "right of erasure" to data subjects.
The user databases of internet giants have shown that modern web-ready database technologies can achieve the robustness, global scale, and geographical dispersion needed by a DID registry. Such centralization undermines SSI's most important design goal (and the internet): eliminating single points of control and failure. Traditional databases are discounted as a viable implementation path for Layer 1.
A.2.5.5 Distributed databases as DID registries and as an infrastructure for decentralized applications
We did a study to add a messaging component to the actual decentralized application architecture, as some decentralized applications require interaction (exchange of information) between other users of the same application or other applications. The conclusion showed that we needed a broader scope than the messaging aspect of an application. We extended the scope of the study starting from the Distributed Database Management Systems and their components and functionalities. It became clear during this study the usefulness of creating the prototype of an Evaluation Framework of Decentralized Database Management Systems. This is still an area for future research and development. [23]
DIDs and DID documents can be generated and exchanged directly between peers that need them to identify and authenticate each other.
In this case, the "DID registry" is the digital wallet of each of the peers--each is the "root of trust" for the other--along with trust in the protocol used to exchange these peer DIDs. The DIDs, public keys, and service endpoints are completely private--they never need to be shared with any external party, let alone on a public blockchain. Situations where one or both of the peers move to new service endpoints and lose touch with one another. Some of these require clever triangulation against a public blockchain at Layer 1.
Key Event Receipt Infrastructure (KERI) is a complete architecture for portable DIDs developed around the concept of self-certifying identifiers at the heart of peer DIDs.
In the ever-evolving digital world, the need for secure and verifiable identities is paramount. DIDs have emerged as a promising solution, providing a globally unique, persistent identifier that does not require a centralized registration authority. However, like any technology, DIDs face challenges in terms of authenticity, discoverability, and portability.
This is where the Domain Name System (DNS), a well-established and globally distributed internet directory service, comes into play. By leveraging the existing DNS infrastructure, we can enhance the verification process of DIDs. Specifically, we can use Transport Layer Security Authentication (TLSA) and Uniform Resource Identifier (URI) DNS records to add a layer of verification and authenticity to DIDs. [24]
Much like presenting two pieces of ID to provide a higher level of assurance when proving your identity or age, replicating important information about a DID into a different domain (like the DNS) enables a similar form of cross-validation. This enhances the initial trust establishment between the user and the DID document, as the key information can be compared and verified across two segregated sets of infrastructure. This also acts as a form of ownership verification similar to 2FA, as the implementer must have control over both the DNS zone and the DID document to properly duplicate the relevant information.
+----------------+ +----------------+ | | | | | DNS Server | | Web Server | | | | | | +-------+ | | +-------+ | | | DID |<---+-----+-->| DID | | | +-------+ | | +-------+ | | +-------+ | | +-------+ | | | PKI |<---+-----+-->| PKI | | | +-------+ | | +-------+ | | | | | +----------------+ +----------------+
The diagram above illustrates how a web server storing the DID document, and the DNS server storing the URI and TLSA records shares and links the key information about the DID across two independent sets of infrastructure. [25]
With did:web, thereâs an inherent link between the DNS needed to resolve the associated DID document and the domain where the relevant supporting DNS records are located. This means that the domain specified by the did:web identifier (for example, did:web:example.ca) is also the location where you can find the supporting DNS records.
The association to a domain stemming only from the did is unidirectional. By leveraging URI records as outlined in [DID-in-the-DNS], we can create a bidirectional relationship, allowing a domain to publish its associated DID in the DNS.
_Ex: did.example-issuer.ca IN URI 1 0 âdid:web:example-issuer.caâ
This relationship enhances security, as an entity would require control over both the DID and the domainâs DNS server to create this bidirectional association, reducing the likelihood of malicious impersonation.
- The records MUST be scoped by setting the global underscore name of the URI RRset to _did (0x5F 0x64 0x69 0x64).
The following part describes the digital identity technologies applied in the Stacks Blockchain - a Bitcoin L2 Blockchain.
The emergence of Blockchain became the candidate to implement the association between names and cryptographic keys. Blockchains provide a global append-only log that is publicly writeable. Writes to the global log, called transactions, are organized as blocks and each block packages multiple transactions into a single atomic write. Writing to the global log requires a payment in the form of a transaction fee.
Blockchain is a large deployment of a decentralized PKI service.
Users can register human meaningful names and securely associate data with them, and only the owner of the particular private keys that registered them can write or update the name-value pair. Many decentralized systems have been and can be built using these blockchain networks, such as new, decentralized versions of DNS and PKI.
The experience presented is the Naming System built on the Stacks and Bitcoin Blockchain [22].
A user's private and public keys are based on mathematical, and cryptographical algorithms, and they are to be used in the Stacks or Bitcoin blockchain.
From a private key, the user can derive a decidable public key in a Stacks address format, and in several Bitcoin address formats. Actual Stacks 2.1 have methods accepting more BTC address formats (P2PKH, P2SH, P2WPKH, P2WSH, P2TR). A Stacks address starts with an âSPâ.
Initially, the Bitcoin address was based on the legacy address P2PKH starting with a â1â, the actual ones are based on SegWit address P2WPKH starting with a âbc1â, and Taproot address when massively available starting with a âbc1pâ.
These addresses are mathematically or cryptographically linked together as one of the same, but they are used in the Stacks or Bitcoin blockchain ecosystem respectively.
The first name registered in a Bitcoin Blockchain transaction was in 2014, called Namecoin service on the Bitcoin Blockchain. [23] This service evolved as the Bitcoin Name Service (BNS) on the Blockstack Blockchain. Later, Blockstack Blockchain was rebranded as the Stacks Blockchain [22], a Bitcoin L2 Blockchain [24].
This BNS naming system means that (a) names are human-readable and can be picked by humans, (b) name-value pairs have a strong sense of ownershipâ that is, they can be owned by cryptographic keypairs, and c) there is no central trusted party or point of failure.
This makes it a powerful tool for building all kinds of network applications. Using the BNS, the following can be achieved:
⢠Build domain name services where hostnames cannot be hijacked.
⢠Build social media platforms where user names cannot be stolen by phishers.
⢠Build version control systems where repository branches do not conflict.
⢠Build public-key infrastructure where it is easy for users to discover and remember each other's keys.
Software applications built with the Stacks blockchain (Bitcoin L2) integrated, give users control over their digital identities, assets, and data. Unlike most cloud-based apps, they are "decentralized" since they do not depend on any centralized platform, server, or database to operate. Rather, they use the Stacks blockchain to authenticate users and facilitate read and write requests for them without any single point of failure or trust.
The name registry is built with a deployed smart contract running on the Stacks Blockchain, a Bitcoin L2 Blockchain. The provable smart contract is written in Clarity-smart contract language [25], a safe, decidable language. The contract links the STX address and the name, domain, and namespace according to the rules about fees and expiry.
The BNS contract version 1 was deployed at a Stacks Blockchain transaction. [26] A BNS contract version 2 was deployed on September 2024 [27].
Additionally to the basic functionality, it offers features for decentralized name management, and marketplace integration supporting both open and managed namespaces [28].
This kind of name can be called Decentralized ID or Decentralized Name. It uses cryptography, digital wallets, and related technologies to enable multiple entities to produce credentials and empower individuals to manage their data.
Decentralized ID systems create a trust triangle that links issuers, holders, and verifiers:
are entities that digitally sign attestations and provide them to holders.
such as individuals, manage their credentials, and use them to prove claims about their data.
assess these attestations to determine whether they satisfy requirements. This process is facilitated by a verifiable data registry.
The Stacks blockchain addresses performance problems using a layered approach. The base layer consists of the Stacks blockchain, and the Blockchain Naming System (BNS) [29]. The blockchain governs ownership of identities in the Stacks network. Identities can be names such as namespaces, domain, and subdomain names. These identities can refer to persons, applications, or things.
Names in BNS have four properties:
⢠Names are globally unique. The protocol does not allow name collisions, and all well-behaved nodes resolve a given name to the same state.
⢠Names are human-meaningful. Each name is chosen by its creator.
⢠Names are strongly owned. Only the name's owner can change the state it resolves to. A name is owned because the owner of its private key can generate valid transactions that update its zone file hash and ownership. The name zone file can only have a valid verification using the ownerâs private key.
⢠Names using their associated public and private keys can sign transactions. Only the owner of the name and the associated keys can sign in a verifiable way transactions, and the execution of the smart contracts in a decentralized way. This action represents the unique action of a user, that has access to those keys.
While on-chain storage solutions and applications like IPFS and Arweave are designed for immutable, censorship-resistant permanent storage, they cannot be deemed as providing user control of the data since the user cannot modify or remove the data once it has been deployed.
Apps built with the Stacks blockchain can store off-chain data using a storage system called Gaia. [30]
Gaia is a unique approach to decentralized storage that focuses primarily on user-ownership of data, rather than immutable on-chain storage. The emphasis here is on user control.
Gaia solves a different problem of allowing users to be in control of where their data is stored while connecting the access of that data to their on-chain Stacks identity.
Whereas public transactional metadata is best stored on the Stacks blockchain, user application data can often be stored more efficiently and privately in Gaia storage.
Storing data off of the blockchain ensures that these applications (decentralized) can provide users with high performance and high availability for data reads and writes without introducing central trust parties.
When a digital identity is created, using a transaction, its creation is recorded in the Stacks blockchain. This is the primary data stored in the Stacks blockchain. These identities correspond to routing data in the OSI stack [31]. The routing data is stored in the Atlas Peer Network [30], the second layer.
The Namespaces Domain Names and user ownership are registered and stored using the BNS Smartcontract in the Stacks Blockchain. This registration considers a reference hash of the contents of a text file describing the services associated. This reference hash serves to verify if the contents have been modified.
The routing data describing the services associated with ownership of the Namespace and Domain Name is stored as a text file in the Atlas Peer Network. Similar functionality and file format that is used in the DNS Zone File management.
This decentralized zone file can specify the user's desire for the type of service that should be considered when using their Identity. For i.e., a reference to a personal website, and a reference to your identity profile data, among other services. TLD format.
Every core node that joins the Stacks Network can obtain an entire copy of this routing data. Stacks use the routing data to associate identities (domain names, user names, or application names) with a particular storage location in the final layer, the Tertiary Data Storage like Gaia Storage System.
A Gaia Storage System consists of a hub service and storage resource on a cloud software provider. The storage provider can be any commercial provider such as Azure, DigitalOcean, Amazon EC2, and so forth. Typically the compute resource and the storage resource reside same cloud vendor, though this is not a requirement. Gaia currently has driver support for S3, Azure Blob Storage, and Google Cloud Platform, but the driver model allows for other backend support as well.
Gaia stores data as a simple key-value store. When an identity is created, a corresponding data store is associated with that identity on Gaia. When a user logs into a dApp, the authentication process gives the application the URL of a Gaia hub, which then writes to storage on behalf of that user.
The Stacks blockchain stores only identity data. Data created by the actions of an identity is stored in a Gaia Storage System. Each user has profile data. When a user interacts with a decentralized dApp that application stores application data on behalf of the user. Because Gaia stores user and application data off the blockchain, a Stacks DApp is typically more performant than DApps created on other blockchains.
When the user logs using its BNS name into an application, the authentication process gives the application the URL of a Gaia hub, which performs writes on behalf of that user. The Gaia hub authenticates writes to a location by requiring a valid authentication token, generated by a private key authorized to write at that location.
Gaia's approach to decentralization focuses on user control of data and storage. If a user can choose which Gaia hub and which backend provider to store data with, then that is all the decentralization required to enable user-controlled applications.
The App's objectives could suggest using an alternative solution to store data associated with a BNS name. The option of using a distributed file system like IPFS, or Arweave, or messaging services like Mastodon, or Matrix, among other types of storage services, will be an area of intensive growth in the next years as the decentralization process turns mainstream.
c) Essentially, these technologies will try to bring to market the capacities of the design of Distributed Databases.
A proposal of extending the Stacks component was proposed by @Paradigma-cl in this study [32].
The domain name phillip.stx was registered as primary data into the Stacks Blockchain and the BNS at the transaction last_txid":"0x102d73f2ce7906649715764a78d9b75dc3f188ff60128f61dc9d713790906f29". The ownership of the domain name is represented with the "address":"SP17Z5ZD89DVJHDB2SBZAST41PTS3BS50YY3XBVJY", and it was executed using the BNS smart-contract function called "name-register" [25]. A hash of the routing information is included in the primary data layer.
{"address":"SP17Z5ZD89DVJHDB2SBZAST41PTS3BS50YY3XBVJY","blockchain":"stacks","last_txid":"0x102d73f2ce7906649715764a78d9b75dc3f188ff60128f61dc9d713790906f29","status":"name-register","zonefile_hash":"c74108af50c099a211e35eb22456812a1a61230e","expire_block":36708}
Additionally, data is registered as a Secondary Data Layer associated with the "address":"SP17Z5ZD89DVJHDB2SBZAST41PTS3BS50YY3XBVJY". A text file is used to describe the routing data similarly to a Domain Name System (DNS) zone file. In this example, the zone file text is associated with the phillip.stx name:
{"zonefile":"$ORIGIN phillip.stx.\n$TTL 3600\n_http._tcp\tIN\tURI\t10\t1\t\"https://gaia.blockstack.org/hub/17tqGoM8xDjLTpy2rFZ1yj9BPmVeC3zjDi/profile.json\"\n\n"}
BNS names can be compliant with the emerging Decentralized Identity Foundation [38] protocol specification for decentralized identifiers (DIDs), and the W3C. These initiatives define mechanisms by which an end user can leverage an open provider to release identity information (such as authentication and claims) to a Relying Party that can act on that information.
Stacks has a long history of Decentralized Identifiers (DIDs) as they introduced human-readable names for Bitcoin addresses when the project started as âOne Nameâ back in 2014.
The Stacks public DID is a profile that is registered with a username on-chain using the BNS (Blockchain Naming System) smart contract. These profiles are defined using the JSON web token, and its contents using the appropriate objects of the Schema standard [36], like the person object [37].
Each name in BNS has an associated DID. The DID format for BNS is: ⢠did:stack:v2:{address}-{index} ⢠did:btc-addr:{address}-{index}
Where: ⢠{address} is an on-chain public key hash (for example a Stacks or Bitcoin address). ⢠{index} refers to the nth name this address created.
The Stacks blockchain ensures that each node's BNS view is synchronized to all the other nodes in the world, so queries on one node will be the same on other nodes. Stacks blockchain nodes allow a name's owner to bind up to 40Kb of off-chain state to their name, which will be replicated to all other Stacks blockchain nodes via a P2P network.
The biggest consequence for developers is that in BNS, reading name state is fast and cheap but writing name state is slow and expensive. This is because registering and modifying names requires one or more transactions to be sent to the underlying blockchain, and BNS nodes will not process them until they are sufficiently confirmed. Users and developers need to acquire and spend the requisite cryptocurrency (STX) to send BNS transactions. At another level, the different applications could interact among them exchanging information. To use these capabilities, a set of standard verifiable digital identities should be used and integrated into the web to have a secure and private interaction.
A request for a transaction or change of state of the Blockchain requires the use of the private key to sign, and funds as gas to materialize the order. To improve security, and reduce the risk of losing control of the private key of an account, different methods have been developed, trying to avoid entering it directly to the application.
For the use of web applications, it requires the use of a browser wallet software plugin, that has access to the private key directly or using a hardware device.
At present in the Stacks ecosystem, there are two browser wallet software available. One is the Hiro Wallet (https://wallet.hiro.so/) for desktop PCâs, and Xverse Wallet (https://www.xverse.app/) for mobile devices.
To incentivize mass adoption of DIDs, one initial strategy is to link both Internet Domain Names to DIDs, both referring to each other, in the BNS zone file a reference to a web server, and in the Internet domain server referring to the respective DID. Mixing a centralized domain names with the decentralized domain names. For example, the Internet domain name XCK.app refers to the Stacks DID XCK.app, and both are owned by the same controller. In this case, the controller should be the dapp.
This strategy is ratified by a recent proposal in using a new DID method in conjunction with blockchain-based DIDs that allows them to bootstrap trust using a web domain's existing reputation (https://w3c-ccg.github.io/did-method-web).
Typically, the domain and subdomain names have commonly used Latin characters in ascii format. Due to the convergence of the use of different languages, and character systems, the popularity in social apps, people have started to think about using emoji as names for their domains or subdomains.
The compatibility of the dapps with Punycode could be a facilitator of mass user adoption. For example: đ§âđź .xck.app is represented as xn-- -zc3sr5i.xck.app
In order to have higher level of adoption, increases the desire to have communications, and interoperability between users cross blockchains ecosystems like Stacks, and Bitcoin. One example, is Nostr, that uses the public key as unique identifier, that is linked to the DNS.
Each App (web application) should have a verified identity in order to safely reference it and be trustworthy of interaction between other applications. An app can be identified both by the Internet domain (DNS) for example 'XCK.app' and the Stacks DID 'XCK.app' In case, it is a web application, it could be accessed as https://xck.app having both definitions. In this case, we using the trust of the Internet domains to match the Decentralized Domains (DID).
The description for an App Profile document should be done using a JSON web token based on the WebApplication Schema object (https://schema.org/WebApplication). Additionally, this App Profile document must include the did-method-web. The example is represented as 'did:web:xck.app'. The target system of the Web DID method is the web host that the domain name described by the DID resolves to when queried through the Domain Name System (DNS). This did-method-web must be included in this app profile.
It could be useful to have a way to retrieve a verifiable DID profile for the App as recommended by the W3C using an URI. For example, a web URI https://xck.app?.well-know/profile In this case, the application should also return a JSON web token using the protocol previously mentioned.
Creating a DID is done by: applying at a domain name registrar for use of a domain name and storing the location of a hosting service, the IP address at a DNS lookup service creating the DID document JSON-LD file including a suitable keypair, e.g., using the Koblitz Curve, and storing the did.json file under the well-known URL to represent the entire domain.
For example, for the domain name 'xck.app', the 'did.json' should be available under the following URL: 'did:web:xck.app' -> https://xck.app/.well-known/did.json
Example of the 'did.json' file for 'XCK.app'
{
"@context": "https://www.w3.org/ns/did/v1",
"did:web": "xck.app",
"verificationMethod": [
{
"id": "did:web:xck.app#OAuth",
"type": "Secp256k1",
"controller": "did:web:xck.app:oauth",
"stacksAddress": "SP3YK7KWMYRCDMV5M4792T0T7DERQXHJJGGEPV1N8"
}
],
"authentication": [
"did:web:support.xck.app#OpenID",
"type": "Secp256k1",
"controller": "did:web:xck.app:oid",
"stacksAddress": "SP3YK7KWMYRCDMV5M4792T0T7DERQXHJJGGEPV1N8"
]
}
Expanding the Internet Domain Names to the users of Decentralized Identifiers (DID) For the users of each App (web application), the App could provide a verified user identity in order to safely reference across other applications. In this context, the DIDs are URIs that associate a DID subject as a user of the application with a DID document allowing trustable interactions associated with that subject.
The BNS Bitcoin Name System has the possibility to create subdomain names under a defined decentralized domain name. A user can inscribe a subdomain name, having the attribute of a DID. For example, the user 'support', using the domain name âxck.appâ is 'support.xck.app' In the example used here, the user is identified by this subdomain name, and it could be useful to retrieve a verifiable DID profile for the App User as recommended by the W3C using an URI. For example, a web URI https://support.xck.app/.well-known/profile
The BNS implement a way to store the description for a User Profile document using the Person Schema object (https://schema.org/Person). The BNS has the possibility to associate a zone file to each Stacks address. In the zone file there is a reference to the location of a profile.json file, where the user profile is saved, with a hash in a JSON web token format. The web token assures that only the user can sign the profile in the blockchain. If the profile is altered by somebody else of the owner, the profile file would not match the JSON web token.
Also, this document must include the did-method-web for the app user. For the user support.xck.app as an example, it is represented as 'did:web:support.xck.app'. The target system of the Web DID method is the described web host resolved by the Domain Name System (DNS) when queried. This did-method-web is included in this app user profile.
In this case, the application should also return a JSON web token using the Person Schema object.
Example of the Person JSON web token included in the profile for support.XCK.app
{
"header": {
"typ": "JWT",
"alg": "ES256K"
},
"payload": {
"jti": "a7ad5f4f-0f6b-4674-903c-e0c9acd542af",
"iat": "2023-06-16T22:59:11.416Z",
"exp": "2024-06-16T22:59:11.416Z",
"subject": {
"publicKey": "031f6416b88fc084c12edc8aa052d9408513793a832a9546d768cb90ba6e6875d5"
},
"issuer": {
"publicKey": "031f6416b88fc084c12edc8aa052d9408513793a832a9546d768cb90ba6e6875d5"
},
"claim": {
"@type": "Person",
"@context": "https://schema.org",
"apps": {
"https://xck.app": "https://gaia.blockstack.org/hub/1EqMMnscqw4BExURkxjamnyW47aqQSKmwV/",
"https://explorer.stacks.co": "https://gaia.blockstack.org/hub/13gRiYdPQnDyhSjmuAoKpsYHRCxapP5opi/",
âŚ.
},
"appsMeta": {
"https://xck.app": {
"storage": "https://gaia.blockstack.org/hub/1EqMMnscqw4BExURkxjamnyW47aqQSKmwV/",
"publicKey": "0250eff373ca36b72aa4fdb6a7fc201829b2a7c5ccf7b7196e5b6b6b734facbe84"
},
"https://explorer.stacks.co": {
"storage": "https://gaia.blockstack.org/hub/13gRiYdPQnDyhSjmuAoKpsYHRCxapP5opi/",
"publicKey": "0269903a668f1a3fd3f17528b3fb70c75cff910bbe456f3811ade975dba473f71a"
},
âŚ,
},
"name": "Support CrossCheck",
"description": "The CrossCheck(c) Dapp requires sometimes a support service. This account represents the support service that it is given to CrossCheck users.",
"sameAs": [
"https://www.facebook.com/checkParadigma",
"https://twitter.com/xck_app",
"https://www.youtube.com/@crosscheckxck",
"",
"https://www.linkedin.com/company/52113400",
"",
"https://xck.app"
],
"email": "[email protected]",
"telephone": "",
"telephoneCountry": "",
"telephonePrefix": "",
"potentialAction": [
"Public",
"",
"Public",
"",
""
],
"contactPoint": [
"Active",
"false",
"true",
"true",
"true",
"true",
"true"
]
}
},
"signature": "kMzVsEoLOLn3HpsJu2vyY2SHQ_zTQj4-anUihtvDd1G2mkaWcS4Jee57r4M60CU1JA-51J14E7qGj7FwLESELw"
}
In case, the did:web does not match the domain name, it could be used with an alternative url. All Stacks decentralized ID (did:web) have access to the did.json file.
Example: did:web:my.xck.app/paradigma.id --> https://my.xck.app/paradigma.id
Creating a DID is done by: applying at a domain name registrar for use of a domain name and storing the location of a hosting service, the IP address at a DNS lookup service creating the DID document JSON-LD file including a suitable keypair, e.g., using the Koblitz Curve, and storing the did.json file under the well-known URL to represent the entire domain.
For example, for the domain name 'support.xck.app', the DID document should be available under the following URL: 'did:web:support.xck.app' -> https://support.xck.app/.well-known/did.json
Example of the 'did.json' file for 'support.XCK.app'
{
"@context": "https://www.w3.org/ns/did/v1",
"did:web": "support.xck.app",
"verificationMethod": [
{
"id": "did:web:support.xck.app#OAuth",
"type": "Secp256k1",
"controller": "did:web:support.xck.app:oauth",
"stacksAddress": "SP3VBHA63ZTZFWTBJWHV775WR3PBZ64B26AYX2CF"
}
],
"authentication": [
"did:web:support.xck.app#OpenID",
"type": "Secp256k1",
"controller": "did:web:support.xck.app:oid",
"stacksAddress": "SP3VBHA63ZTZFWTBJWHV775WR3PBZ64B26AYX2CF"
]
}
This did.json references the blockchain account associated to the DID, and the method to be used to verify if a message hash has been signed by the user.
Also, did.json file specifies the method to be used for the authentication of the user into an application.
In case, the did:web does not match the domain name, it could be used with an alternative url. All Stacks decentralized ID (did:web) have access to the did.json file.
Example: https://my.xck.app/paradigma.id/.well-known/did.json
{
"@context": "https://www.w3.org/ns/did/v1",
"did:web": "my.xck.app:paradigma.id",
"verificationMethod": [
{
"id": "did:web:my.xck.app:paradigma.id#OAuth",
"type": "Secp256k1",
"controller": "did:web:my.xck.app:paradigma.id:oauth",
"stacksAddress": "SP1X4571GM6232GPQ7MW44HGTNX5TH3PKJQR6H7K8"
}
],
"authentication": [
"did:web:my.xck.app:paradigma.id#OpenID"
"type": "Secp256k1",
"controller": "did:web:my.xck.app:paradigma.id:oid",
"stacksAddress": "SP1X4571GM6232GPQ7MW44HGTNX5TH3PKJQR6H7K8"
]
}
SSO authentication is the process of logging in to a network once and then being able to access all the other systems within the same network using the same credentials. A user can log in once and have access to all the systems associated with their account. SSO authentication is used for cloud-based applications, web applications, and mobile apps and so on.
Many services are provided through web applications and the number of applications is increasing rapidly. The same sign on login information is also used by many of these users.
For example, a single-click login is available with OpenID-enabled services like Google, and Facebook. Also, custom Single Sign-On (SSO) provides additional security to protect identity and authentication.
However, centralized authentication has major security vulnerabilities with a single point of failure. Many developments have been made in recent years to address these weaknesses in authentication, and the answer is clear. Security risks can be mitigated by using blockchain-based SSO authentication, which is more secure, cost-efficient, and reliable
The BNS infrastructure, including the Profile, did:web specification could be used to develop a Application Single Sign On (SSO). The decentralized applications typically use the web Wallet for authentication. But probably, there could be an additional level of authentication compatible with the traditional SSO to access the decentralized applications, but when these applications require to sign, and send Blockchain transactions, the web Wallet are used for that purpose.
The described methods above in 4.3 for verification, and authentication, could serve as single sign on a platform based on the Stacks and Bitcoin blockchain to access any application any place in the world. The definition of this way of authentication is owned by the user, and enabled by cryptographic technology.
This Sign On infrastructure does not require to access directly the different blockchain ecosystems, it is through the user published methods. It is a initial step to massify the adoption of DIDâs.
It will be important to define a standard protocol for each of the methods, the verification and authentication. Probably, the OpenID4VC (Open ID for Verifiable Credentials) standard could be used as a base. But the benefits of using an authentication based on Blockchain is much robust, secure, and private than the traditional methods of authentication.
Did:web users can register their ID in compatible applications, probably from different blockchain networks. These applications could retrieve directly the userâs validated profile data, avoiding the re-entry of information to the application. Having also the possibility the ownership of an identity using the verification and authentication methods.
A did:web could bring each individual, business or organization a verified identity web presence. Or, to share their contact details, kind a visiting card, but digital and verified.
The web presence inclusion option for every inhabitant of the world could be possible, using the did:web, and their owned SSO to any application. Tapscott, describes a higher level of digital capital when applications can integrate to each other.
In some specific use cases, probably, more in the formal space, some legal and business processes, its deliverables, and some cross border transfers, require that the participant users be identified by some valid legal national ID. DID profiles could be ideal to bound them a valid national identity document.
Using a blockchain technological solution to bound a user's national identity document, for example, a national passport or national ID card, permitting a DID to be used by the user. This is an authorizing and bound process to the DID, as a proof of identity. When users are interacting in a transfer or business agreement, this identity attribution could be shared between them. This utility of proof of identity could satisfy KYC (Know Your Customer) requirement of some country governments. In this case, regulation, executed in a decentralized way, controlled, and owned by each user.
The proof identity should be an inscription of a DID bound to a National ID document, maintaining privacy, and security. The user could share its proofs of identity with the corresponding peers, when necessary, with the correspondent National ID Inscription. This type of inscription could be considered as Soulbound tokens (SBTs), a proposal for enabling non-transferrable cryptoassets that represent commitments, credentials and affiliations.
Another complementary Proof of Identity solution could be done by the reference of other users, that they know a certain user. Kind of a reputation ranking, like for example (https://trajan.app). At a certain, point one or more of the sponsoring users must have a more solid proof of identity issued by a valid legal national ID. These referrals can also be indicated in the user profile.
Immutability is an attribute that Blockchain technology offers to world society. A transaction, and/or the execution of a smart contract that cannot be altered.
This attribute of immutability could be transformed in an inscription service applied to different purposes. The first example of this type of service is the BNS, and the second NFT inscriptions for art or music work. Other examples taken from XCK.app are the business Agreements Inscriptions, payments, and business Deliverables Inscriptions. Ordinal inscription is another emerging inscription type stored directly on the Bitcoin blockchain.
Some of these inscriptions could be considered also as Soulbound tokens (SBTs), enabling non-transferrable cryptoassets, specially for business Agreements, and business Deliverables.
The Stacks blockchain smart contracts can leverage the usability of the Bitcoin ecosystem, could help manage the inscription process of Ordinals that has started recently. An inscription is not sufficient as a solution of being the first doing it. It should have management rules, that users abide to, in order to have real meaning, and value. The BNS can be used to acquire, manage, and distribute ordinal inscription, as other type of inscription assets, both in the Stacks or Bitcoin ecosystems.
Inscriptions could be leverage with the use of did:web for the users, and apps. An app inscription or an inscription executed by a user could be accessed publicly by a web service using the did:web protocol. So ideally, Blockchain Inscriptions could be turned into a standard Stacks Improvement Proposals - SIP. This standard could boost usability among other applications that reference this blockchain inscriptions. TXT records could be used at the zone file to connect BNS domains with inscriptions at ordinals.
A market of exchange of DID domain name is already operating. Since the BNS lets any domain name owner to transfer its property to another user, there has been interest specially among early adopters to save some âkeyâ names for future users, also as the STX exchange value is still low. There have been some proposals to change the behaviour of the BNS to facilitate storing list of domain names for future exchange. An example of an application that tries to help manage and saving different DID domain names is BNSx.
In the case of DID subdomain names is different, as the list maintained under its DID domain name in the zone file. Each DID subdomain name owns its own zone file specification, profile file, and its valid hash. The owner of the DID domain name is the only one that can update the list of subdomains under its domain name. For the exchange of subdomain name between one user to another, the domain name owner must provide a service to transfer its ownership, and executes in behalf of the owner.
Nowadays, the most common use for the blockchain, agreed by several countryâs Central Banks, it is its capacity to make cross border assets transfer efficiently.
Lately, the exchange of pieces of digital art using non fungible tokens, and similarly Ordinals in the Bitcoin network, have attracted the attention generating high level of transaction traffic.
Nevertheless, the use of decentralized ID (DIDs) has not been understood well, and used as it should be.
- The use of domain or subdomain names can facilitate the easiness to make inter user token transfer. Instead of using the Stacks or Bitcoin addresses, the users can use the DID as the address to execute transactions.
- The use of domain or subdomain names can facilitate the easiness to make inter used non fungible token exchange or transfer. Instead of using the Stacks or Bitcoin addresses, the users can use the DID as the address to execute transactions.
- Users can use their DID to login into hundreds of available compatible Dapps, like for example in chat boxes, sharing of information, publications, etc. As a Single Sign On method, easier to use.
- Users can use their DIDs to login, create and share business process agreements, and deliverables, sign them, and inscribe them in the blockchain using smart contracts.
- Probably, some business process agreements and deliverables, require that the participant users be identified by legal national IDs. Then a national attribution identity technology can be used by each one of the users, authorizing and linking it to the DID, as a proof of identity. This utility of proof of identity conforms to the requirement of KYC (Know Your Customer) imposed by some country governments. In this case, regulation, executed in a decentralized way, controlled by each user.
- Users could own a Single Sign On (SSO) technology to access any application.
- Users can use their did:web definitions as a web presentation landing page presenting their profile information. Individual web presence.
- Web marketplaces that recognize the use of did:web specification could facilitate the capture of user domain or subdomain names. These users will not be required to re-enter profile information, as the did:web specification can be accessed through a .json file and entered to the application. This functionality increases the level of digital capital of the person or the organization.
[1] Kenneth Arrow wrote in 1971 p. 22
[2] Bowles, Samuel; Gintis, Herbert. A Cooperative Species (p. 200). Princeton University Press. Kindle Edition.
[3] BahĂĄ'u'llĂĄh,
[4] Frankl, Victor
[5] 'Abdu'l-BahĂĄ Wings..
[6] Hashing (https://computersciencewiki.org/index.php/Hashing)
[7] Nakamoto, Satoshi (https://bitcoin.org/bitcoin.pdf)
[8] Ruff, Timothy, "The Three Models of Digital Identity Relationships", (https://medium.com/evernym/the-three-models-of-digital-identity-relationships-ca0727cb5186)
[9] (https://identitymanagementinstitute.org/evolution-of-digital-identification/)
[10] Digital Identity Guidelines (https://pages.nist.gov/800-63-3/sp800-63b.html#sec4)
[11] Authenticator Assurance Levels (https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/)
[12] (https://joinclicki.com/blog-full/understanding-dns-and-domain-key-to-digital-identity-and-trust)
[10] (https://link.springer.com/article/10.1007/s44206-023-00049-z)
[11] (https://en.wikipedia.org/wiki/Domain_Name_System)
[12] (https://en.wikipedia.org/wiki/Zone_file)
[13] (https://datatracker.ietf.org/doc/html/rfc1035)
[14] (https://www.icann.org/resources/pages/welcome-2012-02-25-en)
[15] (https://www.icann.org/resources/pages/zfa-2013-06-28-en)
[16] https://cloud.google.com/dns/docs/routing-policies-overview
[17] https://www.ioriver.io/terms/dns-zone
[18] https://www.lectron.net/docs/dns/dns-configuration-and-management/managing-dns-zones/
[19] (https://en.wikipedia.org/wiki/Public_key_infrastructure)
[20] (https://www.ittc.ku.edu/~fli/papers/2020_globecom_Secure_Cryptography_Infrastructures.pdf)
[22] Self-Sovereign Identity - Decentralized digital identity and verifiable credentials (Alex Preukschat, Drummond Reed Alex Preukschat, Drummond Reed, Manning Publications 2021)
[23] A Proposal of Change of the Components for the Stacks Decentralized Application Development Architecture, Roe Phillip (https://github.com/paradigma-cl/stackscomponents/blob/main/report_stacks_architecture_change_proposal_rev2.pdf)
[24] (https://datatracker.ietf.org/doc/draft-carter-high-assurance-dids-with-dns/06/)
[25] (https://www.ietf.org/archive/id/draft-carter-high-assurance-dids-with-dns-04.html)
[22] Stacks Blockchain - Bitcoin L2 (https://stacks.co)
[23] (https://www.usenix.org/system/files/conference/atc16/atc16_paper-ali.pdf)
[24] Stacks Core (https://github.com/stacks-network/stacks-core)
[25] Clarity-smart contract language (https://docs.stacks.co/concepts/clarity)
[26] BNS Smart-contract blockchain deployment version 1 (https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.bns?chain=mainnet)
[27] BNS Smart-contract blockchain deployment version 2 (https://explorer.hiro.so/txid/SP2QEZ06AGJ3RKJPBV14SY1V5BBFNAW33D96YPGZF.BNS-V2?chain=mainnet)
[28] BNS-v2 Documentation (https://github.com/Trust-Machines/BNS-V2)
[29] (https://docs.stacks.co/concepts/gaia)
[30] OSI Stack (https://en.wikipedia.org/wiki/OSI_model)
[31] The original Atlas Network was later merged with Stacks Core (https://github.com/stacks-archive/atlas?tab=readme-ov-file)
[32] Distributed Databases Stacks Components Proposal (https://github.com/paradigma-cl/stackscomponents)
[33] Web3 definition (https://en.wikipedia.org/wiki/Web3)
[34] Decentralized Identifiers-DID (https://www.w3.org/TR/did-core/)
[35] Decentralized Identifier (DID) (https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers)
[36] Schema (https://schema.org)
[37] Schema Person Object (https://schema.org/person)
[38] Identity Foundation (https://identity.foundation)