This document discusses upcoming changes to browser policies that will impact identity flows and the web. SameSite cookie policies will be changing, defaulting cookies to SameSite=Lax and requiring SameSite=None cookies to also be Secure. This will impact authentication redirects and hidden iframe flows. The ITP and "browser VPN" changes may also wipe local storage and mask IP addresses. The navigator.isLoggedIn() proposal aims to better define user login state. HTTP state tokens are referenced as an alternative to cookies for managing sessions.

1. BROWSER CHANGES
IMPACTING IDENTITY FLOWS
NISO WORKSHOP

2. INTRODUCTION
SameSite Policy Impacts
ITP Policy Impacts
Browser “VPNs” to mask browser IP addresses
navigator.isLoggedIn() proposal / WebID
Bounce Tracking Prevention
HTTP State Tokens

3. SAMESITE POLICY CHANGES
SameSite=Strict
● Only sent when page loaded in the browser exactly matches
the domain of the cookie
SameSite=Lax
● Cookie is sent from a non-matching domain if and only if
the user explicitly clicks a link that initiated the load of the
off-domain page
SameSite=None; Secure
● The default that we have today except that these cookies will
only be sent over secure connections (HTTPS)

4. WHAT IS AFFECTED BY SAMESITE=STRICT
It’s fair to say that mostly everything, Client requesting an
authentication/authorization response from an AS through the
regular browser redirect flow will get hindered like so
● The RP session cookie (in which regularly nonce and state is stored) will not
be sent with the callback.
● The OP session cookie will not be sent with the redirect and therefore AS will
resolve to authenticating the end-user again. It will set a new session cookie
and the old one will become orphaned.
● When an AS redirects to an upstream IdP (facebook, google, etc) it won’t be
able to consume the callback since then we are the RP and we can’t load our
session cookie with the state/nonce details we need to consume a callback.

5. WHAT IS AFFECTED BY SAMESITE=LAX
Any hidden iframe mechanism
● response_mode=web_message used for silently renewing
tokens, the origin of the request is not the AS hence the AS
session cookie is disqualified from being sent.
● OIDC Session Management and Logout Specifications
○ Session Status Change Notification - the origin of the request is not
the AS hence the individual RP session state cookies are disqualified
from being accessible to the javascript context.
○ Front-Channel RP Logout iframe - the origin of the request is not
the RP website hence the RP session cookies are disqualified from
being sent.

6. WHAT IS AFFECTED BY SAMESITE=LAX
POST based protocol messages
● response_mode=form_post used to return tokens via the front-channel but
directly to the RP backend service. The origin of the request is the AS hence
the RP session cookie (in which regularly nonce and state is stored) will not be
sent with the callback. An RP will fail to consume the callback.
● POST to the authorization_endpoint - the OP session cookie will not be sent
with the POST request and therefore the AS will resort to authenticating the
end-user again. It will set a new session cookie and the old one will become
orphaned.
● POST to the end_session_endpoint - the OP session cookie will not be sent
with the POST request and therefore the AS will not be able to identify the
authenticated session and logout will not be performed.

7. WHAT IS IMPACTED BY SAMESITE=NONE
● Cookies marked as SameSite=none MUST also be flagged as
‘Secure’
● This means that these cookies will only be sent to an HTTPS
endpoint
● This means that if the RP is using SameSite=none cookies,
their callback URI MUST be HTTPS
● Developers now need to run their dev endpoints as secure
(HTTPS) endpoints

8. UPCOMING CHANGES TO SAMESITE POLICY
● Google calls this Incrementally Better Cookies in their
individual draft and it consists of two changes, one being a
prerequisite for the other.
○ Default sameSite cookie attribute changes from “none” to “lax”
○ Cookies with sameSite attribute none also have to be secure
● Intent to ship in Chrome by default has been set to version
80 (due in February 2020), Firefox version 69 behind a
preference toggle.
○ Google has stopped the rollout of this feature due to COVID-19
○ This appears to be enabled by default in the Brave browser
● Testing in chromium based browsers
○ chrome://flags , brave://flags, etc
○ Search for “samesite” and enable all the options

9. WHAT THE CHANGE MEANS
When a set-cookie header does not have a sameSite attribute,
instead of defaulting to none (today’s behaviour) it will be
defaulted to lax.
When a set-cookie header has an unrecognized sameSite
attribute, instead of defaulting to none (today’s behaviour) it will
be defaulted to lax.

10. IMPACT ON AUTHORIZATION SERVERS
● Inventory existing flows to determine impact
○ Depending on the existing supported flows (e.g. top-level full page
redirects) no changes may be necessary
● What to do?
○ In order to ensure all existing flows are still working send
sameSite=none with all cookies that are intended to be accessed
cross-origin.
○ Use two cookies
● Risk:
○ Some, to work around a known WebKit bug which is still in effect
(see below “Existing WebKit bug”).

11. IMPACT ON RELYING PARTIES
● If a client currently sets their cookies to either of the defined
values, it will continue to work after the default sameSite
value changes as well.
● If a client currently uses response type query or fragment, it
will continue to work after the default sameSite value
changes as well
● Native SDKs (using custom scheme or claimed https uris) are
not affected, these use either query or fragment.
● If a client uses response_mode=form_post
○ the cookies used to convey a session or ones that contain the
request parameters like nonce, state, etc need to be set to “none”
○ - or -

