3.2 Roam Protocol

The W3C’s DID standard is one of the key components of Roam protocol. The decentralized identifier (DID) is a new, verifiable, and decentralized type of identifier. The DID architecture is shown in Fig. 22. A DID can point to any subject, such as person, transaction, organization, device, etc. It can also be parsed into a corresponding DID Document, which can express the encryption material, verification method, or service that points to the subject. Through these methods, a DID Controller can prove their control over a given DID. In order for the data to be parsed, the verifiable data registration center is responsible for storing DID and DID Document content. The registration center can take any form, such as a distributed ledger, decentralized file system, database, etc.

The DID format is shown in Fig 23. A DID is composed of the fixed Scheme “did”, DID Method, and identifier in the corresponding DID Method. The DID Method defines how this particular DID type is created, parsed, updated and destroyed.

Roam protocol follows the W3C’s DID standard [21], and focuses on its implementation via a permissionless blockchain.

The Elliptic Curve Cryptographic (ECC) algorithm is mainly used to generate the user's DID identity, and must be consistent with the blockchain which Roam protocol uses. Algorithms like SECP256k1, SECP256r1, and ED25519 will be employed in different SDKs. The corresponding private key is the user identity private key.

3.2.2 VC Data Model

The W3C also has a standard for the Verifiable Credential (VC). The VC is the user's digital credential, which has the same function as their physical credential. A verifiable credential is a tamper-evident credential whose authorship is cryptographically verifiable. Compared with a physical credential, the VC provides encryption security, respects privacy and allows for machine- verification, which is a more suitable method for use in Web 3.0 network scenarios.

The VC ecosystem is shown in Fig 24. The Issuer issues a VC to the Holder, who sends proof of it (the VC) to the Verifier. All participants verify its authenticity through the VC data registry. For example, the Issuer records the certificate format information and issuer information in the registration center, and Holder and Verifier check the authenticity of the certificate through the registration center and cryptographic algorithms.

The basic components of the VC are shown in Fig 25. A VC includes metadata such as issuer information of the credential, expiration date, etc. The credential declaration includes the attribute information of the credential and the certification information of the issuer of the credential.

The basic components of the Verifiable Presentation (VP) are shown in Fig 26 [22]. A VP is a display information which consists of metadata, the VC, and proof data. Enhanced privacy is a key feature of the design of this specification, so selecting and exposing only appropriate attribute information is very important for the implementation of this technology. It is common to use zero knowledge proof algorithms in a VP generation and validation process, which ensures that there won’t be any privacy leakage concerns. The VC part can contain the attribute information of multiple VCs.

Roam protocol follows the W3C’s VC standard, and focuses on its implementation via a permissionless blockchain. Hash Algorithms SHA256, KECCAK-256, etc., are used to generate the hash value of the message to be signed with a private key.

Since Roam network utilizes DID/VC to achieve OpenRoaming network authentication, ID providers who want to let their users roam into this network need to download the SDK from Roam foundation to become a VC issuer. This SDK is fully compliant with the W3C’s DID and Verifiable Credential standards.

3.2.3 Privacy Protection with DID-VC

Roam allows users to use DID and VC to login to the WiFi system, with all the interactions constituting this process being recorded on a blockchain. A zero-knowledge scheme could be implemented in the VP to add privacy protection to it. In this case, a derived VC (instead of the original one) which encrypts all of the holder’s private information will be placed inside the VP.

ZKPs have two types: interactive and non-interactive. Non-interactive zero-knowledge proofs are cryptographic primitives where information between a prover and a verifier can be authenticated by the prover without revealing any of the specific information beyond the validity of the statement itself. The key advantage of non-interactive zero-knowledge proofs is that they can be used in situations where there is no possibility of interaction between the prover and verifier, such as in online transactions where the two parties are not able to communicate in real time. The ZK- SNARK (Succinct Non-Interactive Argument of Knowledge) is a common implementation of the non-interactive ZKP, and the proof size is limited, making it easy to use. Plonk (Permutations over Lagrange-bases for Oecumenical Non-Interactive arguments of Knowledge), Bulletproof, and SONIC are also common ZKP schemes.

Interactive ZKPs are more suitable for Roam applications, where a challenge is required during the log-in process, like authentication processes using the Challenge-Handshake Authentication Protocol (CHAP). A protocol implementing zero-knowledge proofs (of knowledge) necessarily requires interactive input from the verifier. This interactive input usually takes the form of one or more challenges such that the responses from the prover will convince the verifier if and only if the statement is true, i.e., if the prover does possess the claimed knowledge. If this were not the case, the verifier could record the execution of the protocol and replay it to convince someone else that they possess the secret information. In this case, the new party's acceptance would either be justified since the replayer does possess the information (which implies that the protocol leaked information, and thus, is not proved in zero-knowledge), or the acceptance would be spurious, i.e., it was accepted from someone who does not actually possess the information.

