Identifier use in Browsers - Revision history

Tom: /* Context */

2025-09-06T19:04:49Z

‎Context

Tom: /* References */

2022-05-27T00:02:06Z

‎References

Tom: /* References */

2022-05-27T00:01:50Z

‎References

Tom: /* References */

2022-05-06T19:41:40Z

‎References

Tom: /* Solutions */

2022-05-06T19:39:01Z

‎Solutions

Tom: /* Solutions */

2022-05-06T19:38:22Z

‎Solutions

Tom: /* Context */

2021-11-26T00:49:01Z

‎Context

Tom: /* Context */

2021-09-03T19:15:53Z

‎Context

Tom: /* Context */

2021-04-18T17:36:25Z

‎Context

Tom: /* Context */

2021-04-18T17:32:17Z

‎Context

@@ Line 5: / Line 5: @@
 * 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.
+* 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].

@@ Line 34: / Line 34: @@
 [[Category: Identifier]]
 [[Category: User Experience]]
-[[Category: Broser]]
+[[Category: Browser]]

@@ Line 34: / Line 34: @@
 [[Category: Identifier]]
 [[Category: User Experience]]
-[[Category: User Agent]]
+[[Category: Broser]]

← Older revision		Revision as of 19:41, 6 May 2022
Line 33:		Line 33:

	[[Category: Identifier]]		[[Category: Identifier]]
		+	[[Category: User Experience]]
	[[Category: User Agent]]		[[Category: User Agent]]

@@ Line 21: / Line 21: @@
 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]],
+*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: