UCANs for social proofs

[Gozala]

Hi Folks,

I have been trying to design account registration / identification a system in which email verification could be decentralized and I thought I'd tap into collective intelligence of this group as some of you may have already thought about this.

Overview

Goal is to allow a user holding an account e.g. [email protected] to identify as did:key:user as long as they:

1. Have access to the email address [email protected].
2. Have private key corresponding to did:key:user.

General idea here is that there could be trusted service(s) with associated DID e.g. did:key:verifier that perform email confirmation dance (send a link to the email that user must click) for which they can issue a UCAN proving that service performed confirmation.

The way I have been thinking about it is as follows

User sends request (with CID bafy...req) to did:key:verifier with a UCAN claiming that did:key:user holds [email protected] account e.g.

{
   iss: "did:key:user",
   aud: "did:key:verifier",
   att: [{ with: "did:key:user", can: "account/access", id: "mailto:[email protected]" }]
}

Since issuer is the DID it will be signed via corresponding private key proving that claim is made by DID owner. Verifier service then can send a confirmation email to [email protected]. Once user clicks that email verifier can issue derived(?) UCAN:

{
   iss: "did:key:verifier",
   aud: "did:key:user",
   att: [{ with: "did:key:user", can: "account/access", id: "mailto:[email protected]" }]
  prf: ['bafy...req`]
}

This time UCAN is signed by did:key:verifier private key and certifies that it indeed confirmed that user:key:user has access to the [email protected] account.

Why do this ?

Idea here is that second UCAN could be used to register account in e.g web3.storage that would map to the claimed email address and a did. Furthermore verifier service could become standalone independent service that many other services could interop.

I focused here mostly on email as it's a very common pattern but same technique could be applied to various other identities e.g. keybase.io style social proofs could be implemented as well.

I think wallet auth could even be done without verifier service, simply by signing UCAN with a wallet.

Issues

Something about this approach does not seem right and I can't seem to identify what or how to do better. Specifically there is this relation between first and second UCAN which does not seems to be captured. On one hand if you trust did:key:verifier proof isn't really necessary, but on the other hand how do you know that email owner did not just claimed a DID they have no private key for ?

I have considered adding separate field into capability instead, however it seems like it would be recreating UCAN proof anyway so that does not seem right either. Maybe something should go into "fct" instead ? Somehow I don't find it to better.

Is this something you have thought about before ? Or maybe have an idea what the right approach is ? If so please provide your insight.

[bmann]

@Gozala I think we need to look at Verified Credentials for this as a step one, rather than re-inventing. They have a whole DID <> VC thing. From there, we can understand where we store / how we communicate / share VCs.

[gobengo]

Perhaps ccg would be willing to host a meeting about UCAN https://www.w3.org/community/credentials/

Same for DIF WGs https://identity.foundation/

[expede]

@gobengo We definitely want to get there one day (hence setting up IPR early: #41). We've been advised by several people inside the W3C and IETF that the UCAN spec probably wants to stay much more nimble than the process inside of named orgs.

In fact, my company (cofounded with Boris, above) is a member of the DIF, and someone at the DIF suggested the template in that PR :)

[expede]

But not against talking to folks involved in these efforts! UCAN has lots of overlap with SPKI, for example

[gobengo]

This from zcap-ld "Relationship to Verifiable Credentials" seems relevant to the use case being discussed:

We seem to be in a conundrum. Claims and credentials are forms of correlation that allow us to reason about an entity in our squishy human world, but are unsafe when used as mechanisms to authorize some event to occur within a system. Capabilities are a safe mechanism to model the flow of authority through a system, but there are times when capabilities have not been granted and we need to make a "judgement call" by correlating information about that entity. What should we do?

To pose the question is to see the answer: the right approach is to use each system for what it does best. Use correlation (Verifiable Credentials) in a reasoning system (most commonly human reasoning) as a path to make judgements about whether to hand an entity a specific set of initial capabilities. Use capabilities (ZCAP-LD) as the mechanism to grant and exercise authority through computing systems.

By that argument the email verifier system may be interested in issues a VC rather than UCAN.

@bmann I think this could be the JSON that corresponds to the VC Credential context.

{
  "@context": ["https://www.w3.org/2018/credentials/v1", { "account/access": "hl://account-semantics-hashlink" }],
  "issuer": "did:method:email-credentialer",
  "credentialSubject": {
    "id": "did:key:end-user",
    "account/access": "mailto:[email protected]",
  }
}

Now, it would be rad if there was a signature/proof, and if there was a way of encoding the whole credential so it could be added as a proof or prf in other delegations. One promising way is using LDI.
A more UCANish way might be the VC JWT encoding

(jwt body)

{
  "sub": "did:key:user",
  "iss": "did:method:verifier",
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      {
        "account/access": "hl://account-semantics-hashlink"
      }
    ],
    "issuer": "did:method:verifier",
    "credentialSubject": {
      "id": "did:key:user",
      "account/access": "mailto:[email protected]"
    }
  }
}

The end-user could then verifiably present this credential and exchange it for a capability it entitles them to (e.g. upload to bucket named 'mailto:[email protected]').

[expede]

Hmm yeah interesting idea. We've thought a bit about including other kinds of credential in UCAN, like FIDO certificates. Worth thinking about more, for sure!

[expede]

@Gozala

Yeah, this is not that different from say, Sign In With Ethereum (SIWE). Self-attestation or ID linking like this is one use case of the facts field 👍

I have on the back burner writing a SIWE spec, but you're right that a more general pattern like proving access to email addresses totally makes sense 💯

[expede]

(I'm just working through a list of TODOs for the day; I'll circle back and flesh this out more)

[expede]

Okay haha 😅 This is what Saturdays are for, right? @Gozala thank you for being patient. Good news: we've actually looked at this exact scenario previously. I also see that you put some time in my calendar for Monday -- looking forwards to chatting about this live as always 🎉

I hope that the below is helpful, and that I understood your use cases correctly! The top sections are mostly about philosophical orientation about VCs vs caps, and then onto your direct use case (as I understand it), and finally onto "what you could do with this pattern" and some related flows.

Views

There's two ways of viewing it, and legitimate use cases for both. They're surprisingly close in practice, so it can be a subtle distinction:

As a Verifiable Credential (VC)

The VC take on this is that you're attaching some statement about the human holding the credential. At its core, this approach is about "identity".

The classic example is a government issuing a VC that says "the holder of this DID is at least 18 years old". In this view, it's a statement about the holder.

As @gobengo points out, there's enough of a structural similarity here that other projects like zcap-ld have explored putting VCs directly into the token as a dependency. I've also heard from others looking to use UCAN to root trust in totally P2P networks (not Bluesky this time!), and need to pass around statements about "who" the agent is.

You can do this by leveraging the facts (fct) field, though it doesn't really map super cleanly onto UCAN. Which brings me to...

As a Capability

In the cap view, we say that some authority is granting the ability to do something. This is about the "capability" to perform some actions, and doesn't care who the holder is outside of the credential. It's not "is the owner of the email", but "is allowed to send email from this address", and can be attenuated further (e.g. "can only send to these recipients", "only for the next hour", or "only without file attachments").

How To Approach It

Idea here is that second UCAN could be used to register account in e.g web3.storage that would map to the claimed email address and a did. Furthermore verifier service could become standalone independent service that many other services could interop [...] Furthermore verifier service could become standalone independent service that many other services could interop [...] I think wallet auth could even be done without verifier service, simply by signing UCAN with a wallet.

Yes, exactly! The trusted server in this case at minimum plays the role of a nameservice: it controls mapping DIDs to human-readable names. It can then go further and provide further services, as long as the user delegates rights to the server's DID.

As an example, here's what Fission's flow looks like today:

1. Alice opens webpage
2. Key is generated in background (they have an "anonymous" DID)
3. Alice fills out the sign up form with a username and email
4. The form submits a request along with a UCAN (containing the DID) to register that username & email
5. Confirmation email is send to the Alice to verify her account
6. Alice clicks the link in the email, which tells the server that the email is confirmed
7. The _did.alice.fission.name TXT record is updated with Alice's "root" did:key as one way to distribute that human readable mapping to other users (could also use ENS, IPNS, a REST server, did:ion, etc)

This is really "just" a nameservice flow. Note that the actual DID was created browser-side. If she has a use for it, Alice can now also delegate capabilities via UCAN to the server, to run cron jobs, index her data, append data to her account, and so on. The UCAN itself doesn't need to know about any of that.

There are two use cases that you allude to that aren't covered in the above flow:

1a. Sending Email
1b. Proving Control
1c. Proving Ownership
2. Account Recovery via Trusted Service

1a. Sending Email

Email services often have an OAuth interface. That trusted server can act as a UCAN/OAuth bridge. In this case, the trusted server ("Trusty" from here on) "owns" the OAuth capability. Trusty does the OAuth dance with dmail, which includes part of the user flow signing into their email as normal. Now Trusty has am OAuth refresh token, and can act as a dmail proxy. Trusty then delegates a UCAN to did:key:zAlice, granting her super user access to the email. She can then turn around and subdelegate this capability (or a subset) to did:key:zBob.

This keeps things very cleanly inside capability territory.

1b. Proving Control

In Web 2.0, we focus a lot of "who" someone is. If you want to prove that you're talking to the "owner" of the email, you can look at the UCAN and check that it has super user capability (it's "observationally equivalent to the email owner").

This delegates well in a UCAN chain. As with all UCAN resources, when you actually go to do something with the capability, you need to validate against the trusted service. If you're showing that some DID has sending rights to the email, the prover (Alice) can delegate a UCAN with no capabilities, essentially saying "hey, I want to show that I can do this, even if I'm not actually doing so right now". The verifier passes this along to the trusted server at some "can they really do this?" endpoint, and it responds with a yes/no.

We do something extremely similar to this in AWAKE (essentially MTLS for UCAN handshakes), using that idea of observational equivalence. https://whitepaper.fission.codes/accounts/login/awake#4.-session-key-negotiation-over-ucan In this case, we're establishing an encrypted P2P channel for purposes of UCAN delegation, and want to make sure that there's no person in the middle (PITM) attacker. We ask the provider to show that it already has the capabilities that we will be requesting. It creates a UCAN with att: [], and we can inspect the chain to show that they're able to do this, but if it was intercepted it's useless to the PITM.

1c. Proving Ownership

If you want to show that a DID is the one true owner of a resource, a verifiable credential is a great option! This is a statement about a specific user. It doesn't delegate, because any of the delegates may not be that specific user (e.g. it may actually be Bob)

Account Recovery via Trusted Service

Recovery with a trusted service is very straightforward, if a bit dangerous. You really need to trust the server and that it won't get broken into. Essentially you wildcard delegate to the server's DID, and now it can act "as you". If you lose your key, the server can validate that you're you via email, and redelegate back to the newly created did:key:zAliceNEW as normal.

The security can be tightened up with approaches like BLS recovery cosigning, where an attacker would need to get into both the server and the users device.

[expede]

Also want to loop @bmann into this part of the discussion, especially about the VC vs caps approach. We've had some requests around for sign into Fission via email (i.e. without key management), which has the tradeoffs of around the OAuth gateway as described. Essentially you can "downgrade" to Web 2.0 very easily, but using OAuth as the sign in method to upgrade to web3 is really difficult. That second one is not what we're talking about above!

[Gozala]

@expede we talked through this over the call quite a bit, but still want to describe how I was imagining the flow which is very similar to one you've described above:

1. Alice wants to authorize cool-app.link to store content in her web3.storage account
2. cool-app.link generates keypair for Alice in the background
3. Alice fills out auth form with her email address
4. cool-app.link forwards toauth.link with Alices did (base on kepair that was generated)
5. web3.storage entrusted auth.link with email verification capability by issuing { can: 'access/identify', with: 'email:*' } UCAN to it.
6. Alice types her email at auth.link
7. auth.link sends confirmation email to Alice.
8. Alice clicks the link in the email, confirming she wants to associate her email with a did generate by cool-app.link.
9. auth.link sends request to web3.storage with a derived UCAN { can: 'access/identify', with: 'email:${encrypt(web3StoragePubKey, alicesEmail)}' } and redirects to cool-app.link.
10. web3.storage receives request to associated Alice's account with cool-app.link generated did and does so.
11. coo-app.link generates self-issued UCAN with { 'can': 'store/add', with: did:key:zAlice } which it uses to store Alices data in web3.storage
12. web3.storage stores data for Alice as it is associated with her account & bills her accordingly.

Recovery here would be be no different that authorizing with another app, just associating new did with an account.

[Gozala]

One thing that have I recognized since writing the post is that it would make more sense if:

1. Main service (which will require identification) would issue token to a verifier services e.g. for email it could look like follows, which basically says this service can delegate email identification capability to specific users

{
  iss: "did:key:main-service",
  aud: "did:key:verifier-service",
  att: [
    {
      can: "access/identify",
      with: "did:key:*",
      as: "mailto:*"
   }
  ]
}

2. Then user could talk to any verification service that have above capabilities to obtain delegated capability for a specific email address (that service verified out of bound)

{ 
  iss: "did:key:verifier-service",
  aud: "did:key:user",
  att: [
    {
       can: "access/identify",
       with: "did:key:*",
       as: "mailto:[email protected]"
    }
  ]
  prfs: [
    {
      iss: "did:key:main-service",
      aud: "did:key:verifier-service",
      att: [
        {
          can: "access/identify",
          with: "did:key:*",
          as: "mailto:*"
       }
      ]
    }
  ]
}

3. User that could use that UCAN to identify as [email protected] with any did of choice in the example below with did:key:user and did:key:backup-user.

{
  iss: "did:key:user",
  aud: "did:key:main-service",
  att: [
    {
      can: "access/identify",
      with: "did:key:user",
      as: "mailto:[email protected]"
    },
    {
      can: "access/identify",
      with: "did:key:bakckup-user",
      as: "mailto:[email protected]"
    }
  ],
  prfs: [
    { 
      iss: "did:key:verifier-service",
      aud: "did:key:user",
      att: [
        {
           can: "access/identify",
           with: "did:key:*",
           as: "mailto:[email protected]"
        }
      ]
      prfs: [
        {
          iss: "did:key:main-service",
          aud: "did:key:verifier-service",
          att: [
            {
              can: "access/identify",
              with: "did:key:*",
              as: "mailto:*"
           }
          ]
        }
      ]
    }
  ]
}

Now user has not proved here that they own private key for did:key:backup-user, but that is probably not a big deal as they would not be able to use that capability without the private key.

I am still not exactly happy with all this as there are implicit dependencies which seem bad.

I should also probably mention that I was hoping to use this to perform requests from clients for which we do not even have accounts. E.g. if we get request to store some content along with a proof that they have valid email that had been verified, we could just create an account and store that content without roundloops.

[bmann]

@Gozala totally get the use case. And, for example, we think of it as the same way. Fission can verify an email, and ideally we can send Fission created DIDs with attached proofs saying "yes, we verified an email" over to NFT Storage, and you can choose to trust that we have indeed verified an email so you don't need to do it. I don't think you actually want to send the email, at all. This is where the verified credential comes in. hasVerifiedEmail == true -- but you don't need to know what the email is. Would a verified email work for you or do you need the email itself?

[Gozala]

hasVerifiedEmail == true -- but you don't need to know what the email is. Would a verified email work for you or do you need the email itself?

That is very interesting point. On one hand we do not necessarily need to know an email (if we ignore the fact that sometimes we may need to reach out to the user) but on the other hand we need to associate various DIDs with some account and that was the underlying purpose here.

In other words idea here was that access/identity could also be utilized to recover from key loss, by allowing user to identify with a different DID. Although maybe that could be accomplished without having to know the email.