Roam protocol design refers to a design similar to the Hyperledger Indy blockchain. Hyperledger Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo. Indy is interoperable with other blockchains, or can be used as standalone infrastructure powering the decentralization of identity [23]. The Camenisch- Lysyanskaya (CL) signature, Boneh-Lynn-Shacham signature, and other cryptographic signature schemes are employed by Roam protocol. These algorithms are used to either assist in selective disclosure of VC/VP data, or to prove that the attribute values satisfy a certain condition using zero-knowledge algorithms.

Taking the CL signature as an example of a selective disclosure algorithm, the details of its implementation are as follows:

There are three parties in the credential scenario: the issuer, the certificate holder, and the verifier. We assume that the certificate holder has L attributes (m1, m2, m3, ..., mL) that need to be issued by the issuer. The certification process is as follows:

1) Key Generation

The issuer randomly generates two prime numbers {p, q} as the private key, which multiply to create a number n from the private key p and q:

n = pq

Then, L+2 random numbers are generated by calculating the quadratic remainder of modulo n:

where, (a1, a2, ..., aL, b, c, n) constitute the public key of the message.

2) Signature Generation

The issuer generates a random prime number e, and a random number s. Assuming L input attributes in the format of mi, (m1, m2, m3, ..., mL), the issuing authority calculates a value v that satisfies the following formula:

(e,s,v) forms the signature of the message (m1,m2,...mL)

3) Signature Verification

Given a signature (e,s,v), a message (m1,m2,...mL) uses the issuer's public key (a1, a2,...,aL, b,c,n) to check whether the following formula is satisfied:

If true, the message invoked above proves that the certificate was issued by the issuing authority and has not been tampered with.

CL signatures support zero-knowledge proofs and selective disclosure of attributes. In the above steps, when the certificate holder sends a message to the verifier, one of two methods could be adopted:

• 1) Send mi directly to the signer/verifier, then the signer/verifier calculates (ai^mi) mod n

• 2) Calculate (ai^mi) mod n, call the commitment of mi, and send the commitment to the signer/verifier.

Since the discrete logarithms are mathematically difficult, it is challenging for the signer/verifier to infer the value of mi from the committed value, so the signer can generate the signature without knowing the original value. Similarly, a verifier can verify certificate attributes without knowing the original value.

For example, a certificate holder has attributes (m1, m2, m3) and wishes to disclose only (m1, m2) in the message, while m3 uses a zero-knowledge proof. When the issuing authority signs the certificate, the certificate owner sends (m1, m2, a3^m3 mod n) to the issuing authority. When presenting the proof and the certificate owner only wants to disclose the attribute m2, they send (a1^m1 mod n, m2, a3^m3 mod n) to the verifier, who can prove that the certificate owner has not tampered with the attributes of the certificate, and who can see the value of m2.

3.2.4 Trust over IP Stack

The Trust over IP technology stack developed by the Linux foundation is referred to in Roam’s architecture design. In the typical ToIP stack, Layer 1 is the utility layer, which supports the public DID utilities needed to look up and verify the current public keys of digital credential issuers. In public/private key infrastructure, these cryptographic “starting points'' are called roots of trust, or trust anchors. ToIP Layer 2 is the communication layer, which supports the private digital wallets and agents needed in order to accept, store, and exchange digital credentials over a standard peer- to-peer protocol such as DIDComm. Layer 3 is the data exchange layer used to create the verifiable credential trust triangle that enables the establishment of transitive trust relationships between any three parties anywhere in the world using the data exchange formats and protocols for verifiable credentials. Layer 4 is the application layer, which enables the market applications needed to build healthy, vibrant digital trust ecosystems atop this new decentralized digital trust infrastructure.

Roam is one kind of implementation of Trust over IP in terms of real-world application. The W3C’s DID and VC standards are relevant to ToIP Layer 1 and Layer 3 respectively, and they (DID and VC) are the foundation of Roam protocol. In addition, Roam protocol supports multiple DIDs for the same subject on one or multiple blockchains, and these subjects on different chains can use the Layer 2 DIDComm protocol per ToIP to communicate. Roam protocol provides a blockchain independent DID layer design which will greatly facilitate such communications. In the end, Roam protocol will support all the applications described in ToIP.

ToIP aims to provide a robust, common standard and complete architecture for internet-scale digital trust (as shown in Fig. 31), which is the basis of Web 3.0’s user centric network. At the same time, the Linux foundation intentionally neglected to define how to implement ToIP. In fact, one of the key design principles of ToIP is that every protocol in the ToIP Technology Stack must be implementation-independent. Roam protocol is one such implementation, and provides a complete sdk to support applications built on ToIP.

The following design rules are followed by Roam protocol:

• 1)  To maximize security, privacy, and confidentiality, cryptographic private keys should be stored at the edges of the network, not on intermediate nodes. Roam protocol allows users to control their own private key. The devices which are used to support Roam-enabled decentralized wireless network access, edge computing, storage, and caching will have their own private key stored in their own trustzone or similar hardware vault.

