Identifier use in Browsers

Full Title or Meme

The ways that browsers interact with the user's Identifiers is tracked here.

Context

• Recent changes from the major browser vendors to improve privacy have impacted the existing use of front-change OpenID Connect authentication.
• The challenges of self-issued identifiers in existing browser has had low user adoptions due to our user experiences.

Problems

Just a random collection of issues.

from Justin Richer (Note that eh AS - authz server - is likely to be include in the same package as Wallets.

Ultimately, in most situations like these in the real world, the hurdle isn’t technical compatibility so much as it is trust compatibility. The RP (client) needs to have some incentive to trust the assertions and identity information that’s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard question is less “how” to do that (which SSI answers), but more “why” to do that (which SSI doesn’t answer very well, because it’s a hard question).

Still: it’s definitely a question about how to support this “AS on device” element. We’ve got the start of it more than OAuth2/OIDC have by allowing the bootstrap of the process from a starting call: the interaction and continuation URIs handed back by the AS don’t need to be the same URIs that the client starts with, so just like SIOP the process can start in HTTP and potentially move to other communication channels. A major difference is that we aren’t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel messages that SIOP relies on doesn’t fly. That said, we’ve got an opportunity to more explicitly open up alternative communication channels here, and that’s something I’d like to see engineered, even if it’s an extension. I’d love to see a concrete proposal as to how that would work over specific protocols, starting with what we’ve got today.

Solutions

Generally these are blink-dev issues either proposed or in development.

• Same-site policy has been added and slowly enhanced to block cross-site scripting attacks (CSRF or XSRF) by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain. This site describes the varying impact that this policy has on users on the various browsers. The challenge for [Single Sign On]] efforts with a Identifier or Attribute Provider at a different site than the Relying Party is that they rely on cross-site cookies to pass user credentials from one site to another. The problem introduced with iOS 12 from Apple is described on this site.
• First-Party Sets and 'SameParty' cookie attribute has two "explainers" as GitHub pages First Party sets and same party. Introduce a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. (A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set.) Allow sites to indicate which cookies are intended to be set or sent in contexts where all ancestor frames belong to the same First-Party Set.

References

• See the wiki on Trusted Browser for ideas on creating a User Agent that is responsive user security concerns.