1490386 - Add/support the DID: protocol handler

Status: ASSIGNED

(WebExtensions :: General, defect, P3)

Description

[dbuc]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

As a developer, there is no ability to hook into the DID: protocol prefix when used/activated in web pages or extensions. The DID protocol is actively being worked on in the W3C Credentials CG, the Decentralized Identity Foundation, and numerous other groups. The DID spec can be found here: https://w3c-ccg.github.io/did-spec/

Example of where devs would like to use this: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers


Actual results:

Developers are unable to create content and extensions that extend the browsing experience DID-based activities and content.


Expected results:

I should be able to write extensions and other code that can leverage the DID: protocol as a browser-registered protocol prefix.

Comment 1

[Shane Caraveo (:mixedpuppy)]

We'd like the extension protocol_handler to remain very close if not the same as RPH. This request is about adding DID to the allow list.

@tantek any thoughts on allowing DID in RPH?
@dragana what is the decision process for adding protocols in RPH?

Comment 2

[OR13]

There are a number of related links for this here:

• https://chromium.googlesource.com/chromium/src/+/4e8ed0cecce04c5c55dd84a09e4df0d0f11c660f

I think this issue may be the best place for interested parties to start:

• https://github.com/mozilla/standards-positions/issues/339

Comment 3

[Anne (:annevk)]

The process for adding schemes to RPH is getting the scheme standardized in the HTML Standard. That hasn't happened here so we can either leave this open until that happens or WONTFIX. Per comments on the standards-positions repository I don't think we're particularly keen to add these kind of schemes.

Comment 4

[Javier Fernandez]

Per comments on the standards-positions repository I don't think we're particularly keen to add these kind of schemes.

Maybe we can continue the discussion n the standards-positions issue, to clarify what are the actual concerns. If I've understood it correctly, there are mainly 2 negative positions:

• "sharing a single origin" - https://github.com/mozilla/standards-positions/issues/339#issuecomment-630517916
• "need to review each scheme separately" - https://github.com/mozilla/standards-positions/issues/339#issuecomment-644289267

I believe Fred already replied to the first one, asking about the issue of Firefox already whitelisting ipfs / ipns protocols already for extensions. It'd be useful to understand better why this concern affects more to the HTML API.

Regarding the second issue, about apparently endorsing all the protocols once they are accepted in the safe-list, I may agree with doing an independent review of each of them. However, I wonder also about the fact that they are already considered safe by Firefox for extensions.

Comment 5

[Pierre Gronlier]

Attachment: WIP: Bug 1490386: add "did" as a valid protocol handler for extension

Comment 6

[Pierre Gronlier]

Hello,

Here is an example of a simple did:web resolver extension https://gitlab.com/pierre.gronlier/extension-did-web-resolver/ that can be implemented if https://phabricator.services.mozilla.com/D240768 is accepted.

Comment 7

[Rob Wu [:robwu]]

On the one hand there seems to be a desire for the list of supported protocols to be consistent with the web platform, and the issue tracking did support in the registerProtocolHandler method is at bug 1639016.

On the other hand, we have already accepted other non-standard protocols before in the extension-specific protocol_handlers field in bug 1428446.

Comment 8

[Pierre Gronlier]

Hello,

Chromium seems to have the same dilemma:

the documentation says that only https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme are safe

BUT

The code says that all below are valid, which include ipfs, did, ...

  static constexpr const char* const kProtocolSafelist[] = {
      "bitcoin", "cabal",  "dat",    "did",  "doi",  "dweb", "ethereum",
      "geo",     "hyper",  "im",     "ipfs", "ipns", "irc",  "ircs",
      "magnet",  "mailto", "matrix", "mms",  "news", "nntp", "openpgp4fpr",
      "sip",     "sms",    "smsto",  "ssb",  "ssh",  "tel",  "urn",
      "webcal",  "wtai",   "xmpp"};

Code history shows that did is in Chromium safelist since 2020-08-24 12:27

Could Firefox fast-forward 4years 😁?

Comment 9

[Rob Wu [:robwu]]

(In reply to Pierre Gronlier from comment #8)

Code history shows that did is in Chromium safelist since 2020-08-24 12:27

Your code history lookup got to the point where the line was introduced. That is not the same commit where these schemes were added. I found that these schemes got into Chromium with https://source.chromium.org/chromium/chromium/src/+/4e8ed0cecce04c5c55dd84a09e4df0d0f11c660f and the following commit message:

This CL adds "cabal", "dat", "did", "dweb", "ethereum", "hyper",
"ipfs", "ipns", "ssb" to the safelist of
navigator.registerProtocolHandler. Chrome status entry is [1]
and feature has been discussed in [2] [3] [4] [5]. Currently,
the WHATWG and WPT changes are pending on the Mozilla position
review [6].

[1] https://www.chromestatus.com/feature/4776602869170176
[2] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/29sFh4tTdcs/K4XroilVBAAJ
[3] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7nHTRUP1EGY
[4] https://github.com/whatwg/html/issues/3935
[5] https://github.com/whatwg/html/issues/3998
[6] https://github.com/mozilla/standards-positions/issues/339

Note that the last s-p link is the same as the one linked from bug 1639016.

Comment 10

[Pierre Gronlier]

Fair point @robwu

Would you know what is missing to move forward on the primarily topic of this ticket which is to add did to the list of accepted scheme handler for extensions ?

Who might be the proper reviewer(s) ?

Best regards