• 2) As part of digital trust, messages and data structures exchanged between parties should be verifiable as authentic using standard cryptographic algorithms and protocols. Parties communicating over ToIP protocols should expect communications to be secure, private, and confidential without any special thought or action required on their part. Roam protocol is developed based on proven cryptographic algorithms and is consistent with industry-acknowledged standards. All communications that occur within the Roam-enabled network will remain secured and confidential by design.

• 3)  To be trusted by all parties, a global network cannot favor any single centralized service or authority; it must allow functionality and authority to be distributed as widely as possible. Roam protocol follows this principle and will advocate a decentralized and self-operational wireless access network as well as an edge computing and storage / caching service network. These networks are expected to form the foundation of Web 3.0, for which no centralized service will be used.

• 4)  For maximum utility and adaptability, the best place to put a network’s intelligence and processing is at its endpoints rather than in the communications subsystems that connect those endpoints. This principle is consistent with the nature of decentralized communication infrastructure.

• 5)  In a layered protocol architecture, the most successful design takes an hourglass shape where a single “spanning layer” in the middle connects a family of higher-level, application-facing protocols via a family of lower-level transport protocols. Roam was developed to support higher level data oracle protocols, authentication methods, and other user applications. On the other hand, it supports a lot of communication and network protocols like IEEE802.11u.

3.2.5 Blockchain Network Independence

In the traditional DID scheme, the private key of the DID user and their blockchain wallet address are the same. This design prevents the DID-based authentication process from being isolated from the details of the given blockchain platform where it is carried out. We believe that the core content of the DID consists of the different private keys that identify the user's identity; and that each private key should have a single purpose. Based on these ideas, we designed the Roam protocol.

First of all, we distinguish the wallet private key of the blockchain from the DID private key. For example, registering and updating a certain DID can be submitted by any blockchain address. At the same time, the blockchain will verify the legitimacy of the transaction itself, and a smart contract will check the submission for whether the data has a legal signature of the private key corresponding to the DID.

Secondly, in the basic library design of DID/VC, we separate the blockchain-related codes from the system access components. The overall architecture is shown in Figure 6. For the basic DID information, we use the same structure, and for the registry, we use different registration methods according to different blockchains.

3.2.6 Improvements over Hyperledger Indy/Aries

Roam protocol’s design takes as a main reference the DID / VC implementation developed by Hyperledger Indy/Aries, which has been predominantly contributed to by Sorvin. Sorvin’s Self- Sovereign Identity (SSI) concept and Hyperledger Indy/Aries inspire Roam protocol’s design concepts. Roam protocol is necessary for the DID / VC implementation, however, as Hyperledger Indy is very difficult to port to other blockchains.

Roam DIDs and Indy DIDs share the following similarities:

• (1) Both are designed based on the SSI concept.

• (2) Both represent mature implementations of DID / VC, with the Roam zero-knowledge proof algorithm borrowing the mature implementation of Indy.

The main differences between these two DIDs are:

• (1) Indy is based on its own blockchain design, development is tightly coupled with its own blockchain, and it is difficult to port to other platforms. One of the original design motivations of Roam protocol was the need to make adapting to other blockchains more friendly.

• (2) The business goals are different. Indy/Aries is mainly positioned as a certificate issuing platform. Roam provides a user authentication infrastructure that protects user privacy based on the issuance of credentials.

3.2.7 On-chain Data Access

As a data exchange layer protocol, Roam protocol is designed for data interaction and supports on- chain data enquiry. Although the DID and VC are stored locally in the user's own wallet, the following information will be stored on a blockchain which the user can access via SDK.

The smart contracts on-chain include:

On-Chain registration

On-chain registration maintains the status of each VC (whether it is valid or not). When the verifier validates a VP, it relies on the on-chain registration to confirm the status of the VC, which is used to generate the VP.

On-Chain Mining Device Status and Location

Each Roam mining device will have a VC issued by the foundation. Each device will report to the on-chain smart contract their status, which includes their PCOI, location, QoS level, etc. Besides PCOI, most information publishing is optional for the access point (miner) hosts.

Validator Management

Any user who stakes a certain amount of tokens can become a network validator. To gain validation rights, they need to present a VP to the validator management smart contract.

Validation Management

Each time a validator validates the status of an access point, they interchange the VP between each other, and the VP of the other party will be embedded into the mining rewards request made to the smart contract. It will also validate the status and location information posted by the miner on-chain.

Network Usage Check

Each time a user logs in to a Roam-powered OpenRoaming network, it is optional to post the relevant information to the blockchain for further data analytics purposes. Which data shall be posted will be determined by the community.

3.2.8 Roam Protocol System Architecture

The following system architecture is proposed for Roam protocol. It is designed to work with multiple L1 networks as an independent DID / VC middleware tool.