This has become important for feature policy, as we're round-tripping origins between renderers through the browser.

dcheng had a good CL for unique (actually opaque) origins which I want to use as a starting point here: https://codereview.chromium.org/2714813003/

The unique id, which all opaque origins should have, needs to survive a round-trip over IPC (either mojo or chromium IPC). A base::Optional<base::UnguessableToken> should work for both classes.

Other Key Issues:
- url::Origin is missing domain (and domain_was_set_by_dom, but that can be replaced with a base::Optional<string>),
- url::Origin is missing the ability to determine the 'default' port if it was unset (url::Origin's port_ member is essentially SecurityOrigin's effective_port_)
- Comparison and access methods (IsSame{Physical}Origin, CanAccess, IsSameSchemeHostPort{AndSubOrigin}, etc) need to be reconciled, and should match specs wherever possible
- is_unique_origin_potentially_trustworthy can be added to url::Origin -- we're already replicating it beside Origin in all places where it matters, so it may as well be part of that class, as it is in SecurityOrigin.

Following https://docs.google.com/document/d/19NACt9PXOUTJi60klT2ZGcFlgHM5wM1Owtcw2GQOKPI/edit#heading=h.g7bs0mwylz7g, I'd also like to remove the access-control bits from SecurityOrigin, but that may end up being a separate issue.

This is also related to 695622, where I'd like to rename 'unique' to 'opaque' in most cases. We will still need the concept of 'creating a new unique origin', which simply means a new opaque origin (which is unique by virtue of having a new unique id which is not shared with any other existing origin), but almost every other instance of the term 'unique' should actually be 'opqaue'

Also strongly related: https://crbug.com/490074

Just for some background, the reason I didn't land my original CL was because I was poking at how to make conversions fast. As this wasn't high priority at the time, I backgrounded the CL.

If this is critical, I'm happy to bring the CL up-to-date and figure out the conversions, so we can land the unique/opaque origin tracking: this is actually important for me now as well (I don't care as much about the other bits, though I think we should fix them as well).

That CL is crucial to getting feature-policy-controlled features working in sandboxed frames; right now there's no way for a sandboxed frame to know that the opaque origin mentioned in its feature policy refers to itself, and not some other opaque origin.

I'd started changing both Origin and SecurityOrigin to use base::Optional<base::UnguessableToken>, and plumbing that id through IPC and frame creation, but I'm happy to let you pick up where you left off with that CL if you're motivated :) 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/75414dbfcaa569ee97864695259b5e137c82e508

commit 75414dbfcaa569ee97864695259b5e137c82e508
Author: Daniel Cheng <dcheng@chromium.org>
Date: Thu Sep 21 02:33:21 2017

Only use url::Origin::UnsafelyCreateOriginWithoutNormalization for IPC

Tests should just use the constructor from GURL.

Bug: 712213
Change-Id: I38cd41b6fda1646074ac4620ce3c19cc2776fe3f
Reviewed-on: https://chromium-review.googlesource.com/674944
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mike West <mkwst@google.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Michael Nordman <michaeln@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503323}
[modify] https://crrev.com/75414dbfcaa569ee97864695259b5e137c82e508/components/autofill/content/common/autofill_types_struct_traits_unittest.cc
[modify] https://crrev.com/75414dbfcaa569ee97864695259b5e137c82e508/content/browser/dom_storage/local_storage_context_mojo_unittest.cc

Ian, is this still to be addressed?