Difference between revisions of "Identifier use in Browsers"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Solutions)
Line 8: Line 8:
  
 
*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.]
 
*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.]
*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].
+
*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.
  
 
==References==
 
==References==

Revision as of 09:41, 10 February 2021

Full Title or Meme

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

Context

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