Should we support non DID principals ?

[Gozala]

Right now UCAN spec requires that principals be identified by DID URIs, which in turn motivated me to start defining did:mailto method so that we could use email principals.

Unfortunately DIDs even though decentralized are in fact logically centralized (perhaps that's why most methods are blockchain based) which seems to be at odds with (our) desired uses in UCANs. Specifically with did:mailto there is no desire to have canonical set of keys associated with that identifier, on the contrary we want an evidence inside the UCAN chain that specific did:key has been authorized to invoke certain capabilities on behalf of specific mailto: principal. We also several other things that DIDs do not address while UCANs do:

1. Expiry of the authorization.
2. Revocation of the key (or authorization rather).

DIDs require you to resolve canonical state and make it complicated to embed that state into UCAN instead.

There is also whole another thing with DID been set of keys, while UCAN principals been a specific key instead.

As a side effect mentioning did:mailto to people inspires questions about how one resolves the key(s) ? And even if you do resolve it which one has an authority to invoke which capabilities (If you call out key ids with fragment identifier in UCAN delegations you wind up having to introduce interior mutability, which is another 🥫🪱).

This got me wondering if it would be a better idea to relax a spec and allow principals to be an arbitrary URIs. That way we could define ucan-mailto spec without having to define did:mailto spec and avoid whole logical centralization. E.g. ucan-mailto could define how to represent mailto: -> did:key delegation without implying that the key is somehow associated with that email address.

[Gozala]

/cc @gobengo @blaine @expede

[blaine]

Yes, strongly support. I was having a very similar thought last night (I think prompted by @gobengo's comments about did-percent-encoding) and was getting close to writing up that we'd need a "canonical-form" for the issuer encoded in the UCAN in order to make NNS & WhoCANs work. The encoding of that would be exactly the same as you've just proposed: "mailto:", "https://", "acct:", etc.

A conversation with Brooke yesterday also provided some clarifying detail on where this might be useful:

UCANs, with did:key issuers (principals?), are capabilities.
WhoCANs, with non-did:key principals, are for delegation but are explicitly not ever to be used as capabilities themselves. They're just a way to prove ownership of a key that can be used for capabilities.

(let me know if that makes sense / needs tweaks / doesn't make sense!)

I don't know / have an opinion on the best way to encode this in the UCAN, but I support the approach in principle.

cc @cdata @jsantell

[expede]

Should we support non DID principals?

It's a good question, and has come up a few times! I'm not dead set against opening principals to being any URI, or alternately limiting them to public keys only (people have argued for both).

Unfortunately DIDs even though decentralized are in fact logically centralized (perhaps that's why most methods are blockchain based) which seems to be at odds with (our) desired uses in UCANs. Specifically with did:mailto there is no desire to have canonical set of keys associated with that identifier, on the contrary we want an evidence inside the UCAN chain that specific did:key has been authorized to invoke certain capabilities on behalf of specific mailto: principal. We also several other things that DIDs do not address while UCANs do

I'm not aware of anything in the DID spec that prevents did:mailto (see also did:key and did:pkh). One of the criticisms of the DID spec is that it's extremely general and you can express pretty much anything in there. It's true that the vast majority of DID implementations are based on some concept of consensus, but I'm not sure that there's anything that prevents one from using either a convergent or monotonic model instead. In concept, we should be able to write a resolver that checks an arbitrary UCAN chain, no?

Arbitrary URIs also open up the potential for confused deputies, since (e.g.) multiple verification methods on a single URI scheme mean that it's much easier to spoof the root of trust. We would need to define some new methods for signalling verification. I have the intuition that this puts us on a path to writing a parallel spec to DID that covers a lot of the same ground, but haven't explored it deeply.

There is also whole another thing with DID been set of keys, while UCAN principals been a specific key instead.

UCAN principals can absolutely be one of a set of keys today! We did a proof of concept with ION a couple years back and it worked well (other than the fact that not being self-attesting imposed additional latency and liveness constraints that we're hoping to avoid in a lot of our current work).

We also several other things that DIDs do not address while UCANs do:

Expiry of the authorization.
Revocation of the key (or authorization rather).

Yup absolutely 💯 These are slightly different layers: authN vs authZ. We sadly can't get away from authN completely (at least AFAIK), but you're absolutely right that we try to minimize it in UCAN as much as possible

[Gozala]

I'm not aware of anything in the DID spec that prevents did:mailto (see also did:key and did:pkh). One of the criticisms of the DID spec is that it's extremely general and you can express pretty much anything in there. It's true that the vast majority of DID implementations are based on some concept of consensus, but I'm not sure that there's anything that prevents one from using either a convergent or monotonic model instead. In concept, we should be able to write a resolver that checks an arbitrary UCAN chain, no?

You are correct that DID spec does not explicitly calls out "single source of truth", yet most of the spec seems to be written in a way that expect that to be the case. That is not to say we can't define a method that goes about it differently, it's just I'm not sure if benefits of doing it outweigh the tradeoffs.

Arbitrary URIs also open up the potential for confused deputies, since (e.g.) multiple verification methods on a single URI scheme mean that it's much easier to spoof the root of trust. We would need to define some new methods for signalling verification. I have the intuition that this puts us on a path to writing a parallel spec to DID that covers a lot of the same ground, but haven't explored it deeply.

I'm not sure I entirely follow this. My expectation was that spec defines how to verify UCANs issued by did:key, we could develop another ucan-mailto spec that would define how to verify UCANs issued by mailto: principals.

I realize there is some overlap with DID spec, yet I often find that most of the DID spec is irrelevant in UCAN context as you really just need a way to verify that issuer authorized specific UCAN delegation / invocation. Let me try and make it more concrete in case of UCAN mailto.

1. I have been delegated upload/list capability with did:key:zSpace from January to February to my email [email protected]

   {
     iss: 'did:key:zSpace'
     aud: 'did:mailto:web.mail:gozala',
     att: [{ can: 'upload/list', with: 'did:key:zSpace' }],
     nbf: jan,
     exp: feb,
     sig
   }

2. In order to redelegate this capability to say did:web:web3.storage I need to issue following UCAN and sign it with some key that can be verified to be owned by me.

    {
      iss: 'did:mailto:web.mail:gozala'
      aud: 'did:web:web3.storage',
      att: [{ can: 'upload/list', with: 'did:key:zSpace' }],
      nbf: jan,
      exp: feb,
      sig
    }

To accomplish this we need to:

1. Define did:mailto spec that would tell how one resolves key for the did:mailto:web.mail:gozala.
2. Since we do not need a "global source of truth" here somehow we need to embed resolved DID document into above UCAN e.g. in fct.
3. We need to (still) define ucan-mailto spec so that UCAN validator knows how to resolve key from embedded fct.
4. Assuming we want to implement discussed DKIM idea, we need to define format for the email subject that I could send from [email protected] capture and embed in the fct. Perhaps something along the lines of I am also known as did:key:zGozala

Even if we do all that we still have some problems:

1. What if someone mislead me to sending I am also known as did:key:zAttacker ?
   • We can perhaps define another revocation format for these kind of attestations, but that's yet another spec.
2. What if I want to authorize as [email protected] on some agent but for limited time ?
   • We could extend attestation message to include nbf and exp and att and that point we're just embedding UCANs in email subject and possibly making it easier for an attacker to confuse users.

---

Lets take a step back here. All I wanted to do is redelegate capability from my email address to some DID but instead I had to create intermediate did:key send an email proving I own it and then creating a delegation UCAN that I can sign with that key. And if that new key gets compromised I'm in trouble because I don't have a way to revoke the DKIM fact.

I think things could be both simpler and better if instead

1. I have been delegated upload/list capability with did:key:zSpace from January to February to my email [email protected]

   {
     iss: 'did:key:zSpace'
     aud: 'mailto:[email protected]',
     att: [{ can: 'upload/list', with: 'did:key:zSpace' }],
     nbf: jan,
     exp: feb,
     sig
   }

2. I could need redelegate that capability from my email

    {
      iss: 'mailto:[email protected]'
      aud: 'did:web:web3.storage',
      att: [{ can: 'upload/list', with: 'did:key:zSpace' }],
      nbf: jan,
      exp: feb,
      sig
    }

The best part is we don't even need a way to resolve key for mailto:[email protected] nor there is a key to be resolved. Instead ucan-mailto spec can define new Varsig format which essentially would be a DKIM-Signature header for the email message sent from [email protected] with a subject that is above UCAN signature payload.

This way deputy just needs to generate payload for UCAN per usual, ensure that it matches subject in the DKIM header and verify DKIM signature.

Not only we completely sidestep the whole DID documents and keys and resolution we also retained all of the missing functionality from UCANs like time bounds and revocations. We also don't have translate email address into idiosyncratic format just to make them DIDs.

UCAN principals can absolutely be one of a set of keys today! We did a proof of concept with ION a couple years back and it worked well (other than the fact that not being self-attesting imposed additional latency and liveness constraints that we're hoping to avoid in a lot of our current work).

This is what spec says today, which tells me that I could sign some UCAN today with my did:web today which may become invalid because I've added another key to the document. Again not end of the world, just another case of incidental complexity.

spec/README.md

Line 361 in 692e8aa

If an issuer's DID has more than one key (e.g. [`did:ion`](https://github.com/decentralized-identity/ion), [`did:3`](https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-79/CIP-79.md)), the key used to sign the UCAN MUST be made explicit, using the [DID fragment](https://www.w3.org/TR/did-core/#fragment) (the hash index).