Fediverse

Honestly, ID verification wouldn’t be so bad if we didn’t have to worry about regimes using our data in ways we wouldn’t approve of. Has everyone forgotten that loading your drivers license into your Apple Wallet was (at first) an exciting idea; how long ago was that?

I would wonder whether ID verification can be made cryptographically secure, reliable, completely anonymous, and it’s tech stack FOSS. For example, if we could do something like public/private key pairs but where I’m validating my identity as a human rather than as a server. The thing is, how can we do it while (1) not centralizing the identity authority and (2) not requiring a priori trust relationships?

1. Users should not have to worry about a single point of failure/attack where their identity is concerned
2. Users should be able to sign-up for a new service and continue using it without ever having to pre-establish a trust relationship — like sending them a public key first.
3. The process should confirm I am human without confirming which human I am.

This is difficult for my brain. I want to say something like… what if we created a decentralized identity provider that was free to sign-up for and use, via (dare I say) blockchain technology?

A neat version of this, whatever works, would include the ability to reveal various attributes of my person on a service by service basis. For example, my bank can know my age but my Lemmy cannot.

That leads me to another point. Users should be able to authenticate with multiple services (e.g., bank, Lemmy) but the identity information provided to each service should not be compatible. It should inherently prevent cross-platform session stitching.

Which leads me to my last point. It might be worth considering a nerf on this thing… maybe it should not supply any stateful information about a single person — even to the same service — by default. This stops single-platform session stitching too, so users don’t need to worry about transparent tracking / fingerprinting [unless they choose to expose a static-attribute to the service and the service tracks it as a user-account].

This could be really interesting. Considering cryptocurrency wallets, I wonder how much of the necessary code already exists.

Edit: the most interesting part is, we can develop this the right way and use it against oligarch armies like Meta. The push for ID verification is using good-sounding arguments to do something bad. So, if we develop the tech first — which does the good things but none of the bad things — it forces Meta to either accept the terms or change their position to something much more failure prone.

Edit 2: okay, hear me out… I’ve got an idea, and it only partly requires a trusted authority.

Steps:

1. We establish a blockchain identity layer that’s free to sign-up and use.
2. User wallets contain signed statements from trusted authorities, kind of like digital notaries.
3. Signed statements can come directly from governing entities, like a college or DMV.
4. While governing entities are still getting their shit together, we establish a third party trustee who verifies documents and issues certificates. Documents are always temporary/deleted. Certificates are stable / timebound as necessary.
5. Users can create attribute-profiles, which contain a specific set of certificates. For example, a profile may confirm I possess a DMV credential showing age >18. without supplying a stable identifier, making it possible to prove age while impossible to track the same individual across sessions.
6. Users can optionally include more attributes in the a profile, for stable account tracking with a service.
7. By default, a service never gets a stable identifier. Not a wallet number, not a user id, nothing like that.
8. The service should maintain its own ability to supply a “service level ID” as a dynamic profile attribute. This should allow session stitching for the same service, but not across services. Rather than storing a bunch of IDs, I’d argue for a way to deterministically derive the IDs.
9. The service could even maintain its own session semantics with a dynamic “service session level ID.” It could deterministically change after a configured amount of inactive time. This would allow for every session to be a new identity while still being human-verified or age-verified — and the service wouldn’t even need to know about it. This is an acceptable risk, because services can still restrict account creation as-needed to profiles including PII attributes (e.g., for banking KYC). Services that don’t require PII can be scrutinized for any such requirements.

Interestingly too, what’s stopping this from working? If you have the infrastructure and it can be trusted as an identity provider, then it starts to look like a cost saving option. Services will integrate with it. Then the battle becomes getting it approved for things like banking.

But, above all else, it needs to be secure and trustworthy first.

Edit 3: it might be better to classify every usage of this identity layer. For example, if you use special hardware (e.g., local phone biometric reader) to authenticate your request to use your own wallet — then that particular callback should indicate “100% human” somehow. But if you just use your wallet by clicking a button on screen, then it should indicate “locally confirmed, but possibly scripted.”

This way, if a bot ever gets its hands on a wallet, the activity is still classified as the risk it presents. Humans, on the other hand, have a way (albeit slightly inconvenient) to fully certify any requests as human.

So the workflow starts looking like this:

Every authentication starts anonymous.

↓

Need age?

Reveal age only. [auth by local cert]

↓

Need account?

Opt into a stable pseudonym. [auth by local cert]
{can be service-stable or session-stable}

↓

Need legal identity?

Reveal legal identity. [auth by local cert]

↓

Need human?

Reveal humanity only. [auth by biometric]

Where profiles = groupings of attributes. You can select a profile as a way to log-in to a service. That service decides what to do based on the attributes you expose to it.

Profiles

○ Anonymous

    Human
    CAPTCHA-resistant

○ Adult

    Human
    Age >18

○ Banking

    Legal Name
    Address
    SSN
    KYC

○ Work

    Employer
    Department
    Employee #

○ Developer

    GitHub verified
    Email verified

○ Medical

    Medical License
    DEA registration

Services see something like this:

Authentication

Human Present:
YES

Verified by:
Secure Enclave

Biometric:
YES

PIN:
YES

Remote:
NO

Timestamp: ...

Attributes:
  - …

The service can simply decide: This proof corresponds to the same account as before. Now services model policy around risk and identity rather than just identity.

The full architecture could use blockchain for stable preservation of a persons attributes / certificates. But actually I don’t think that’s necessary either. If you offload risk onto the user, you can use this architecture too:

             Credential Issuers

 DMV      University      Bank      Employer
   │            │            │            │
   └────────────┴────────────┴────────────┘
                    │
          Signed Credentials
                    │
                    ▼
      +--------------------------+
      |      User Wallet         |
      |--------------------------|
      | Master Secret            |
      | Credentials              |
      | Attribute Profiles       |
      | Proof Generator          |
      +--------------------------+
                    │
     Pairwise IDs / Session IDs
     Zero-Knowledge Proofs
                    │
                    ▼
          Service Verification
                    │
      Learns only requested facts

No blockchain.