first draft

[Gozala]

Preview

Please provide your feedback.

P.S.: I still think ucan-wg/spec#139 might be a better approach, but I do wanted to get thiso out of the way never the less.

[expede]

@blaine and I talked about the %-encoding a bit yesterday. I don't think the ugly %s are the end of the world, buthave you considered making this either a multibase or a hash?

A hash seems strange at first, but since you will have that info in the DKIM or similar later, you can validate it at that time. The downside is that it's harder for a human to track visually, but a fringe benefit is that you don't have to worry about encoding and they're constant size.

[Gozala]

@blaine and I talked about the %-encoding a bit yesterday. I don't think the ugly %s are the end of the world, buthave you considered making this either a multibase or a hash?

I was mostly bothered about this in because it would turn @ into %40 which is why I end up moving username into the tail of the did. Otherwise I think most email addresses won't actually encounter this so probably not a big deal ?

I have thought about hashes, but mostly for the user privacy, but then realized it probably won't provide much. At the moment I think %-encoding a reasonable compromise and seems to be expected approach for DIDs, but I'm fine taking it other way.

A hash seems strange at first, but since you will have that info in the DKIM or similar later, you can validate it at that time. The downside is that it's harder for a human to track visually, but a fringe benefit is that you don't have to worry about encoding and they're constant size.

I would prefer to not to with DKIM assumption, because we already have a system in place that adds did:mailto support without it, which I think will continue to be useful even when we implement DKIM support.

[alanshaw]

Are there any advantages to domain-name ":" user-name over user-name%40domain-name over the precieved uglyness of "%40"?

If no then I'd favor user-name%40domain-name because extracting it from the DID is way simplier.

[Gozala]

My rationale was:

1. Unfortunately new URL(“did:mailto:[email protected]”) does not get escaped, so it’s seems more likely to encounter malformed versions unless encoding is distinct enough
2. DIDs seem to love : delimiter, did:web even goes as far as replacing / with them, so this seemed reasonable
3. And yeah I find it harder to read

Above said I’m not feeling strongly about this

[gobengo]

fwiw I also kinda prefer the simplicity of just did:mailto:pct-encoded-email-address

We could also establish some norms around, regardless of did mailto, what to do if someone sends you a did that is not actually a valid did, e.g. did:mailto:[email protected] or just did:whatever:[email protected]. We could just say "percent-encode any colon-delimited segment in method-specific-id that isn't already in the valid alphabet, and implement that in @ipld/dag-ucan or something in DID.from

DID.from('did:whatever:[email protected]')
// did:whatever:bengo%40dag.house

This is a little inspired by how web browsers in practice don't always show you the perfectly encoded URL in the URL bar. It does its best to decode the url-like strings you put in there. If we do something like that, maybe we can avoid the annoyance of %40 instead of @ because a lot of our tooling will accept the @ and only throw when it really needs to be strict about being a compliant did.

[cdata]

Just wanted to add as an additional perspective: we use DIDs as domain-style origins within a human-author-able link syntax. For example, a user may write:

@did:key:.../foo

...or...

@did:web:example.com/foo

In the case of did:key, it is not convenient for a human to write by hand w/o copy-pasting the DID. In practice, we implement a petname system and alias DIDs by petnames that are easy for humans to write.

But, with did:web (and perhaps did:mailto), it is more plausible that a human will author a DID by hand, or read a link with a bare (not-petname-aliased) DID in it. And, for that case it would be preferable for did:mailto to be written and rendered without a %-encoded @ in the email address.

[gobengo]

it would be preferable for did:mailto to be written and rendered without a %-encoded @ in the email address.

I think we can accomodate this by in practice users just typing did:mailto:[email protected] but anywhere that gets that string as input and is casting it to a valid did needs to pct-encode the :-delimited segments to match syntax requirements of DIDs.

i.e. if the method-specific-identifier contains a @, you can tell it's not a valid DID, but that it wants to be a did:mailto, so software can deterministically get to a valid did by pct-encoding the email address.

[alanshaw]

One of the biggest reasons to revoke would be because the user lost access to the email address. Is there a way to revoke in this case?

How do I prevent any other user from claiming my did:key:x? Is it correct that we don't have to...because anything I send with issuer as did:mailto:x has to be signed with the private key for did:key:x.

Assuming that is true, anyone could claim they are known as did:key:x, but they wouldn't be able to act as did:key:x because they don't have the private key.

So then, presumably if I have multiple email addresses I can register them all as being aka did:key:x, so my question is what does "I revoke ..." mean?

