RFC: Proposal to standardize email to DID translation

[Jan Christoph Ebersbach]

I'd like to see established global identifiers become translatable to new DID identifiers so that people don't have to remember/learn a new identifier. In particular, I find email addresses to be a) one of the few globally accepted and widely spread identifiers and b) built on the DNS system like did:web is.

Therefore, I propose to extend this specification with a translation mechanism from email addresses to did:web DIDs, e.g. [e-mail] -> did:web:example.com:john.doe / https://example.com/john.doe/did.json. In my understanding, this translation is mainly relevant for implementers of user interfaces that request identifiers from users to ease their way into SSI and to hide DIDs from them.

I see the following issues with this proposal:

• DIDs are URIs while email addresses are just identifier-host tuples. Extended features like query parameters and paths can't be represented.
• Spammers use the technique of iterating identifiers to find accounts on mail servers. A direct correlation between the email address and the DID would allow spammers to iterate publicly readable did.json HTTP endpoints to find valid email addresses. Having said that, this attack vector might exist regardless of this proposal because operators could choose to implement did:web with human-readable identifiers that resemble valid email addresses.

Non-goals:

• The goal of this proposal is not to make it possible to represent all possible did:web DIDs as email addresses. For example, an email address couldn't represent a DID with a path: ?? -> did:web:example.com:accounts:sales:john.doe

Without the standardization of email to DID translation, implementers could still choose to follow the proposal and try to resolve the corresponding DID. However, chances of success would be higher if the standardization existed and server operators would naturally adopt the mechanism.

I'd love to hear your thoughts on this idea.

[Ted Thibodeau Jr]

I question whether a wholesale translation of email addresses to DIDs is appropriate.

Also, I think it's important to note that mailto:[e-mail] is a mailto scheme URI based on your example email address.

In this case, there is probably a one-to-one relationship between that URI and the humans it has ever reached — but that might change in the future, after john.doe's eventual demise or employment change, depending on the rules example.com has in place at that time.

In other cases, a given mailto: URI might be a role address, which reaches different humans over time (e.g., [e-mail]), or a distribution or mailing-list address, which reaches multiple humans at one time (e.g., [e-mail]).

All that said, past work on WebID has considered using URIs from multiple schemes, starting with http/https, and likely adding mailto. My employer settled on using NetID as an superset of WebID, permitting use of URI schemes other than http/https, which remain the only schemes currently listed in the WebID draft specification, including mailto.

[Jan Christoph Ebersbach]

@TallTed thank you for pointing out the mailto: scheme.

I'm not too worried about the differences in use cases between email addresses and DIDs since the use case and its correct implementation comes at a higher level.

I'm not familiar with WebID or NetID and how people deal with URIs as user names. What's your experience, how do people handle multiple different URIs schemes and : and /s in their user names?

Do WebID implementations support simplifications of the user name similar to browsers that translate example.com to http(s)://example.com/?

I just realize another issue with the proposal - email addresses aren't case sensitive while URIs are. So, did:web:example.com:John.Doe could not be pointed to by an email address.

[Ted Thibodeau Jr]

@jceb --

It seems you may need to read more RFCs and other standards before you propose a new one, as your current proposal seems to be based on a number of misconceptions, unfamiliarities, and oversimplifications.

You say --

What's your experience, how do people handle multiple different URIs schemes and : and /s in their user names?

Colon (:) and slash (a/k/a solidus, /) are treated as any other character in a user identifier (often simplified to "username"). These characters may require special treatment for database or other storage and other use, but that's a server-side question, not a user-side question.

Whatever identifiers (username, WebID, NetID, etc.) someone may use, each identifier has one URI scheme. There may be some form of aliasing between URIs to indicate that those URIs refer to the same entity. (This is known as "co-referencing", and is often indicated by recording owl:sameAs relations between those URIs.) Depending on the sophistication of the implementation, one server-side system may accept only one URI for each user, or it may accept any of their identifiers as synonyms.

The user might also want to restrict System A to knowing about one identifier, while System B is told about two identifiers, and System C is told about all the user's identifiers. An extreme but fictional example here might be members of the Rebel Alliance, who don't want the Empire to know their Rebel identifiers, but may want other Rebels to know how they're identified to the Empire.

Do WebID implementations support simplifications of the user name similar to browsers that translate example.com to http(s)://example.com/?

As with many things, "it depends on the implementation." Note that [web] browsers do not so much "translate to" as "try" these variants, which may include prepending various other schemes to URIs input by users without a scheme. Such a list of schemes to prepend may be built into the web browser, or may be user configurable, or both.

Systems that use WebIDs to identify their users may only accept that WebID when the user logs in, or may accept some/any of the user's specified/chosen label values — depending on how many users there are, how unique the users' label values are, etc.

email addresses aren't case sensitive while URIs are. So, did:web:example.com:John.Doe could not be pointed to by an email address.

As you'll find in the eBNF within § 4.1.2, "Command Argument Syntax", of RFC 5321, "Simple Mail Transfer Protocol", the Local-part (sometimes shorthanded to "username") MAY be case-sensitive (and even though nearby advice is that a host that expects to receive mail SHOULD avoid defining mailboxes where ... the Local-part is case-sensitive).

(Yes, many systems treat email addresses (a/k/a Mailbox values) as case-insensitive, and convert mixed-case values to either all-caps or all-lowercase for storage and later use. To my mind, at least, those systems are not RFC-compliant and should be treated as broken.)

---

tl;dr: The answers to your questions boil down to "it depends" or "it varies". There are no real short answers, so going forward, there are no real simple solutions, only deceptively simple solutions.

[Jan Christoph Ebersbach]

Thank you for your reply and insights into WebID. I understand from your reply that the smtp and WebID standards just define one way of identifying users while real-world implementations add their own "enhancements" or simplifications. So for my proposal I gather that the email to did:web translation is something that should be left to the implementations rather than being specified here. - This makes sense to me and I'll close the issue.