View source for Identifier use in Browsers

==Full Title or Meme==
The ways that browsers interact with the user's [[Identifier]]s is tracked here.

==Context==
* Since the time of Netscape, browsers have been called user agents. At first that name was not particularly the way a browser functioned, it was just a render engine. As new demand for privacy and security proliferate, the browsers and increasing advertising to the user their concern for user welfare. At first this was just PR, but it seems to have taken a life of its own and is becoming a fact. 
* Recent changes from the major browser vendors to improve privacy have impacted the existing use of front-channel [[OpenID Connect]] authentication, especially for federated logins.
* The challenges of self-issued identifiers in existing browser has had low user adoptions due to our user experiences. The issues there are discovery and launch of the authentication code from the browser.
* Browsers generally come with [[Password Manager]]s, which are, in effect, connection/relationship managers between the user and a website authority. Theoretically the user can select their own password manager, but that does not appear to be a common case.
* The use cases for this topic are on [https://github.com/IDBrowserUseCases/docs git hub].

==Problems==
Just a random collection of issues.

Comments from Justin Richer (Note that the AS - authz server - is likely to be included in the same package as a [[Wallet]]).

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. There are usually W3C working groups that track this issues like privacy and innovation or security. The blink-dev issues are code actually being tested.

*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. [https://caniuse.com/#feat=same-site-cookie-attribute 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 [https://github.com/IdentityServer/IdentityServer4/issues/2595 this site.] For more details see the wiki page [[Cross-Origin iFrame]],
*First-Party Sets and 'SameParty' cookie attribute has two "explainers" as GitHub pages [https://github.com/privacycg/first-party-sets First Party sets] and [https://github.com/cfredric/sameparty 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.
* Declarative Link Capturing for PWAs [https://github.com/WICG/sw-launch/blob/master/declarative_link_capturing.md explainer]. New Web App Manifest member to control what happens when the user navigates to a page within scope of an installed web app. This feature introduces the "capture_links" member, an enumeration allowing the customization of link capturing behaviour, allowing sites to:
** Automatically open a new PWA window when the user clicks a link to their app.
** Have a "single window mode" like mobile apps.
* Web ID
* IsLoggedIn from webkit to protect user privacy - can last for a long time so they want to be sure the user consented to logged in and everything is cleared when they log out. https://bitbucket.org/openid/connect/downloads/GFletcher-Apple_Webkit_IsLoggedIn-20210210.pdf

==References==
* See the wiki on [[Trusted Browser]] for ideas on creating a [[User Agent]] that is responsive user security concerns.

[[Category: Identifier]]
[[Category: User Experience]]
[[Category: Browser]]