Implementing a minimal identity (meta)system

[thelastjosh]

Tl;dr: we should see if Solid or some other service in Web3 has implemented a minimal, "claims-based" identity metasystem, and evaluate whether it's possible to import that metasystem into Metagov along with some basic support for building plugins and policies using the units of that metasystem.

Parts of this post are

Problem
Linked identity is a clear prerequisite to a range of possible governance policies that communities may wish to adopt. Linked identity is also necessary for certain Metagov services to function. For example:

1. A policy that bans a user from linked Discord, Discourse, and GitHub communities upon detecting a banning offense on any single platform.
2. (copied from @mashton's docs) The community has a SourceCred instance which is connected to Discourse, tracking users contributions on the Discourse platform only. The community also uses OpenCollective to submit invoices. Not all members have accounts on both platforms–– some may be members in Open Collective only, others are members in Discourse only. In order to support a governance policy that says “Invoices submitted by users with sufficient Cred are automatically approved,” the system needs to know that the OpenCollective user ‘joshua-tan’ is the same person as the user ‘joshua’ on Discourse.
3. SourceCred itself requires and maintains an "internal" concept of linked identity in order to aggregate contributions by single users within multiple platforms (e.g. GitHub contributes and Discord messages).

This is clear value in having linked or shared digital identities for users as well as for other entities such as organizations, roles, and resources.

Direct solutions (copied from @mashton's docs)
Linked identity can be accomplished directly through various forms of account linking; account linking is when user accounts from various identity providers are associated with the same user profile. In the above example, the record for OpenCollective user “joshua-tan” would be linked to the record for Discourse user “joshua.” There would be some core user profile record that lists all the accounts that belong to this user. That profile record could be curated

1. manually, by an admin who links accounts (without user consent) e.g. through something like Auth0 Management API (paid service) using the server-side account linking flow.
2. manually, the user links accounts themselves by providing credentials for each separate account
3. manually, as above but users are incentivized to link their accounts (e.g. see SourceCred's approach)
4. automatically, the system naively links accounts that have the same email address (without user consent)
5. automatically, the system prompts users to link accounts when the user logs in with the same email (with user consent)
6. automatically, the system infers linked accounts using data and machine learning (without user consent)

We got as far as the above before deciding that identity was out-of-scope for phase 1 of the Metagov prototype.

Proposal: an identity metasystem
I hypothesize that Metagov should not be in the business of providing a shared identity layer for its plugins, nor should it be in the business of determining the identity policies of particular platforms and communities.

Therefore, instead of an explicit identity layer, I propose that we implement (or import) a minimum viable identity metasystem (MVIM) for Metagov. Such a metasystem should expose a unified interface that allows services to "loosely couple" to a set of 3rd-party identity management systems. By implementing an identity metasystem as opposed to an identity system, we maintain Metagov's status as a backend service for governance authors.

Background and Definitions
This is clear value in having linked or shared digital identities for users as well as for other entities such as organizations, roles, and resources. Indeed, corporations spend billions on a generalization of this problem every year, called "[entity resolution[(https://www.sciencedirect.com/topics/computer-science/entity-resolution)". But the problem of providing a linked, much less unified, identity layer is extremely difficult. Kim Cameron has an excellent summary of why:

Why is it so hard to create an identity layer for the Internet? Mainly because there is little agreement on what it should be and how it should be run. This lack of agreement arises because digital identity is related to context, and the Internet, while being a single technical framework, is experienced through a thousand kinds of content in at least as many different contexts, all of which flourish on top of that underlying framework. The players involved in any one of these contexts want to control digital identity as it impacts them, in many cases wanting to prevent spillover from their context to any other.

Instead of an identity layer, Cameron argues that we need a identity metasystem:

The technology of “device drivers” enabled interchangeable hardware to be plugged in as required. [...] Digital identity requires a similar approach. We need a unifying identity metasystem that can protect applications from the internal complexities of specific implementations and allow digital identity to become loosely coupled. This metasystem is in effect a system of systems that exposes a unified interface much like a device driver or network socket does. That allows one-offs to evolve towards standardized technologies that work within a metasystem framework without requiring the whole world to agree a priori. [...]

She further argues that the concept of a "claim" is central to such an identity metasystem and "encompasses all the known digital identity systems and therefore allows us to begin to unify the rational elements of our patchwork conceptually. It allows us to define digital identity for a metasystem embracing multiple implementations and ways of doing things." To Cameron,

A claim is: “An assertion of the truth of something, typically one which is disputed or in doubt.” Some examples of claims in the digital realm will likely help:

1. A claim could just convey an identifier: for example, that the subject's student number is 490-525, or that the subject's Windows name is REDMOND\kcameron. This is the way many existing identity systems work.
2. Another claim might assert that a subject knows a given key; and should be able to demonstrate this fact.
3. A set of claims might convey personally identifying information; name, address, date of birth and citizenship, for example.
4. A claim might simply propose that a subject is part of a certain group; for example, that she has an age less than 16.
5. And a claim might state that a subject has a certain capability; for example, to place orders up to a certain limit, or modify a given file.

Note that, contrary to the problem setting above described by Cameron, Metagov does not need an identity layer for the whole Internet. It just needs an "identity open set" that covers the services needed for a single community. (Indeed the problem seems intractable at the scale of the Internet: Cameron posed her idea of an identity metasystem in 2006.)

Next steps
It's my belief that some kind of claims-based identity metasystem has almost certainly been implemented somewhere, i.e. the claims-based approach sounds vaguely familiar to docs I've read for things like Solid, DID, and self-sovereign identity. So the next step is to do some research / ask a knowledgeable expert who can point us in the right direction. I'll update this issue as we collect more information.

[gigxz]

Thanks for writing this up, super interesting.

You gave this policy example:

A policy that bans a user from linked Discord, Discourse, and GitHub communities upon detecting a banning offense on any single platform.

Is the idea that each of these platforms––Discord, Discourse, and GitHub–– would actually add support for the same "identity metasystem" (whether that's Solid WebID or DID or something else)?

[thelastjosh]

Possible identity arrangements, from hardest to easiest:

• Any of the decentralized/SSI approaches, e.g. WebID or DID
• Every service integrated through SSO
• …
• Metagov does its own identity linking—i.e. Metagov holds the canonical identity information across all services. In that case, Metagov would offer its own identity system for SSO, and provides this as a service to plugin authors.
• • This would support things like Roles.
• • Metagov identity linking would be per community per authentication system (e.g. Auth0, WebID, DID). Then Auth0 would be storing the “canonical” identity across different services for that community, and Metagov would store the Auth0 identity and use it to resolve identities to service-specific usernames and pass those along to plugins/services.
• Manual or automatic linking of accounts across services by the policy author / platform developer, i.e. entity resolution
• Every service has its own login/account information that it does not share, i.e. we don’t do identity linking

Note, you can have SSO without account linking, because the identity provider might not give you access to the distinguishable user information.

[gigxz]

I don't think I understand each of these bullet point options well enough to really be able to comment on this yet @thelastjosh .

Is the idea that each of these platforms––Discord, Discourse, and GitHub–– would actually add support for the same "identity metasystem" (whether that's Solid WebID or DID or something else)?

and I still don't have the answer to this question, but I can do some more research into decentralized/SSI approaches to figure it out.

--

Can we bring this back to what we're trying to accomplish to see if we're on the same page about that? Here's what I would like Metagov to be able to do. This example uses SourceCred(+Discourse) and Open Collective, but ideally we can do it for any external service that we have a Plugin for (Loomio, Discord, etc).

# use-case: Use SourceCred to decide whether to approve or reject an Open Collective invoice.

# this is in a PolicyKit policy:

oc_username = opencollective_event.initiator.username   # "miriam-ashton"
response = metagov.perform_action(
      name="sourcecred.get-user-cred",
      # this is directing metagov to resolve this username using the "opencollective" provider key
      user={"username": oc_username, "provider": "opencollective"}
)

# metagov magically returned my SourceCred value, even though SC does not have an OC integration
cred = response["value"]

So, there's lots of ways for that identity resolution to happen, I'm sure. But somehow, Metagov is able to resolve username from one provider ("miriam-ashton" in OC) to another provider ("miriam" in discourse/SC). Either this mapping exists in the Metagov DB itself, or Metagov uses Auth0 or some other service to track and maintain the identity connections. Somewhere, there is a record like this:

    ```json
    {
          "user_id": 1234,
          "connections": [
              {"username": "miriam-ashton", "provider": "opencollective"},
              {"username": "miriam", "provider": "discourse"},
              {"username": "miriam", "provider": "sourcecred"},
              {"username": "mashton", "provider": "github"},
              # and so on. This could include my NEAR wallet, my WM payment pointer, my Solid WebID(?), etc..
          ]
          # maybe there are metagov roles here too :)
    }
    ```

There are lots of questions here around consent, opt-in/opt-out, and how these connections are formed. But I think these connections DO need to exist in order for us to achieve all these cross-platform use cases we've talked about. Do you agree? Is using a "self-sovereign identity meta-system " supposed to make this obsolete somehow? That's the part I'm not following. Thanks!

[thelastjosh]

Is the idea that each of these platforms––Discord, Discourse, and GitHub–– would actually add support for the same "identity metasystem" (whether that's Solid WebID or DID or something else)?

I think the idea of a Metagov identity metasystem is not that these platforms themselves would implement an identity metasystem, but that every community would implement its own identity system. So the administrator of a multi-service, multi-platform Metagov community would have tools that allow her to choose whether to manually link identities across services and platforms, link them through user prompts, or through some sort of external SSI option. ONE such tool for linking would be an "off-the-shelf" Metagov identity system that solves the problem for services with a Metagov plugin.

But I think these connections DO need to exist in order for us to achieve all these cross-platform use cases we've talked about. Do you agree?

Yes.

Is using a "self-sovereign identity meta-system " supposed to make this obsolete somehow?

No. SSI is just another method of providing these identity linkages. It simply offers more security / control over personal information to the user, but also requires a lot more active permissioning + sophistication by the user.