Identity and Access Control in REMAP

Identity management systems represent a critical component of business infrastructure across the PropTech ecosystem, enabling secure identities and communication among various stakeholders. By identifying participants in real estate processes and validating their credentials, a reliable identity system fosters trust and helps mitigate authenticity and integrity risks. More specifically, in decentralized environments where KYC compliance presents unique challenges, these systems play a vital role in providing cryptographically secure methods for verifying identities, thereby reducing the risk of identity-related fraud.

As a core element of its identity system, REMAP employs a decentralized or self-sovereign identity (SSI) framework. SSI is a user-centric and privacy-focused identity framework aimed at empowering individuals with complete control over their personal information without relying on centralized identity providers. REMAP leverages a set of key SSI elements such as decentralized identifiers (DIDs) and verifiable credentials (VCs) to enable the creation, verification, or interaction of and among identities across the ecosystem. DIDs serve to uniquely identify entities within an ecosystem, while VCs provide cryptographically provable claims about the entities they describe. Our choice of integrating SSI within REMAP’s identity system is motivated by a proactive adoption of future digital identity systems as well as by the technical interoperability it enables. First, we anticipate the implementation of national and supra-national digital identity regulations that aim to digitalize and unify the specifications of identities within dedicated operational frameworks. Notably, the EU’s eIDAS 2.0 regulation mandates user-centric digital identity requiring EU Digital Identity Wallets (EUDIW) in every EU member state by 2024. These wallets can hold not only EU Digital Identity, but also independently issued credentials. Concurrently, projects like ID Austria aligns with the European Union’s mission for a trusted cross-border digital identity. The European Self-Sovereign Identity Framework (ESSIF), part of the European Blockchain Service Infrastructure (EBSI), aims to implement a generic and interoperable self-sovereign identity capability. By proactively adopting a compatible identity approach, REMAP prepares for a smoother transition and compliance with these upcoming regulations and projects. At the same time, our proposed design enables technical interoperability with existing and future SSI-based systems, as well as with legacy systems. This allows REMAP to communicate with processes pertaining to a wide range of external services, from credential-issuing authorities to financing and regulatory bodies alike.

REMAP Identity System

Current methods of identity management encounter significant limitations such as lack of individuals’ control over their personal data or a limited ability to seamlessly port identities across platforms. Additionally, centralized digital identity systems are often provided by for-profit corporations, which may undermine privacy-preserving design in an economy where information is increasingly valuable. To overcome these limitations, SSI enables increased control over user data, while enhancing the trust, transparency, and security of real estate data as well as processes. By integrating DIDs and VCs into the real estate project, several benefits can be realized. Firstly, the utilization of DIDs and VCs enhances the transparency and trustworthiness of identity and own ership claims, mitigating the risk of fraudulent statements or disputes. Secondly, it streamlines business processes by enabling efficient and secure identity verification of stakeholders, simplifying the screening and approval processes. Additionally, users’ privacy is respected by allowing them to control their own data and selectively disclose information through verifiable credentials. Lastly, the combination of on-chain and off-chain workflows ensures a seamless user experience while maintaining the security and immutability offered by blockchain technology and ensuring privacy by minimizing the amount of data that is stored on-chain.

In REMAP, we propose a flexible identity framework that can accommodate varying needs of both users and businesses, addressing concerns such as data privacy, process transparency, and efficiency. One main component of our design consists of separating flows between on-chain and off-chain processes, allowing for a flexible approach tailored to specific use cases. By interweaving these flows, REMAP ensures the protection of sensitive data by circumventing its storage on immutable public ledgers following the principle of data minimization. Simultaneously, we enable seamless automation through direct access to on-chain data by smart contracts. To achieve this, we use a robust array of off- and on-chain identity solutions. In addition to DIDs and VCs, we propose the use of non-fungible tokens (NFTs) and soulbound tokens (SBTs) for encoding privacy-agnostic credential data such as user roles, necessary for enabling smooth access control across development layers. While SSI can be seamlessly integrated on-chain, the nature of information pertaining to PropTech operations is prohibitive in the context of privacy-preserving frameworks such as EU’s General Data Protection Regulations (GDPR).

Identity System Components. The identity system in REMAP consists of several composable primitives to develop identity modules such as user or asset registration. Whether we speak of verifying decentralized identities or securely exchanging credentials, components such as NFTs, DIDs, or VCs help build a robust identity infrastructure for the entire ecosystem. In the following, we detail the core functionalities and contextual applications of each primitive.

 


Figure 8: Verifiable Credential Issuance-to-Verification flow.

