Spinning off from #2759 (comment)

It's confusing that "origin" as defined right now is seemingly spread out across DOM/HTML/URL/File API. Not to mention the obsoleted "Origin of a URI" spec.

My suggestion would be:

• Fix Origin of blob URLs doesn't match what implementations do url#127 / "origin of a blob URL" is redundant/confusing w3c/FileAPI#63 so that the File API just defers to the URL Standard instead of overwriting it
• Move the definition of the origin type, as an opaque origin or tuple origin, into the URL Standard. Ideally the URL Standard should not depend on the HTML Standard for the aspects it deals with. So also move serialization and maybe the same-origin checks.
• Now we can more clearly start defining "x's origin" in various places: audio/video elements, image elements, Document objects, URL records.
  • Each needs its own distinct <dfn> instead of everyone linking to a central origin definition. This makes it clear they are properties of a (whatever), and their type is origin.
  • Move the definitions into the appropriate sections. This is easy for img/audio/video, where we define the associated concept as an algorithm to return the right value (as opposed to as a mutable internal slot).
  • For Document we should for now move it, without changing it, into the Document section of the HTML spec, as an override to DOM's definition---i.e., overriding DOM's mutable-internal-slot idea with our own algorithm-to-return-the-right-value idea.
  • But over time we should explicitly set its value at various places, instead of saying "if this happened somewhere, then the origin is X". Then we'll be sticking with the mutable-internal-slot version for Document.
  • Related: Reference document's origin accurately #1725

Curious what @annevk thinks.