Without signed proof, you can't revoke the use of did:key:x (since we don't know you have the private key) but it could revoke the use of the senders email address as an alias of did:key:x. Perhaps it is better for this to read "I am no longer also known as..."?

[Gozala]

One of the biggest reasons to revoke would be because the user lost access to the email address. Is there a way to revoke in this case?

Note that revocation here implies revoking a key as opposed to revoking a whatever permissions email has, which is I think what you’re thinking of. If I don’t have access to the email, I may want to revoke it’s privileges but that is to be done at another layer - delegation to the email address. That is out of scope here.

Reason you’d want to revoke here is because you’ve lost a private key, or perhaps key got compromised.

How do I prevent any other user from claiming my did:key:x? Is it correct that we don't have to...because anything I send with issuer as did:mailto:x has to be signed with the private key for did:key:x.

If someone say [email protected] associates my key with their email they are essentially granting me all the privileges that email address has, which is opposite of what they would want so there is no initiative to do this.

Assuming that is true, anyone could claim they are known as did:key:x, but they wouldn't be able to act as did:key:x because they don't have the private key.

I think you could put it that way.

Without signed proof, you can't revoke the use of did:key:x (since we don't know you have the private key) but it could revoke the use of the senders email address as an alias of did:key:x.

I think you’re thinking of association in opposite direction.

If I send you an email saying X is my key it’s reasonable to expect that messages signed by that key is from the owner of that email. If I then send you a message (from the same email address) saying I no longer use that X key it is reasonable to expect that if you see message signed with that key X it’s probably an attacker trying to impersonate me.

Here you trust that messages are from trusted source (email address) and what you verify is the DKIM signature to ensure that email is indeed from the owner of the address.

[alanshaw]

Ok I understand thanks for the clarification.

[gobengo]

It may be good to make a distinction between 'key authentication' and 'subject aliasing'. DID documents support both, but they're not identical. It looks like this section here, because it mentions 'I am also known as' seems like the human-readable instruction is more about subject aliasing and did-core alsoKnownAs.

"Key Authentication" could be confused with did-core's Authentication verification relationship. This is how a did can use its did document to enumerate the ways (e.g. a signing key) someone can authenticate as the did.

If you alias from your did:mailto:ab:c via alsoKnownAs to did:key:abc, you're authorizing did:key for all verification relationships, not just authentication but also assertionMethod, capabilityInvocation, and capabilityDelegation

So whereas the spec currently calls this "Key Authentication", what it's doing by using did alsoKnownAs is quite a bit more than that, and we might want to either:

• call what the spec currently does "DID Aliasing" and leave the perhaps-ambiguous 'key-authentication' unused
  • if you want to, say 'and you can only alias to did:key' (for now)
  • I think this is the best thing to do
• keep supporting a 'key-authentication', but have it only affect the derrived did document by adding an authentication verification method (not using alsoKnownAs
  • and maybe as the human readable string use I use {did:key} for {verificationMethod} where verificationMethod can be authentication

[gobengo]

The DID method specification MUST define sensitivity and normalization of the value of the method-specific-id.

https://www.w3.org/TR/did-core/#method-syntax

It's probably good to appease that MUST by having a small section on normalization. e.g. is it safe to canonicalize did:mailto:dag.house:bEnGo to did:mailto:dag.house:bengo?

I think the answer is no?

The
local-part of a mailbox MUST BE treated as case sensitive.

https://www.rfc-editor.org/rfc/rfc5321#section-2.4

[blaine]

I'm not a fan of the canonicalization complexity here. I have a bunch of use-cases for this sort of approach that extend beyond did:mailto: and can see the complexity spiralling out of control. This is not helped by the fact that these identifiers need to be checked with a simple string comparison; using modified "canonical" identifiers runs the risk of changing the security semantics.

tbh, if the intent of the did scheme is to be opaque, I'd prefer:

aud: did:mailto:${multihash(email)} along with some other field (maybe in fct?) that clearly states the hashed email address according to 5321 rules (but not canonicalized). (repeat for other schemes as necessary)

Looking through the DID/VC specs, it seems like this is the same conclusion that the VC folks came to: https://www.w3.org/TR/vc-data-model/#identifiers – specifically, there's a separate id field that is the raw URI identifier, separate from the credentialSubject did (unless I'm misreading this; there's a lot in these specs, and I may very well have missed something).

That all said, I would love to be convinced that the canonicalization is possible to do reliably; I just feel like there are too many unknowns there to be confident about it.