2 of 24

The Privacy Sandbox

The Privacy Sandbox initiative aims to create web technologies that both protect people’s privacy online and give companies and developers the tools to build thriving digital businesses to keep the web open and accessible to everyone.

The Privacy Model [1]�

Identity is partitioned by First Party Site
Third Parties can be allowed access to a first-party identity
A per-first-party identity can only be associated with small amounts of cross-site information

[1] https://github.com/michaelkleber/privacy-model

APIs

SaaS Embeds (CHIPS), Spam/Fraud (Trust Tokens), Ads (attribution reporting, etc), First Party Sets, Fenced Frames, …

�… and ...

Chrome announced the Privacy Sandbox initiative in August 2019 with the goal of building web technologies that advance user privacy, while preserving the vibrant nature of the open web that allows publishers to monetize their content. The initiative aims to phase out support for third-party cookies in Chrome, and also subsequently tackle the threat of fingerprinting.

Chrome has laid out a privacy model for the web, and much of the Privacy Sandbox effort is anchored upon these principles. The key principles that are worth calling out are the following:

First, users’ identity is partitioned by the top-level site/”party”. In other words, the user’s identity when visiting nytimes.com is distinct from the identity of the same user when visiting cnn.com. This ensures that user’s browsing activity across multiple top-level sites/parties cannot be compiled. Note that, user actions like "Pay with PayPal", "Log In with Facebook" or "Use your email address as your account name" can enable joining of user identity across distinct sites/parties. In these situations, browsers should help users understand the implications of allowing that joining, and be supportive of ways to access sites that do not require that cross-site joining.
Second, to preserve the highly composable nature of the modern web, which allows first-parties to delegate services or portions of their website to third-parties; we assert that third-parties may be allowed to the first-party identity, while allowing the first-party to retain control over the user’s identity on their site.
Third, in order to preserve the web platform’s usability and health; it may be necessary for some use-cases to learn small amounts of information from the user’s identity on other sites. For example, anti-fraud solutions may need to learn a user has earned trust on another site — for example, by solving a CAPTCHA, becoming a subscriber, etc. As another example, an advertiser may want to know when a user clicks on an ad on one website, which then converted to a purchase on the destination site. In this case, it may okay to allow this information to be exchanged, as long as there is very little additional information that needs to be passed beyond the fact that a conversion took place.

The Chrome Privacy Sandbox team is building privacy-preserving, purpose-built APIs for many usecases that currently rely on third-party cookies. For example, SaaS embeds that can sufficiently operate with a per-top-level-site session identifier can use partitioned cookies (or CHIPS: Cookies Having Independent Partitioned State), anti-spam/fraud solutions may use Trust Tokens which provide a small number of bits to convey a notion of trust across sites in a way that is unlinkable to the user’s identity. We also have a set of proposed APIs that allow publishers to monetize via advertising, such as the attribution reporting (previously known as conversion measurement) API. First-Party Sets is a mechanism that allows sites to declare a collection of domains to be treated as the same “first-party”, and Fenced Frames allows for embeds usecases that need access to user identity on their site, while disallowing communication or joining of the user’s identity on the embedding site.

3 of 24

Federated Identity

What is it?

Users sign-in to a RP (relying party) with an IDP (Identity provider)

Why do we think it’s important?

�Federated identity is safer* than per-site usernames and passwords

* phishing, password reuse, etc

4 of 24

What’s the problem?

By design, Identity federation was built on top of low-level primitives*.

By accident, the same primitives also enable cross-site tracking.��

* iframes, third party cookies, redirects

your@email.com

******

https://example1.com

John Doe�johndoe@email.com

Sign-in to example.com with IDP

Continue as John

forgot password

your@email.com

******

https://example2.com

John Doe�johndoe@email.com

Sign-in to example.com with IDP

Continue as John

forgot password

Browser

IDP

The classification Problem

5 of 24

https://idp.com

Signing-out of RP1

Signing out of your apps

Signing-out of RP2

Signing-out of RPn

...

logging out

******

https://example1.com

Continue as John

forgot password

your@email.com

Or register with usernames and passwords

personalized buttons

******

https://example1.com

John Doe�johndoe@email.com

Sign-in to example1.com with IDP

Continue as John

forgot password

your@email.com

social widgets

3P cookies use in Federation

Browser

IDP

6 of 24

The Classification Problem

Browser

Tracker

https://rings.com

Engagement Rings!

Buy

US$ 1000

User 123 viewed engagement rings

https://tracker.com

Redirecting you ...

https://shoes.com

Engagement Shoes!

Buy

US$ 32

User 123 viewed engagement shoes

https://tracker.com

Redirecting you ...

7 of 24

The IDP and RP Tracking Problems

Yes

Welcome Bob!��Are you trying to create an account with rp1.example?

https://idp.example

IDP’s log

https://rp1.example

Sam Goto�samuelgoto@gmail.com

John Doe

johndoe@email.com

∑ RP’s log

John Doe has visited rp1.example

https://rp2.example

Sam Goto�samuelgoto@gmail.com

John Doe�johndoe@email.com

global identifiers

...

John Doe has visited rp2.example

...

8 of 24

What’s WebID*?

A high-level, identity-specific, privacy-preserving browser API that enables identity federation to continue thriving on the web.

* Oops. Web Sign-in?�

9 of 24

Useful principles so far

Users first*.

Developers 2nd, browser engines 3rd, technical purity 4th.

* you’d be surprised how often this is used.��

Private by default.

Partitioned by first party site by default, global* by choice [1].

* yes, we expect enterprises and education to pick different defaults.��[1] https://github.com/michaelkleber/privacy-model

�

Minimize redeployment.

O(B) of users*, O(M) of RPs**, O(K) of IDPs***, O(10) browser engines.

* no, we won’t start with the NASCAR�** yes, customer support is hard too�*** consumer IDPs control JS SDKs!�

10 of 24

Classes of solutions

Permission

Browser is only involved to capture user consent for tracking.

Pros

Backwards compatible. Extensibility.�Cons

Permission-blindness* ineffective at driving change.��* on the way of the job to be done��

Mediation

Browser renders parts of the IDP flow in the browser consent moments.

Pros

Deployable by IDPs. Meaningful permission.

Cons

Ossification*.

* basic auth anyone?

Delegation

IDP delegates much of the responsibility for minting tokens to the browser.

Pros

Frictionless, consequence-free.

Cons

RP backwards incompatible *.

* reminder: O(M) of RPs

11 of 24

The Permission-oriented API

The Mediation-oriented API

Pros: most backwards compatible�Cons: permission-blindness

Pros: meaningful permission�Cons: ossification

12 of 24

https://rp2.example

The unbundling of global identification into directed and �The unbundling of issuing and presentation

Welcome John!�

https://idp.example

user-agent://holder

https://rp1.example

Sam Goto�samuelgoto@gmail.com

∑ RP’s log

Not viable anymore

J.D..�abc@email.com

Directed

Global

Issues

John Doe�johndoe@email.com

Not observable anymore

IDP’s log

Sam Goto�samuelgoto@gmail.com

J.D..�def@email.com

Presents

13 of 24

20??

2020

2021

2022

Here are 3 options�I2P

I2E?

I2S?

Oops, we have a problem

Hi there!

today

Prototyping

Devtrial

Hello WICG, OIDF

Origin Trial

The End State

Is this even a problem?

Would these even work?

This could work. How can I try?

This should be even better!

Why > What > How > Who > When

Stable

You

14 of 24

Thanks!

Intro

15 of 24

ANNEX

Intro

16 of 24

The progressive disclosure of identification

******

https://rp.example

your@email.com

Self-issued Directed Identity

J. D.�Forward to johndoe@email.com

Sign-in to rp.example with idp.example

Continue as J. D.

Authorization

https://rp.example

Connect your calendar with us to allow us to manage your schedule!

Connect my calendar!

rp.example is asking for access to your calendar:

Read access to your calendar

Block

Allow

Welcome J.D!

We need to confirm your real email address to unlock certain features.

Share my email address

https://rp.example

Progressively Identification

rp.example is asking for access to your email address:

�johndoe@email.com

Allow

Block

17 of 24

Show me the code

Intro

18 of 24

// Exact API largely TBD. Our best guess so far:

const token = await navigator.credentials.get({

provider: "https://idp.example",

request: {� client_id=”1234”,

nonce: “Ct60bD”,

mode: "permission" || “mediation” || “delegation”,

});

19 of 24

Demos

Intro

20 of 24

The Mediation-oriented API

21 of 24

The Permission-oriented API

22 of 24

WebAuthn?

WebOTP?

Forms?

Intro

23 of 24

User

Identity

Account

Session

Registration

Authentication

Session Authentication

Loss

Expiration

Verification

Usernames

Emails

Phone #s

Passwords, JWTs

Recovery

Profile

Names, Age, Social Graph

Personalization

SMS OTP, Magic Links

WebID + Forms

WebOTP

WebAuthn

2FA

Biometrics

The Identity Lifecycle

Tightly bound and very permanent but less easier to use
Some things are easier to use but not as tightly bound
There is a spectrum of these things, from something like a passport on one end / driver license one end and cookies on the other
Tightly bound:

They are more permanent (vs ephemeral), its validity will change in different time frames
Maybe not on second thought, but here is a thought: another aspect may be the level of confidence that you’d expect from these (some things are harder to impersonate)
Degree of derivation
Degree of confidence of who you are
The degree of recoverability
Anchor into something stable

“Recovery seems to be generating a new derived from a primordial claim” – the point of derived claims is that they are easier to use, to carry and to present, while being more ephemeral.
Harder to use but more guaranteed to have them
E.g. if you lose your session you can easily recreate them
These don’t seem like state transitions … I initially thought that these were relationship between concepts rather than state transitions ….

Jeff:

Peer-entity authentication: when you are authenticating the entity you are
Data-origin authentication
Registration ceremony before
Ambient Credentials: cookies are ephemeral evidence
Unless they are signed, cryptographic demonstration of their origin, who minted them, etc, they are not authentication, they are simply evidence of state
Cookies were initially invented as session state, state maintenance
Strong-authentication has to do with cryptography vs Weak-authentication:
Cookies are replayable, misappropriated and replayed
Usernames and passwords is simply a shared secret, user manipulated shared secret
Identification and authentication
There is no identity involved, it is anonymous
Usernames and passwords are both authentication and (a weak form of) identification (because usernames are typically treated as a form of identification). It gets stronger notions of identity if you enforce uniqueness over the username, and if you enforce some sort of evidence from third parties as to the content of the username, such as some form of identification from a third party.
Primary Key on the account
https://garlic.com/~lynn/secgloss.html
SAML
Authentication:
https://csrc.nist.gov/glossary/term/security_assertion_markup_language#:~:text=Definition(s)%3A,between%20on%2Dline%20business%20partners.
https://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf
http://www.projectliberty.org/liberty/content/download/1958/13778/file/draft-liberty-glossary-v2.0-03.pdf
https://www.researchgate.net/profile/Umesh-Kumar-72/publication/326553062_Authentication_Protocols_and_Techniques_A_Survey/links/5c7cf3b792851c6950523390/Authentication-Protocols-and-Techniques-A-Survey.pdf
https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=survey+of+authentication+methods+email+sms&btnG=
Demonstrating an established relationship
https://www.identityblog.com/?p=1049
https://www.identityblog.com/?cat=70

Reading

1 of 24

2 of 24

3 of 24

4 of 24

5 of 24

6 of 24

7 of 24

8 of 24

9 of 24

10 of 24

11 of 24

12 of 24

13 of 24

14 of 24

15 of 24

16 of 24

17 of 24

18 of 24

19 of 24

20 of 24

21 of 24

22 of 24

23 of 24

24 of 24