12. TEMPORARY WORKAROUND FOR LOGIN
FLOWS
● If a cookie has been set (session or persistent) within the
last 2 minutes without an explicit SameSite value, it will still
be sent with FORM posts
Impacts
● Allows existing flows to *mostly* NOT break when deployed
● Any FORM response based login flow that takes more than 2
minutes will break as the cookies will not be sent

13. SAMESITE=NONE WEBKIT BUG
Older instances of iOS webkit do not correctly handle a cookie
explicitly marked as SameSite=none. Instead it defaults the
cookie to the ‘strict’ policy.
Resolution:
● At this point it doesn’t appear that older version of webkit
will be patched
● Recommended solution is to use two cookies one explicit set
to SameSite=none and one with no SameSite attribute
○ This requires the service receiving the cookies to work through

14. ITP 2.X
Sites flagged as “tracking sites” have their cookies wiped every
30 days unless the user explicitly interacts with the eTLD+1.
This applies to local storage as well. [ITP 2.1]
Persistent Cookies set via JS are wiped after 24 hours. [ITP 2.2]
Cookies won’t be sent at all in 3rd party contexts.
In Safari 13, local storage will be wiped (after 7 days of no
activity to that domain) if coming to a site from a “tracker site”
and request contains query parameters. [ITP 2.3]
https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

15. IMPACT OF ITP 2.3
● Since OIDC/OAuth authorization_code flow redirects with
query parameters, it appears this will set the RP domain to
have it’s localStorage wiped 7 days after the user last
accesses that domain

16. BROWSER BASED “VPNS”
● Concern that request features like IP address might uniquely
identify a user and enable tracking
● Browsers currently collecting metrics regarding this
“tracking” approach
● Planning to support “remote proxying” of requests so that
IPs are multiplexed across random users
https://www.technadu.com/firefox-premium-version-integrated-vpn/70071/
https://private-network.firefox.com/
https://github.com/bslassey/privacy-budget
https://blog.cloudflare.com/announcing-warp-plus/

17. NAVIGATOR.ISLOGGEDIN() PROPOSAL
“For the purposes of client-side storage/state, the behavior of the web platform has been “logged
in by default,” meaning as soon as the browser loads a webpage, that page can store data
virtually forever on the device, and the browser may have to treat the user as logged in to that
website. That is a serious privacy issue. Long term storage should instead be tied to where the
user is truly logged in.”
“If websites were allowed to set the IsLoggedIn status whenever they want, it would not
constitute a trustworthy signal and would most likely be abused for user tracking. We must
therefore make sure that IsLoggedIn can only be set when the browser is convinced that the
user meant to log in or the user is already logged in and wants to stay logged in.”
“If websites were allowed to set the IsLoggedIn status whenever they want, it would not
constitute a trustworthy signal and would most likely be abused for user tracking. We must
therefore make sure that IsLoggedIn can only be set when the browser is convinced that the
user meant to log in or the user is already logged in and wants to stay logged in.”
https://lists.w3.org/Archives/Public/public-

18. NAVIGATOR.ISLOGGEDIN() PROPOSAL
There are several ways the browser could make sure the IsLoggedIn status is trustworthy:
● Require websites to use of WebAuthn or a password manager (including Credential
Management) before calling the API.
● Require websites to take the user through a login flow according to rules that the browser
can check. This would be the escape hatch for websites who can’t or don’t want to use
WebAuthn or a password manager but still want to set the IsLoggedIn bit.
● Show browser UI acquiring user intent when IsLoggedIn is set. Example: A prompt.
● Continuously show browser UI indicating an active logged in session on the particular
website. Example: Some kind of indicator in the URL bar.
● Delayed browser UI acquiring user intent to stay logged in, shown some time after the
IsLoggedIn status was set. Example: Seven days after IsLoggedIn was set – “Do you want to
stay logged in to news.example?”
● Requiring engagement to maintain logged in status. Example: Require user interaction as
first party website at least every N days to stay logged in. The browser can hide instead of
delete the credential token past this kind of expiry to allow for quick resurrection of the
logged in session.

19. NAVIGATOR.ISLOGGEDIN() PROPOSAL
Some websites allow the user to use an existing account with a
federated login provider to bootstrap a new local user account
and subsequently log in. The IsLoggedIn API needs to support
such logins.
● First, the federated login provider needs to call the API on its
side, possibly after the user has clicked a “Log in with X”
button:
● For the promise to resolve, the user needs to already have
the IsLoggedIn status set for the federated login provider,
i.e. the user needs to be logged in to the provider first.

20. WEBID (PROPOSED)
● JS API focused on identity federation flows
● Allow the browser to intermediate the identity flows
● Browser provided chrome specifically for identity flows
● Works with (or minimal changes to) existing standards
(OIDC, SAML)
● Still in the early days of being fleshed out

21. BOUNCE TRACKING PREVENTION
Apple proposed solution to user tracking that happens via
redirects
If a site is flagged for participating in “bounce tracking” it will
have all cookies set to samesite=strict.
Available for testing starting in Safari Technology Preview 105

22. HTTP STATE TOKENS
https://mikewest.github.io/http-state-tokens/draft-west-http-
state-tokens.html
While not new, this is referenced in the “navigator.isLoggedIn()”
proposal as the “better” way to manage state and logged in
sessions.
Also wanted to discuss whether it’s possible to use state tokens
to “sender constrain” cookies (ala token-binding) but with a
different mechanism

23. ACKNOWLEDGEMENTS
Filip Skokan
Mika Mannermaa
Ajinkya Kshirsagar
Samuel Goto

24. GENERAL DISCUSSION