One Issuer can provide VCs for many holders, and one holder may be issued VCs from many Issuers. Verifiers may verify the identity of the Issuer against a Verifiable Data Registry to check whether, e.g., the VC has been revoked. Decentralized identifiers (DID) serve as global identifiers distinguishing subjects from individuals to organizations and objects. The associated DID Document carries cryptographic material such as public keys for authentication or DID ownership verification methods. By leveraging DIDs, REMAP can establish trustworthy and persistent communication channels between entities, enabling secure interactions and data integrity. Additionally, the standardized DID format issued by the World Wide Web Consortium (W3C) ensures interoperability and compatibility across different systems and platforms. REMAP may employ various types of DIDs to meet specific requirements, such as static or dynamic, on- or off-chain DIDs. Off-chain DIDs cater to peer-to-peer communications, fostering secure direct interactions particularly for natural persons, while on-chain DIDs primarily cater to legal entities and offer immutability and transparency of identity data. Static DIDs, which are non-updateable, are useful for creating object-related identities, e.g., for properties or assets. As different DID methods come with different affordances in terms of integration, interoperability, or compliance with data privacy and security regulations, developers may select the one(s) that best fit their functional and security requirements.

Another critical SSI component, Verifiable Credentials (VCs), provides a framework for securely asserting claims about subjects. REMAP may leverage VCs to provide information about property ownership, legal rights, e-certifications, or regulatory compliance, and can be used to demonstrate qualifications, validate claims, or facilitate trust-based interactions.

A VC comprises one or more such claims made by an issuer (e.g., a regulatory body) about a subject (e.g., a property manager). VC schemas define the structure and semantics of claims within a credential. Due to their cryptographically verifiable nature, VCs enable the exchange and verification of information about a subject while maintaining the integrity and authenticity of such data. In turn, this provides a high level of trust and reliability for stakeholders across REMAP as they can verify a wide array information such as property ownership, rental history, licenses, and certifications. The VC process flow is illustrated in Figure 8. To share selected claims from across multiple VCs, users may compute verifiable presentations (VPs) which may hold varied information such as property transactions, rental agreements, or mortgage applications. In this process, a VC Issuer asserts claims about a subject and issues the VC to Holders. The latter control the VC, although they may differ from the subject of the claims. For example, in case where a real estate agent operates on behalf of a property owner, the relevant VCs are (also) controlled by the agent. Verifiers are responsible for checking the authenticity and validity of a VC/VP, hence the trustworthiness of the data. The verification process can employ a verifiable data registry that serves as a store of important verification information such as DIDs, VC schemas, and revocation registries. Revocation registries provide mechanisms for revoking and updating credentials should circumstances change or upon expiry of the validity of the encompassing claim.

Non-Fungible and Soulbound Tokens. Similar to DIDs, NFTs may serve as digital object identifiers that can prove authenticity and ownership for a wide range of assets including digital images or physical items such as rental units. REMAP employs NFTs to represent assets, prove their ownership, or implement access control, to name some of the most obvious use cases. More concretely, NFTs are useful in a variety of PropTech tasks, from mirroring physical assets in the digital realm, their ownership and rental rights, user roles to control access, or representing onchain certificates for any PropTech purpose. One important design consideration is that NFTs are always stored on-chain, which, for public blockchains, means that all data associated with an NFT is publicly available to the ecosystem. As such, careful consideration should go into what data is eventually stored in an NFT, to prevent overexposure of potentially sensitive data. In the context of real estate, such identity data can be the personally identifiable information (PII) of asset owners, which shall unequivocally be excluded from on-chain storage to ensure compliance with data privacy regulations. At the same time, to minimize on-chain storage, relevant asset documentation such as land plots or house plans, energy efficiency certificates, or structural integrity proofs can be stored off-chain and retrievable by the relevant decentralized application (dApp) upon request. Soul-bound tokens (SBTs) refer to NFTs that cannot be transferred between accounts, i.e., that are bound to the account they were issued to. Generally, SBTs can be used similarly to verifiable credentials, attesting to a subject’s qualifications and certifications, or they can securely restrict governance rights to approved parties in a role-based access control (RBAC) setting. Making these certificates available on-chain for all stakeholders to examine and verify, with their origin verifiable and their management automated via smart contracts, can minimize bureaucratic efforts. In REMAP, SBTs are primarily used as part of the access control model to assign roles to identities allowed to perform specific operations such as development and governance rights, or to represent credentials. For example, before deploying a module, a Layer 3 developer may need to provide a proof (e.g., in the form of an SBT) attesting to their expertise or confirming a thorough code audit by an auditing firm representing the credential issuer. Similarly to NFTs, several SBT standards exist, with module and dApp developers having the flexibility to choose optimal solutions for their products. REMAP users collect and store NFTs and SBTs in their wallets and demonstrate their ownership upon request, when interacting with a smart contract or other users. Like VCs, both NFTs and SBTs may have expiration dates, and SBTs can be revoked by their issuer when no longer applicable.

Different REMAP modules and dApps may implement simpler or more complex NFT or SBT interfaces, depending on the functional requirements. For example, fractional NFTs may be used to represent asset co-ownership, while multi-token standards can facilitate the batch-transfer of several related assets to be rented together. Ultimately, REMAP developers in consultation with a variety of stakeholders (businesses and end users) may choose the optimal identity primitives best suited for specific use cases.

Technical Challenges. Due to its privacy-preserving promises, SSI embodies an ideal candidate for identity management, particularly in decentralized systems where it enables trust through cryptographic guarantees over the authenticity of identity claims. Below, we highlight several open challenges for SSI-based identity systems and suggest how REMAP could overcome them.

First, SSI frameworks and subcomponents have not achieved technological readiness, meaning that crucial features are still maturing, under development, or missing. For example, identity recovery remains a challenge for the distributed system space where decentralized key management is implemented. For REMAP users, losing their keys poses the risk of losing control of their on-chain assets, impeding them from, e.g., establishing rental agreements for their real estate property represented on-chain. Existing proposals, such as key delegation or trusted quorum, may effectively re-centralized the system. Additionally, the novelty of SSI may translate to limited interoperability with legacy systems. For example, the issuance of interoperable documentation required for various business processes within REMAP, such as property acquisition contracts, may not be supported by legacy institutions. To overcome this, REMAP introduces the role of verifier agents tasked with converting legacy documentation and with issuing corresponding VCs to users. When applied to intensely regulated industries such as real estate, centralization points such as identity and credential issuance are carried over through select trusted actors and institutions. Such centralization requirements introduce single points of failure, may undermine privacy, and increase censorship risks. Nonetheless, with the introduction of identity frameworks such as eIDAS, as well as through additional research and development, we expect that such challenges will be eventually addressed from both regulatory and technical points of view.

Access Control in REMAP

Implementing access control is necessary for any secure system to mitigate risks associated with unauthorized operations. Attribute-based Access Control (ABAC, or policy/claims-based access control) represents an access control paradigm by which subjects are granted access to system operations based on bearing attributes. Role-based Access Control (RBAC) is an instantiation of ABAC whereby assigned roles attesting to one or several attributes enable access to a system or one or more of its subcomponents. The two main elements of an ABAC/RBAC model are the attributes and the governing policies. Attributes are equivalent to claims in that they describe the properties of a subject, object, action, or environment.

Within REMAP, multiple access control models may be implemented, depending on application requirements. For example, governance modules could gatekeep participation based on membership, i.e., whether a REMAP user has the role of DAO member. Likewise, module access could be enabled based on attributes such as being an asset owner for a user wishing to perform an asset listing. Attributes and roles can be encoded in a variety of ways, on- and off-chain, as VCs, NFTs, or SBTs. While roles may be atomic, such as “node operator,” they may also be defined by a set of required attributes which combined enable access to a system component. Access control policies can be implemented at the module, smart-contract, or function level, allowing or preventing users from accessing corresponding functionality. For example, only users with the role of “property owner” may access the asset listing method within a rental module. Below we exemplify two applications and how different access control components support the respective process flows.

Ecosystem development across layers. REMAP contributors may develop modules across layers depending on their affiliation or particular domains of interest. For example, they may develop an evaluation module within the Building Information Management (BIM) subdomain, to enable stakeholders such as architects, engineers, and other relevant parties involved in a real estate project to evaluate and eventually validate a proposed model. In this sense, REMAP may apply a RBAC policy to verify the module developer’s eligibility. Upon registering the module, the eligibility check is performed, and – should the developer satisfy the requirements – the module is further submitted for verification. A role may be embedded in an SBT, with REMAP users earning roles – and thus broader access – as they demonstrate their skills or attributes. RBAC implemented via SBTs or off-chain VCs provides a secure yet flexible framework for contributors to demonstrate their eligibility.

 


Figure 9: Sample Flow Diagram of REMAP new module evaluation.

Developers submit module proposals to the DAO. Before the relevant DAO’s assessment, the developers must prove their rights to submit the module for the given domain (e.g., BIM) through the respective role-based SBT. The module proposal is automatically rejected if the developer does not have the required access rights (i.e., role). Alternatively, the module can be assessed for quality assurance by REMAP developers or external auditors, before the relevant DAO decides its integration within the REMAP Module Library.

DAO governance. RBAC also plays a role in preventing unauthorized access to governance by enforcing policies on required SBTs for participation across various REMAP DAOs. To ensure that sufficient expertise is accounted for in governance decisions, the DAOs in REMAP app chains within the zones and layer-based DAOs require that given fractions of the organization consist of particular roles. For example, the financing domain may require that one-third of the DAO members (or of voters for specific proposals) represent financial institutions that are best equipped to develop, apply, and assess policies within the domain. Similarly, a minimum number of construction stakeholders such as structural engineers may be required for the corresponding domain DAO. As such, SBTs act as access passes allowing stakeholders to interact with modules or perform their governance duties. Role SBTs are REMAP native, with external certificates being issued upon request, e.g., if a user wishes to register for a given role. In turn, the SBT issuer gains access to the credential-issuance module through their corresponding SBT.

Unlike RBAC, ABAC offers high customizability and accommodates minor differences between subjects otherwise carrying identical roles. Nonetheless, REMAP aims to combine the two approaches in a flexible framework that can fit varying user and developer needs. Depending on the application, module developers can choose between the two designs and offer the access control granularity that best match the functional requirements. Similarly, within the same application, different access control methods can be used across the layered architecture, depending on the security requirements. In most cases, as both roles and attributes represent or are built upon the same primitive, namely on- or off-chain VCs, the user experience should be seamlessly integrated.