[NeoID] Design of Moonlight

[lllwvlvwlll]

Introduction

As a required deliverable of the Moonlight product offering, we are implementing a self-sovereign identity solution. This implementation uses a hybrid on-chain/off-chain approach to identity which is designed to support industry standard application workflows.

A major benefit of our approach is that it is designed to enable projects without requiring any knowledge of blockchain (both at a developer and end-user level). This makes the solution very appealing for adoption as well as onboarding into the ecosystem.

From a workload perspective, there is minimal load on the Neo development team because it is being implemented by the Moonlight team, a group with substantial development experience in the Neo ecosystem. This solution is also already in development so the timeline is very appealing.

There is also a PR benefit because it shows willingness of the Neo team to collaborate with dApps building on their platform. Currently, this reputation is not in the best condition and it is critical to improve this reputation if we want to attract projects to the ecosystem.

The solution is a strong and very practical candidate for NeoID. We are willing to disclose more information as needed.

List of Terms

• Claim - A collection of attestations which are made against an entity on-chain at the same time. Claims are contained within a specific topic whose format is defined in a NEP. A literal grouping of attestations representing a write intent.
• Attestation - An atomic information field within a claim. Attestations are a statement about a target entity.
• Profile - A symbolic group of one or more attestations representing a read intent.

Structure and Behavior On-Chain

Architecturally, this solution implements a collection of contracts, each with a limited scope to improve maintainability and security. The contracts are tied together by a DNS-like solution which allows script migrations without incurring breaking changes on the users of the identity platform.

Attestations and Claims

Its important to note that this solution is designed to be payload agnostic. Claims can include content ranging from highly sensitive credentials to publicly visible statuses. In order to support this range, attestations can support multiple encryption formats: 1) Publicly available (plain text) 2) Encrypted (symmetric) 3) Encrypted (hybrid [PGP-like]) 4) ZKPP ( H(value + nonce) )

An attestation represents a single field within a larger claim object which may have multiple attestations that are contextually relevant to each other (like the many fields on a passport). For common claim topics, NEPs define the attestations and their format. The solution is permissionless so the standards are critical in order to support multiple claim providers.

Claims support limited editing by the submitter (redaction and expiration). This is a critical feature because it allows the platform to support claims which are time-sensitive.

Identity

Within this solution, identities play a critical role in relationship to claims. An individual claim is made against an identity(A) by another identity(B). Each identity may be represented by one or many users with different types of roles (e.g. admin, read, or write access). Access grants to attestation payloads may be provisioned by either the claim provider identity or the target identity if the individual's role supports the function.

Profiles

Profiles are a group of attestations which are bundled together symbolically under the same access grant. This allows an entity to grant access to a collection of attestations together. Under the same access grant, profiles can then be provided through various means to users without the overhead of numerous time-consuming invocations at the time the access grant is provisioned. Its important to note that a profile may contain attestation grants which span subsets of multiple claims. Where claims represent a write intent, profiles represent a read intent.

Documentation, SDK, and Offchain integration

The solution supports three methods of access with varying usecases dependent on the user's need.

• Documentation: An individual may interface directly with the contracts to access claims via neon-js, neo-python, neo-go etc... by referencing the platform documentation
• SDK: An SDK is provided with support for the contract ecosystem as well as the offchain features of the solution
• Offchain integration: A number of offchain solutions are available to enable the ecosystem, allowing entities to use the solution with/without familiarity with blockchain.

Accessing Data

Data access paths are presented in a number of different ways depending on a requestor's state relative to the claim. Claims may be accessed by topic, claim_id, or profile. Rather than incorporate explicit functionality into the solution to define trust of claims submitters, we use this open system and allow the users to define their own solutions based on the state of the ecosystem. In this way, the solution is timeless.

Validation provider

In addition to the solution outlined above, Moonlight also provides a validation service for a number of claim topics.

I propose an internal review of some features by a few core devs in order to evaluate the strengths of some of the features which have been intentionally let out of this github issue.

[gracegui43]

Thanks for addressing your ID solution. Can you provide more details of it for us to understand how it works? #1304

[lllwvlvwlll]

I've updated the root comment with more information.

[belane]

Thanks @lllwvlvwlll, great overview of your solution. I have some doubts that maybe you can clarify me.

• Can you describe how different identities/roles interact with each others and what the flow is like.
• Is there, or there can be, any trust chain between validation providers?
• Can you list some of the advantages or disadvantages compared to the other proposed solutions?

[lllwvlvwlll]

@birmas may be able to provide some additional content to @belane 's questions (specifically #1)

1) Generally speaking, the roles provide access grants over administration of claims. An entity(A) which has been granted an administrative role to another entity(B), is treated equally to the (A) when granted access to claims and attestations (for example). This allows multiple entities to security manage claims against another entity (consider a business where multiple users need to grant access to claims against the business entity)

2) A trust chain can be built by linking claims together using a pointer as one of the attestations. Each claim is signed by the claim submitter.

3) I think this is difficult to do because there is a lot of be "implied" from reading a ~1000 word technical overview of each. I can say that our team is very open to collaborating on the initiative (and changing feature prioritization) to make sure that it meets the needs of as many stakeholders as possible. If we want it to be successful, it needs to accommodate the needs of the users. Some immediate advantages that I see are the following:

• We have spent a considerable time in planning (since the beginning of the Moonlight project) and this solution has been identified as optimal. We believe that it effectively leverages the blockchain to its strengths without overburdening it with other features which is is not designed to support.
• The structure is very flexible and supports a very wide range of usecases. As mentioned in the previous bullet, our goal is to produce straightforward solution without implying/imposing usecases. We propose that projects build on top of this platform to implement specific usecases.
• The solution is permissionless in use, but permissioned in access to data. As a permissionless blockchain, it is critical that we do not act as a governing body which dictates "trustworthiness" of individual entities. This should be defined by the applications using the platform.
  • With this solution, the Moonlight team is also delivering attribute validation, which is a critical component to making any of these identity solutions a success. These features do not necessarily accompany the other solutions.
  • Resource optimizations within the ecosystem is a unique benefit. This platform leverages resources which are not from the same pool as the other two solutions. The opportunity cost is lower for this solution because it does not draw from resources working on other components of Neo3. I also believe there are some business advantages to collaborating with dApps in the ecosystem instead of competing with them which extend beyond the advantages listed in this bullet-point.

[vncoelho]

Hi @lllwvlvwlll, recently, in the last Core Dev meeting there was a discussion about comming back with NeoID discussions and https://github.com/neo-project/neo/issues/1304 was reopened.

I am not sure, but it looks like that Moonlight solution is now VividID, right? If that is the case, maybe we could rename the thread like "Design of Moonlight VividID", such as https://github.com/neo-project/neo/issues/1306 and https://github.com/neo-project/neo/issues/1305.

The VividID has a good scheme for Profiles and also its simplicity. I still miss some of the features of AthenaID, which would provide a Graph of Trust, which would naturally enable several possibilities for applications and reputations systems.