# BISON: Blind Identification through Stateless scOpe-specific derivatioN

Jakob Heher
Graz University of Technology and Secure Information Technology Center Austria
(A-SIT) Lena Heimberger
Graz University of Technology  Stefan More
Graz University of Technology ††footnotemark:

###### Abstract

Delegating authentication to identity providers like Google or Facebook, while
convenient, compromises user privacy. Global identifiers enable internet-wide
tracking; furthermore, identity providers can also record users’ associations.

We show that neither is a necessary evil by presenting the BISON pseudonym
derivation protocol, inspired by Oblivious Pseudorandom Functions. It hides
the service provider’s identity from the identity provider, yet produces a
trusted, scoped, immutable pseudonym. Colluding service providers cannot link
BISON pseudonyms. This prevents user tracking. BISON does not require long-
lived state on the user device, and does not add additional actors to the
authentication process.

BISON uses lightweight cryptography. Pseudonym derivation requires a total of
four elliptic curve scalar-point multiplications and four hash function
evaluations, totaling to $\approx$3 ms in our proof of concept implementation.
BISON is designed to integrate into existing authentication protocols. We
provide an OpenID Connect extension that allows OIDC’s PPID pseudonyms to be
derived using BISON. This demonstrates that BISON’s privacy guarantees can be
realized in practice.

For these reasons, BISON is a crucial stepping stone towards realizing the
privacy-preserving internet of tomorrow.

##  1 Introduction

In today’s internet, nary a day passes without being prompted to create an
account for a newsletter, a website, or simply to keep reading an interesting
article. Users tend to value comfort and usability, and just want to get back
to what they were doing. They will often take the more convenient route and
just “Sign in with Google”, “Log in with Facebook”, “Use your Microsoft
Account”, or “Sign in with Apple” [27, 54]. The promise is as simple as it is
tempting: forget remembering all these different passwords – access the entire
internet, with just one set of credentials to worry about.

Of course, the flip side isn’t talked up as much: whichever service you use to
serve as “your identity” gets involved every time you log in – anywhere.
Troves of highly personalized association data are at one’s fingertips. This
includes valuable information about users’ behavior, attractive for profiling
and marketing purposes, and worse. In the internet of authentication, it’s of
little surprise that everyone wants to be the identity provider.

But – do we need this? Is it really necessary for identity providers to learn
where their accounts are being used, and which services their users frequent?
In this work, we answer this question to the negative. It does not have to be
this way.

###  1.1 Challenges

Later in this work, in Section 2.2, we will identify a number of goals. These
goals map loosely to two fundamental challenges in delegated authentication,
which our work addresses. To help orient the reader, we will now provide a
brief overview.

##### Challenge 1: Portability

Users are fickle, unpredictable beings [3]. They don’t just use their accounts
on a single, stable device, or even on some predictable set of user devices.
Sometimes they’ll log in from their friends’ house, or from a hotel lobby, or
from a shared computer at the school library.

In all of these cases, they still expect their accounts to be there, just one
short authentication process away [50, 26]. This reality is in sharp contrast
with some academic work [11, 39, 56, 41, 34], which envisions secret key
material being stored “on the user’s device”. Without access to this material,
authentication is intentionally made a cryptographic impossibility.

In this work, we will instead aim for a reality-proof solution, by embracing
_statelessness_ of the user device.

##### Challenge 2: Privacy

_Who you’re talking to_ is highly sensitive information. Maybe you’re getting
confidential medical advice from a specialist, seeking help with interpersonal
conflict, or contacting a self-help group for an illness. Either way, nobody
except _you_ and _them_ should know about it; the two of you should enjoy
_relationship anonymity_ [40, 8, 2].

At the same time, _who you are_ is also highly sensitive information. Let’s
say you log in to an internet forum, and you log in to a shopping platform.
The shopping platform might be interested in the messages you post on the
forum, so they can know which products to advertise to you [35]. Maybe you
even want this, and might consent to it. But these parties should not be able
to correlate your information automatically; you should enjoy _pseudonym
unlinkability_ [43, 49, 40, 7].

In this work, we will aim to safeguard _both_ of these privacy properties. As
we will outline in more detail in Section 2.2, this is an especially tricky
challenge; many naïve solutions to one problem simultaneously preclude solving
the other.

###  1.2 Contributions

We introduce BISON, a stateless pseudonym derivation protocol that prevents
profiling by identity providers and tracking by service providers. It produces
pseudonyms that are scoped, immutable, and stable across multiple
authentications.

BISON takes inspiration from Oblivious Pseudo-Random Functions (OPRFs), a
well-researched cryptographic primitive, and applies it to a novel context. As
a result, it is straightforward to understand and implement. Additionally,
BISON is lightweight, only requiring four hash function evaluations and four
elliptic curve point-scalar multiplications per derivation. It does not
introduce any additional actors into the established authentication flow, and
does not require any long-lived state to be stored on the user device. We
provide a security proof, showing that BISON meets the claimed properties.

We then go on to show that the existing OpenID Connect protocol, widely used
in federated authentication, can be easily augmented to use BISON for
pseudonym derivation. This allows user agents to take an active role in
safeguarding user privacy in federated authentication. At a time when browser
vendors are deliberating the adoption of novel solutions to federated
authentication across isolated browsing contexts, this further demonstrates
that BISON can be practically deployed in real-world scenarios. We provide a
full demonstrator implementing our extension, and make its source code
available.

###  1.3 Outline

The remainder of this work is composed of two main parts. First, in Section 2,
we describe the abstract BISON protocol; we introduce our goals (Sections 2.1,
2.2 and 2.3) and necessary background (Section 2.4), then present our
derivation protocol (Section 2.5). We prove its security (Section 2.6) and
discuss further considerations (Section 2.7). Next, in Section 3, we integrate
BISON derivation into OpenID Connect; we introduce OpenID Connect (Section
3.1), specify our extension (Section 3.2) and how it meets security
requirements (Section 3.2.1). We describe our implementation (Section 3.3),
show that it has negligible overhead (Section 3.4), and discuss the
implications (Section 3.5). Finally, we compare to existing solutions (Section
4) and conclude (Section 5).

Figure 1: The basic authentication flow. Using BISON derivation does not alter
this flow; it does not add actors or messages.

##  2 The BISON Protocol

In this first part of our work, we introduce the BISON protocol for pseudonym
derivation. It provides _pseudonym unlinkability_ against colluding service
providers in different scopes, _User-SP relationship anonymity_ against an
honest-but-curious identity provider, and _Sybil resistance_ against a
malicious user while requiring _no persistent state_ on the user device.

###  2.1 Definitions

We start by defining the three protocol actors and the roles they fulfill, and
making some clarifications regarding terminology and notation. Note that we do
not require actors beyond those common in existing authentication protocols
[45, 14].

##### User/User Device

The _user_ is a party with the primary objective of proving their identity to
some service securely and efficiently, ideally in a privacy-preserving manner.

When necessary, we will distinguish between the human “user”, and the “user
device” they are operating, which will, e.g., perform cryptographic operations
on their behalf.

##### Service Provider (SP)

The _service provider_ is a party that requires the user to authenticate, as
part of an authorization decision to access some service or resource. There
are many different service providers, which may offer wildly disparate
services. An internet message board, a virtual storefront, a health provider’s
appointments software, a bank’s online banking application, and a government
bureau’s web portal, are very different kinds of service providers, with
different needs.

Almost all service providers share a need to (re-)identify users. If a user
visits a message board, they should have the ability to edit messages they
have previously sent; if they visit a storefront, they should be able to see
their pending orders; if they visit their health provider, they should be able
to see and cancel their appointments; and so forth. It is thus necessary to
perform an authentication process of some kind, which results in a trusted
persistent identifier for the user.

Authenticating a user is not a trivial task. Depending on the method, a server
may often need to securely store persistent information about the user. Users
may also need to remember many different credentials for different service
providers.

These concerns have given rise to a desire to delegate the actual
authentication process to a dedicated third party.

##### Identity Provider (IdP)

The _identity provider_ is a party that is trusted to perform user
authentication. It decides on the authentication factors to use, and stores
any information necessary to (re-)authenticate the user using these factors,
such as password digests, shared secrets, or public keys.

The identity provider then assigns each _user account_ a “global” identifier,
which is only unique within the context of this particular IdP. Some identity
providers may use truly global identifiers, such as email addresses; but not
all do.

Depending on the context, possession of an account at a certain identity
provider may carry particular implications, such as membership in a certain
organization, which is verified by the identity provider. In such a case, the
service provider delegates not only authentication, but implicitly also
delegates verification of these properties to the identity provider.

##### Scope

A _scope_ is the domain within which a user holds a particular stable, unique,
and non-reassignable pseudonym.

What constitutes a scope is highly context-specific. At a naïve level, each
service provider might form its own scope. However, related service providers,
which should be permitted to share data, might be grouped to form a single
scope. By contrast, a single service provider might also be required to use
different scopes, for example, to prevent data aggregation across different
divisions of a large corporate entity.

A particular scope is identified by a byte string, called a _scope identifier_
, or $\mathit{scopeId}$ for short. In BISON, we assume that the user device
can use some context-specific method to determine whether a service provider
is authorized for a particular $\mathit{scopeId}$. For example, this decision
might be based on a certificate issued by the identity provider, or it might
be based on already-available trusted information. We discuss this requirement
further in Section 2.6.1.

##### Alternate terminology

We have chosen these terms for use throughout this work in an attempt to avoid
ambiguity. However, identity management is a broad field, and different sub-
fields have adopted different terminologies for related concepts. To ease the
reader’s understanding, we briefly mention such alternative terms that may
appear in related work.

The _user device_ may also be referred to as a _client_ , a _user agent_ , or
a _wallet_. The _user_ may be called _resource owner_.

The _service provider_ is often also called a _relying party_. In OpenID
Connect-related contexts, the service provider may – somewhat confusingly –
also be referred to as a _client_ [45].

The _identity provider_ is, based on context, referred to as _(authorization)
server_ , _(credential) issuer_ , or _(claims) provider_.

##### A Note on Notation

To avoid confusion, we briefly outline the mathematical notation used
throughout the remainder of this work. $(\mathbb{G},+)$ is a group of prime
order $p=\mathsf{ord}(\mathbb{G})$. The group operation is written additively.
The repeated application of the group operation, written as $s\cdot X$ for
$s\in\mathbb{Z}_{p},X\in\mathbb{G}$, corresponds to $X+X+X+X+\ldots$ repeated
$s$ times. We will use uppercase (such as $X$ or $\mathsf{ScopeId}$) to denote
elements of $\mathbb{G}$, and lowercase (such as $r$ or $\mathsf{userId}$) for
elements of $\mathbb{Z}_{p}$.

###  2.2 Goals

We now explicitly state our goals for the protocol. In doing so, we will use
the terminology of Pfitzmann and Hansen [40].

##### Pseudonym Unlinkability

Delegating authentication to a central provider is convenient, but enabling a
link between otherwise-disparate user accounts is a significant privacy risk.

At a basic level, consider a “normal” centralized authentication process, as
shown in Figure 1. The service provider redirects the user to the identity
provider, and the user authenticates there. The service provider is then
provided with some assurance, signed by the identity provider, that the user
was authenticated. This includes the user’s identifier, which is commonly a
(unique) account name, email address, or similar. The same user identifier is
then provided to each service provider that the user authenticates to. This
allows different service providers, or other entities that they share data
with, to link together the user’s actions without their consent.

Commonly, there is no legitimate need for such cross-provider tracking. Thus,
_in general_ , there is no reason for every service provider to obtain this
same global identifier. Some authentication delegation schemes recognize this,
and support service provider-specific pseudonyms [45, 14]. Here, the identity
provider generates a persistent pseudonymous identifier for each service
provider. A given user’s identifiers at different service providers are
unrelated to one another, and cannot be linked. Thus, they cannot be used for
tracking.

We formalize this concept of _pseudonym unlinkability_ as follows. Two service
providers, A and B, each perform an authentication process, and as a result,
obtain one pseudonym each. It should be impossible for them to decide whether
the two pseudonyms refer to the same user, or to different users.

##### User-SP Relationship Anonymity

The use of a central identity provider also means that this identity provider
will commonly learn the identity of any service provider(s) that the user
authenticates to. This is, once again, a significant privacy risk, with
identity providers gathering a significant amount of data regarding the users’
associations.

An identity provider necessarily needs to identify the particular user that is
authenticating. Furthermore, it is generally legitimate for the identity
provider to control which service providers can use its authentication
service. However, it is _not_ generally necessary for the identity provider to
learn _which particular user_ is authenticating to _which particular service
provider_ (observability). The link between a particular service provider and
a particular user is the sensitive information at risk.

This, too, is a privacy risk that is well-known, both in literature and
practice; ways to authenticate at an unknown service provider already exist
[15, 52, 24]. Yet, combining this property with the previous _pseudonym
unlinkability_ goal offers a unique challenge. After all, if the identity
provider does not know the service provider’s identity, how can it derive a
service provider-specific pseudonym for the user?

##### Sybil Resistance

It is generally desirable for many internet services to place some barrier on
the creation of fresh user accounts. Failing to do so may lead to the
proliferation of spam, subversion of reputation or accountability systems, and
other related issues. This is commonly referred to as a _Sybil attack_ , and
systems preventing this are termed _Sybil-resistant_ [21].

Services that try to obtain Sybil-resistance commonly require some in-person
contact or a verifiable link to a real-world identifier that is not easy to
obtain. Examples include phone number verification, scans of identification
documents, or in-person account registration. By their very nature, these
interactions are highly invasive to a user’s privacy.

Some approaches to privacy-preserving authentication attempt to prevent user
tracking by both the service provider and the identity provider. They do this
by relying on the user to associate pseudonyms to particular service
providers. In such a scheme, the identity provider simply allows the user to
authenticate using one of any number of pseudonyms; the user device can then
re-use the same pseudonym when re-authenticating to the same service provider
[18].

This completely voids any Sybil-resistance efforts by the identity provider.
Since a single user can present multiple unlinkable identifiers to the same
service provider, a single verified user at the identity provider can spawn an
arbitrary number of “identities” at the service provider. As a result, the
service provider would need to begin its own Sybil-resistance efforts. This
both defeats the point of delegated authentication and, by necessitating an
invasive verification process, undermines any privacy gains towards the
service provider.

To avoid this issue, the user _must_ have a single consistent pseudonym in the
context of a particular scope, or at least some means by which to correlate
different pseudonyms of the same user. We consider these two propositions to
be functionally equivalent from a privacy perspective.

##### No persistent user device state

While storing secret information on the user’s device can be very convenient
for protocol design, it presents many practical challenges.

Devices may break or be misplaced, leading to the irrevocable loss of any
cryptographic information stored. Backing up such information while keeping it
truly private is an open challenge, to which no perfect solution appears to
exist [57].

Users may also wish to log in on a shared computer, or on a friend’s device.
The process of transferring cryptographic key material to such a device is
often complex, and exposing key material to a potentially-untrusted device is
undesirable.

We side-step all of these issues by requiring no persistent state on the user
device. All state kept on the user device should be ephemeral to a single
authentication process, and should be able to be discarded after the process
completes. This matches existing protocols deployed in the real world, and
avoids complications when integrating our scheme.

##### Soundness

Finally, we explicitly state an implicit goal shared with any other delegated
authentication scheme. If a user successfully completes an authentication
process, this should guarantee that they have successfully authenticated to
the identity provider as the user corresponding to the resulting pseudonym. In
other words, a malicious user should not be able to – without the identity
provider’s cooperation – impersonate benign users towards a service provider.

###  2.3 Threat Model

We assume the _user_ to be fully malicious. A malicious user has two possible
goals. First, obtaining a different pseudonym for the same user-scope
combination. This can either be the pseudonym of a particular genuine user
(targeted), or just a blank-slate Sybil identity (untargeted). Second,
completing the authentication without querying the identity provider, while
resulting in the user’s genuine pseudonym. This would then allow a user to
complete authentication using, for instance, a suspended user account.

We assume the _service provider_ to be fully malicious. Malicious service
providers have three possible goals. First, obtaining the user’s global
identifier, which may be identifying information such as an email address.
Second, correlating the pseudonyms of users across different
$\mathit{scopeId}$s. Third, impersonating a user towards another service
provider.

Since the _identity provider_ is tasked with performing opaque, context-
specific steps to authenticate the user, they are the ultimate authority for
who a user is. Them being able to issue false attestations, or create make-
believe identities, is baked into the fundamental assumptions of the system.
As a result, a fully malicious identity provider could trivially violate a
number of the goals of an authentication scheme.

We will therefore assume that the identity provider is _honest-but-curious_.
This is a common assumption, for the reasons stated above. We assume that they
follow the steps required of them faithfully; but they will still extract as
much information as possible from the data obtained in the process. For
instance, they will attempt to trace a user’s associations, and build an
advertising profile of them, without their consent.

We will generally assume that entities do not act contrary to their own
interests within the scope of this particular authentication process. The user
has an interest in pseudonym unlinkability, and relationship anonymity. The
service provider has an interest in Sybil resistance and soundness. The
identity provider, constrained by our honest-but-curious assumption, will not
usually act contrary to pseudonym unlinkability, Sybil resistance and
soundness. We discuss the implications of the identity provider breaking
pseudonymization, and the circumstances in which this becomes possible,
further in Section 2.7.

###  2.4 Background:
Oblivious Pseudorandom Functions

In privacy-preserving computation, two parties may wish to compute a function
where both parties input some data, but do not learn the other party’s input.
This idealized functionality is realized by _Oblivious Pseudo-Random
Functions_ (OPRFs). An OPRF is a two-party protocol between a “client” and a
“server” [13]. The server contributes some secret key $k$, and the client
contributes a value $X$. After performing the protocol, the client learns
$\mathsf{OPRF}_{\\_}k(X)$, but learns nothing else about
$\mathsf{OPRF}_{\\_}k$ or $k$. Meanwhile, the server learns no additional
information; in particular, it does not learn $X$ or
$\mathsf{OPRF}_{\\_}k(X)$.

This very simple primitive is useful in a variety of applications; as a
result, there are ongoing standardization efforts by the IRTF’s Crypto Forum
Research Group [16].

In this work, we borrow operations from the specific class of Hashed Diffie-
Hellman OPRFs over prime-order groups. This is a widely-researched class of
OPRFs [13], which can be conceptualized as a sequence of three operations:  1.
$\mathsf{Blind}(X,r):=r\cdot X$, a user function which uses a randomly-sampled
$r\in\mathbb{Z}_{p}$ to blind the input value222If $X$ is not already a group
element of the prime-order group $\mathbb{G}$, it is transformed into one by
applying a suitable hash function. $X$ for transmission to the server.  2.
$\mathsf{Eval}(A,k):=k\cdot A$, a server function that evaluates the blinded
input value to a blinded output value using the server’s secret333Similarly,
if $k$ is not already of the appropriate form, it is first transformed to an
element of $\mathbb{Z}_{p}$ by applying a hash function. $k$.  3.
$\mathsf{Unblind}(B,r):=r^{(-1)}\cdot B$, a user function that removes the
blinding from the output value to produce444The result is then commonly hashed
again. This, conveniently, also destroys any algebraic structure in the
output. the final output.  The output
$\mathsf{OPRF}_{\\_}k(X)=\mathsf{Unblind}(\mathsf{Eval}(\mathsf{Blind}(X,r),k),r)$
is then $r^{(-1)}\cdot k\cdot r\cdot X=k\cdot X$.

We believe that it would be possible to generalize our approach to other types
of OPRFs. However, our security proof of pseudonym unlinkability in Section
2.6 relies on properties of this particular OPRF construction. Thus, we leave
this as potential future work and do not pursue it further here.

###  2.5 BISON Pseudonym Derivation

[center,boxed] Service Provider User Device Identity Provider
scopeId *<->top=User Authentication, topstyle=draw, solid,
yshift=0.25cm,style=dashed userId∈Z_p
[]
top=$\mathit{scopeId}$ r←Z_p
A=Blind(ScopeId,r) top=$A$ B=Eval(A, userId)
A=?Blind(ScopeId, r’) top=$r^{\prime},\mathsf{Sign}_{\\_}\mathsf{IdP}((A,B))$
r’ = r top=$\mathsf{Sign}_{\\_}\mathsf{IdP}((A,B))$ SignIdP((A, B))
VerifyIdP(SignIdP((A,B)))
Unblind(B, r’) ✓

Figure 2: A visual representation of the BISON protocol.

BISON applies OPRFs, introduced in the preceding section, to the three-party
problem of pseudonym derivation. The $\mathit{scopeId}$, selected by the
service provider and authenticated by the user device, is hashed to
$\mathsf{ScopeId}\in\mathbb{G}$, and serves as the client input $X$. The
$\mathsf{userId}$, only known to the identity provider, serves as the server
input $k$. We also add signatures to convince the service provider that the
user truthfully performed the OPRF. This allows the SP to trust the OPRF’s
output, which then serves as the user’s BISON pseudonym.

The resulting BISON protocol is shown in full as Protocol 1. We also provide a
simplified visual representation as Section 2.5.

List of protocols 1 The BISON protocol as a sequence of steps.

Service Provider

  1. 1.

send desired $\mathit{scopeId}$ to user

User Device

  1. 2.

receive $\mathit{scopeId}$ from SP

  2. 3.

authenticate SP for $\mathit{scopeId}$ $\triangleright$ see Section 2.6.1

  3. 4.

derive $\mathsf{ScopeId}$ from $\mathit{scopeId}$

  4. 5.

sample $r\leftarrow\mathbb{Z}_{p}$

  5. 6.

$A=\mathsf{Blind}(\mathsf{ScopeId},r)$

  6. 7.

send $A$ to IdP

Identity Provider

  1. 8.

receive $A$ from user

  2. 9.

authenticate user and obtain $\mathsf{userId}\in\mathbb{Z}_{p}$

  3. 10.

$B=\mathsf{Eval}(A,\mathsf{userId})$

  4. 11.

$sig=\mathsf{sign}_{\\_}\mathsf{IdP}(A,B)$

  5. 12.

send $sig$ to user

User Device

  1. 13.

receive $sig$ from IdP

  2. 14.

send $(r^{\prime}=r,sig)$ to SP

Service Provider

  1. 15.

receive $(r^{\prime},sig)$ from user $\triangleright$ $r^{\prime}$ is not
trusted

  2. 16.

$\mathsf{verify}_{\\_}\mathsf{IdP}(sig)$ $\triangleright$ see Section 2.6.1

  3. 17.

$(A,B)=\mathsf{unpack}(sig)$

  4. 18.

check $A=\mathsf{Blind}(\mathsf{ScopeId},r^{\prime})$ $\triangleright$ this
implies $r=r^{\prime}$

  5. 19.

derive pseudonym as $\mathsf{Unblind}(B,r^{\prime})$

###  2.6 Analysis

We now provide a security proof, and thus demonstrate that the BISON protocol
fulfills the requirements in Section 2.2.

We note that we intentionally do not include protections against message
replay in the core protocol described above. This allows for easier
integration into existing authentication protocols. Such protocols must
already mitigate message replay; work which we would duplicate. If desired,
the core BISON protocol can be easily augmented to include such protection. We
discuss this possibility further in Section 2.6.1.

We also do not mandate a particular method of authenticating service providers
for a given $\mathit{scopeId}$. This is because different methods will be
appropriate depending on the context in which BISON is used. We also discuss
this requirement, and some possible solutions, further in Section 2.6.1.

Finally, we do not specify how the identity provider authenticates the user.
This is common for authentication protocols.

##### Pseudonym Unlinkability

Two service providers in different scopes each perform an authentication
process, and obtain pseudonyms
$\mathsf{userId}_{\\_}1\cdot\mathsf{ScopeId}_{\\_}A$ and
$\mathsf{userId}_{\\_}2\cdot\mathsf{ScopeId}_{\\_}B$ respectively. Since the
user has performed context-specific steps555see Section 2.6.1 to authenticate
each SP for their $\mathsf{ScopeId}$, we know that
$\mathsf{ScopeId}_{\\_}A\neq\mathsf{ScopeId}_{\\_}B$. We show that the two
service providers cannot decide whether
$\mathsf{userId}_{\\_}1=\mathsf{userId}_{\\_}2$.

We first observe that obtaining $\mathsf{userId}_{\\_}1$ (or
$\mathsf{userId}_{\\_}2$) directly from the pseudonym would require solving
the Discrete Logarithm Problem; this is generally assumed to be hard [38].

We then reformulate our problem more generally as follows: given the tuple
$(X,Y,v\cdot X,Z)$ with $X\neq Y$, decide whether $Z=v\cdot Y$. Here, $X$ and
$Y$ correspond to the two (known) $\mathsf{ScopeId}$s, and $V$ corresponds to
the unknown $\mathsf{userId}_{\\_}1$ in the first pseudonym. $Z$ is the second
pseudonym. Deciding $Z=v\cdot Y$ corresponds to deciding
$\mathsf{userId}_{\\_}2\cdot\mathsf{ScopeId}_{\\_}B=\mathsf{userId}_{\\_}1\cdot\mathsf{ScopeId}_{\\_}B$,
which is equivalent to $\mathsf{userId}_{\\_}1=\mathsf{userId}_{\\_}2$.

We now show that an adversary able to decide this problem in general666See
Section 2.7 for considerations in choosing user IDs. could also decide the
Decisional Diffie-Hellman Problem (DDHP) [9]. Given an instance of DDHP, which
is a tuple $(a\cdot G,b\cdot G,c\cdot G)$ for known generator $G$, they are
asked to decide whether $c\cdot G=(a\cdot b)\cdot G$. We map this to an
instance of our problem as follows: $X=G,Y=a\cdot G,v=b,Z=c\cdot G$. If an
adversary can decide our problem, they can therefore also decide whether
$c\cdot G=b\cdot(a\cdot G)=(a\cdot b)\cdot G$. Thus, they could decide the
DDHP; this is generally assumed to be hard [9].

##### User-SP Relationship Anonymity

The authentication process results in the identity provider learning
$r\cdot\mathsf{ScopeId}$ and $\mathsf{userId}\cdot r\cdot\mathsf{ScopeId}$.
The identity provider knows $\mathsf{userId}$, and we also assume it has a
small list of potential $\mathsf{ScopeId}$s to test.

Even so, the IdP cannot decide which $\mathsf{ScopeId}$ is used in the
derivation. The value $r$ is chosen uniformly at random, and
$\mathsf{ScopeId}$ is a non-identity element of the prime-order group
$\mathbb{G}$. Therefore, $\mathsf{ScopeId}$ is a generator of $\mathbb{G}$. As
a result, $r\cdot\mathsf{ScopeId}$ is a uniformly random element of
$\mathbb{G}$. Since $r$ is not known, $r\cdot\mathsf{ScopeId}$ thus conveys no
information about the underlying $\mathsf{ScopeId}$.

##### Sybil Resistance

The authentication process results in the identity provider learning
$(r^{\prime})^{-1}\cdot\mathsf{userId}\cdot r\cdot\mathsf{ScopeId}$ as a
pseudonym. In the process, they verify that $r\cdot\mathsf{ScopeId}$, which is
signed by the identity provider and therefore trustworthy, equals
$r^{\prime}\cdot\mathsf{ScopeId}$, for an untrusted $r^{\prime}$ claimed by
the user.

Since $\mathsf{ScopeId}$ is a non-identity element of the prime-order group
$\mathbb{G}$, it is also a generator of $\mathbb{G}$. Therefore,
$f_{\\_}\mathsf{ScopeId}:s\mapsto s\cdot\mathsf{ScopeId}$ is a bijection, and
thus $r\cdot\mathsf{ScopeId}=r^{\prime}\cdot\mathsf{ScopeId}$ is equivalent to
$r=r^{\prime}$. As a result, $(r^{\prime})^{-1}=(r)^{-1}$, and thus we can be
sure that the learned pseudonym is actually
$\mathsf{userId}\cdot\mathsf{ScopeId}$. This value is constant across
authentication processes for this fixed $\mathsf{ScopeId}$, as we assume that
the identity provider honestly chooses the correct $\mathsf{userId}$ per
Section 2.3.

##### No persistent user device state

Our protocol does not require any state on the user’s device. We consider this
to be self-evident from the description in Section 2.5.

##### Soundness

During the authentication process, the service provider obtains the tuple
$(A,B)$, signed by the identity provider. We assume777see Section 2.6.1 that
the service provider can validate that this was indeed signed by the genuine
identity provider, and thus a malicious user cannot forge such a signed tuple.

As previously described, the service provider can also somehow††footnotemark:
validate that the response presented is fresh, and intended to be part of the
ongoing authentication process. Therefore, even a malicious user can only
obtain a valid tuple in real time from the genuine identity provider. Per
Section 2.3, we assume that the genuine identity provider only issues such
tuples after successful user authentication for $\mathsf{userId}$.

As shown previously in this section, the service provider’s validation of
$A=r^{\prime}\cdot\mathsf{ScopeId}$ ensures that the result of the derivation
is indeed the user’s BISON pseudonym, $\mathsf{userId}\cdot\mathsf{ScopeId}$.
Therefore, a malicious user cannot produce an authentication response for any
$\mathsf{userId}$ except their own.

####  2.6.1 External Considerations

For BISON to meet our stated goals, we rely on the “host” protocol, which
embeds BISON derivation, to provide certain guarantees. These are guarantees
that are either context-specific, or already a necessary part of existing
authentication protocols. Thus, we choose not to mandate a particular way of
achieving them. Instead, we merely list these requirements here, and expect
the host protocol to ensure they are met.

##### Replay

It may be possible for a malicious user to have knowledge of signed $(A,B)$
tuples from a previous authentication process; for example, they may have
previously compromised a legitimate user’s account, their previously-
registered account may have been suspended by the identity provider, or they
may have compromised a user’s device. The host protocol needs to ensure that
the malicious user cannot _replay_ such a previously-issued tuple to the
service provider, instead of having a fresh one issued by the identity
provider. This attack would allow them to complete the authentication process
without needing to authenticate to the identity provider.

The BISON protocol, in the form described in Section 2.5 above, does not
safeguard against this possibility; a malicious user with knowledge of a
signed $(A,B)$ tuple (and associated $r$) for a given $\mathsf{ScopeId}$ could
repeatedly use it to authenticate. This is an intentional design decision.
Replay attacks are not unique to BISON, but are a challenge that any
authentication protocol needs to solve. Therefore, any host protocol embedding
BISON derivation will already have some means of guaranteeing response
freshness. This is commonly done by including a one-time redemption step [45]
or including a challenge nonce that must be signed by the IdP [44]. Adding
such a step to the core BISON protocol would thus be redundant.

However, if replay protection as part of the BISON derivation is desired, it
can easily be added as follows: have the service provider sample blinding
randomness $r$, and provide it to the user device. The user device then does
not sample its own randomness, but is instead required to use the randomness
provided by the service provider. This randomness, and therefore the blinded
scope identifier $A$, will be different and unpredictable for each
authentication process. Since $A$ is part of the identity provider’s signed
response, this forces the signed response to be freshly generated as part of
this particular authentication process, and prevents message replay.

##### IdP Authentication

The BISON protocol has the identity provider sign an $(A,B)$ tuple, which is
forwarded by the user to the service provider. The service provider then needs
to somehow be able to validate the signature over this tuple.

How the necessary key material is obtained, and how its authenticity is
assured, is context-specific. This is a challenge that is not unique to BISON.
Instead, it is the same challenge that any other delegated authentication
protocol needs to solve. Thus, we again argue that any host protocol embedding
BISON derivation will already have the necessary mechanisms in place, and do
not discuss the subject further.

##### SP Authentication

The BISON protocol makes the user device responsible for verifying that the
service provider is authorized for the requested $\mathit{scopeId}$. Failure
to do so would allow a monster-in-the-middle (MitM) attack; a malicious entity
could forward the genuine service provider’s request to the user, and forward
the user’s response to the service provider. The service provider would then
believe that the malicious entity has successfully authenticated as that user.

Additionally, we also note that if multiple service providers are permitted to
share a $\mathit{scopeId}$, they are able to link the requests of their user.
Further, there is potential for them to perform a MitM attack on connections
to each other. In contexts where such SPs do not always implicitly trust each
other, the authentication process should also be bound to a particular service
provider instance, such as by including a randomized commitment in the data
signed by the IdP.888This is the approach we use in our demonstrator in
Section 3.3.

How a service provider is authenticated is context-specific. Therefore, the
BISON protocol does not mandate any particular method of $\mathit{scopeId}$
authentication. This may be derived from an existing trust scheme, such as a
DNS hostname listed in a Web PKI X.509 certificate,††footnotemark:  or a new
context-specific trust scheme, such as certificates issued by a central
authority.

Finally, we caution that authentication must be tied to information
authenticated by an encapsulating transport protocol, such as TLS. If
appropriate care is not taken here, the MitM attack originally outlined may
still be possible.

###  2.7 Discussion

Two points, which we have previously alluded to, remain unaddressed. In this
section, we will argue why pseudonym unmasking by the IdP is a desirable
property. We also highlight the risks of predictably-chosen $\mathsf{userId}$
values.

##### Pseudonym unmasking by the Identity Provider

The BISON pseudonym obtained by service providers is
$\mathsf{userId}\cdot\mathsf{ScopeId}$. The identity provider never learns
this pseudonym.

What happens, however, if the IdP _does_ learn a pseudonym? Assume they have a
list of their registered users and the corresponding $\mathsf{userId}$s; they
can iterate over them, perform trial calculations, and easily determine the
underlying $\mathsf{userId}$.

We do not view this as a limitation of BISON.Unmasking a user this way
requires a conscious effort by the service provider – it needs to provide the
pseudonym and associated $\mathit{scopeId}$ to the identity provider. The
identity provider cannot do this surreptitiously.

We note that in synchronous authentication protocols, a colluding IdP and SP
can always link users by correlating login timings. By using the timestamp of
the login, they can limit the set of users that some into question, and
compute their pseudonym as stated above.

We therefore consider this an acceptable compromise between strong user
privacy guarantees and accountability requirements. The identity provider
cannot passively gather users’ association data in the course of normal
operation. However, upon exceptional request by a service provider, the
identity provider can determine a misbehaving user’s underlying identity, and
can take action against their account.

##### Entropy of global user IDs

As shown in Section 2.6, correlating two BISON pseudonyms in general would
require deciding the Decisional Diffie-Hellman Problem (DDHP), which is
generally believed to be hard. Additionally, calculating the $\mathsf{userId}$
from the BISON pseudonym ($\mathsf{userId}\cdot\mathsf{ScopeId}$) requires
solving the Discrete Logarithm Problem (DLP).

However, there is a fundamental assumption baked into these statements – that
the $\mathsf{userId}$ is sufficiently unpredictable to make brute-force trial
calculation impractical. This is not the case if, for example, a simple auto-
incrementing database key is used as the $\mathsf{userId}$; iteration over the
integers could then allow the SP, knowing $\mathit{scopeId}$, to determine the
$\mathsf{userId}$.

Therefore, the IdP must ensure that $\mathsf{userId}$ carries sufficient
entropy. One straightforward approach is sampling a random byte string of
length similar to that of the group order; though depending on the context,
others may be preferred.

This issue is not unique to BISON; it is shared by any similar pseudonym
derivation scheme.

###  2.8 Performance Evaluation

A full BISON derivation process consists of sampling of some randomness $r$
and the procedures $\mathsf{Blind}$, $\mathsf{Eval}$, $\mathsf{Blind}$ (again,
to verify), and $\mathsf{Unblind}$. When using a prime-order OPRF over an
elliptic curve group, this process requires 4 elliptic-curve scalar-point
multiplications and 4 hash function evaluations.

When applied in an authentication protocol (cf. Section 3), SP, User, and IdP
need to perform BISON derivation in addition to the established authentication
process and network communication. To maintain usability, it is thus important
that BISON does not slow down the process. To evaluate the performance impact
of BISON, we develop a proof of concept implementation in Kotlin. We
instantiate BISON on the ristretto255 curve using the SHA-512 hash function
and benchmark the implementation using the JMH benchmarking
framework.999https://github.com/openjdk/jmh We run the benchmarks on a
standard office laptop – a Lenovo ThinkPad T14 G2, with a 2.8 GHz Intel Core
i7-1165G7 processor, and typical background load.

On our reference machine, the full BISON derivation process takes $\approx 3$
milliseconds. We took no particular steps to improve the benchmark’s
performance. Therefore, based on these results, we conclude that usage of
BISON derivation has a completely negligible performance impact.

##  3 BISON-augmented OpenID Connect

In this second part of our work, we demonstrate the practical feasibility of
BISON derivation. To do this, we specify an extension to the widely-used
OpenID Connect authentication protocol. This enables it to support BISON
pseudonyms.

###  3.1 Background: OpenID Connect

OpenID Connect (OIDC) is one of the most widely used authentication protocols
on the current internet. Building on the underlying OAuth 2.0 authorization
protocol, it adds an authentication layer, allowing service providers to
obtain a user identifier suitable for re-authentication [45, 37]. It has vast
adoption: Amazon, Apple, DropBox, Facebook, Google, IBM, Linkedin, Microsoft,
and Yahoo all implement OpenID Connect in their respective identity providers
[48, 1].

The goal of an OIDC authentication process is for the service provider to
obtain a so-called _ID Token_. This token is a signed, JSON-encoded set of
key-value pairs, called _claims_ , about the user. One such claim is the
user’s _subject identifier_ (sub claim). The ID Token is signed by the
identity provider, and its integrity can be verified using the identity
provider’s previously-published public key. A traditional OAuth 2.0 access
token may also result from this process. It can be used to access privileged
resources on behalf of the user. This is unrelated to our work, and we do not
consider it further.

Conceptually, the process starts with the service provider, often reacting to
a user action, creating an _Authentication Request_. As part of this request,
the service provider identifies itself (using a client_id), specifies where
the user should be returned to (the redirect_uri), and commonly also includes
a nonce to prevent message replay. It then typically issues an HTTP redirect,
or submits an HTML form, making the user device contact the selected identity
provider with the request.

In reaction to the request, the identity provider prompts the user for any
necessary authentication factors to verify their identity. It then prompts
them for consent to forward their information to the requesting service
provider. If consent is granted, the identity provider issues the
aforementioned ID Token. The token includes the user’s subject identifier,
alongside information used to mitigate various attacks – such as the IdP (iss)
and SP (aud) identifiers, expiry time (exp), and time of issuance (iat). If
requested, it also includes the challenge nonce (nonce). Once the ID Token has
been created, the user device is redirected back to the service provider.

OpenID Connect supports different _operation flows_ , which change how exactly
the service provider now obtains the signed ID Token. In _implicit_ flow, the
ID Token is immediately included when redirecting back to the service
provider. No verification of the service provider’s identity is performed.

By contrast, in _authorization code_ flow, a one-time-use code is included
when redirecting back to the service provider. The service provider can then
redeem this one-time-use code for the ID Token via a back channel to the
identity provider. This redemption process often also includes authorization
of the service provider’s identity via a pre-shared “client secret”.

Our proof of concept uses the implicit flow. We discuss factors motivating
this choice in Section 3.5.

####  3.1.1 Pairwise Pseudonymous Identifiers (PPIDs)

The OpenID Connect specification [45] allows for the use of _pairwise
pseudonymous identifiers_ (PPIDs). Here, the identity provider derives a
pseudonymous identifier for a particular scope, and substitutes it for the
user’s global identifier. For example, Apple’s “Sign in with Apple” OpenID
provider generates a different pseudonymous identifier based on the service
provider’s associated Apple Developer Account [1].

The particular derivation method, and scope delineation, are left up to the
identity provider. Commonly, a hash digest of the user’s global identifier
concatenated with some scope identifier is calculated and used as the user’s
PPID [45, Sec 8.1]. Traditional PPID derivation envisions the IdP knowing
which scope that the user is authenticating for. It enshrines the need for the
IdP to learn sensitive association data with each login. Traditional PPID
derivation and User-SP relationship anonymity towards the identity provider
cannot coexist.

####  3.1.2 FedCM & Browser-augmented OpenID Connect

Traditional OpenID Connect authentication flows, as described above, assume,
and work around, a protocol-unaware user device. This is achieved by
leveraging general-purpose technologies, such as HTTP redirects and HTML form
submissions, to trigger the user’s browser into forwarding opaque information
between logically unrelated remote servers.

Recently, many such technologies have come under scrutiny. This comes in the
wake of web browsers limiting the traditional ways of tracking user behavior
across disparate web origins, such as third-party cookies, which have long
been misused by the online advertising sector. In reaction, privacy
adversaries have explored new ways of associating user interactions; this
includes the use of message-carrying redirects to make the browser identify
itself to an advertising tracker. In response, Browser manufacturers propose
limiting such _stateful redirects_. This would eliminate the technology that
OpenID Connect, and similar use cases, depend on.

The current W3C proposal to solve this conundrum is the _FedCM API_ [33]. It
envisions browsers as being conceptually aware of authentication processes,
and taking an active role in negotiating user authentication. This represents
a paradigm shift away from the traditional OIDC-unaware user device.

###  3.2 OpenID Connect Extension

We build on the existing OIDC infrastructure by specifying BISON pseudonym
derivation as an alternative opt-in PPID derivation method. For our prime-
order group, we choose the _ristretto255_ elliptic curve group [17]. As our
hash function, we choose SHA512. We note that our choices match the parameters
for a standards-track prime-order OPRF instantiation [16], and will motivate
them further in Section 3.5.

We will group our extension’s changes into _substantial_ and _boilerplate_
changes. The substantial changes, that integrate BISON into OpenID Connect,
are as follows. (I). If the service provider opts into BISON derivation, the
user device modifies the OIDC authorization request in three ways. (a). It
replaces OIDC’s existing service provider identifier field (client_id) with
BISON’s $\mathsf{Blind}$-ed scope identifier; (b). it replaces the return
location (redirect_uri) with a browser-local URI that does not expose the
actual value; (c). and it replaces the SP’s chosen nonce with the hash digest
of the current secure origin101010This is necessary because the current origin
may be different from the $\mathit{scopeId}$. See Section 3.2.1 for details on
$\mathit{scopeId}$ authentication. and the nonce. (II). If BISON derivation
has been requested, the identity provider $\mathsf{Eval}$-s the provided
client_id value alongside the user’s global identifier. The resulting blinded
pseudonym is stored in the existing subject field (sub claim) of the resulting
signed JWT, while the input blinded scope identifier is stored in the existing
audience field (aud claim). (III). When redirecting back to the service
provider, the user device adds the randomly selected blind as an (unsigned)
blind parameter. (IV). After the service provider has verified the signed ID
Token, it performs BISON derivation. (a). It re-calculates $\mathsf{Blind}$
and validates that aud is correct. (b). It verifies that the value of nonce is
as expected. (c). It derives the user’s BISON pseudonym by
$\mathsf{Unblind}$-ing sub.

To support opt-in negotiation of the pairwise identifier derivation method, we
also add the necessary boilerplate. (V). We add a new optional
pairwise_subject_types array to the identity provider’s existing OpenID
Connect Discovery metadata [46]. This array advertises the cryptographic
derivation methods supported. We define bison as one possible value for this
array. (VI). The service provider may opt into any of the derivation methods
listed by specifying the chosen method in the pairwise_subject_type field of
the authentication request. If it specifies bison, derivation proceeds as
described above. (VII). The identity provider includes the used derivation
method (in our case, bison) as a pairwise_subject_type claim in the signed ID
Token.

####  3.2.1 Analysis

We now discuss how our integration into OIDC meets the host protocol security
criteria described in Section 2.6.1.

Taking inspiration from existing web standards, such as Web Authentication
[44], we bind scope identifier authorization to the underlying HTTPS browsing
context. We limit use of BISON derivation to secure browsing contexts, such as
top-level windows serving content via HTTPS.111111For a more detailed
definition of this term of art, we refer to https://w3c.github.io/webappsec-
secure-contexts. This implies that the browser has validated the current
page’s TLS certificate using its internal trust store. Thus, under the
assumption that the Web PKI can be trusted, the current page origin is trusted
information. We leverage it for $\mathit{scopeId}$ validation.

We define acceptable $\mathit{scopeId}$ values to be either the current page
origin, or a registrable domain suffix of the current page origin. This
mirrors the limitation placed on the relying party identifier field in Web
Authentication [44]. For example, login.example.com and app.example.com may
derive a shared pseudonym by using the example.com $\mathit{scopeId}$.
However, login.example.com and login.unrelated.com cannot derive a shared
pseudonym, as .com is not registrable.121212For a detailed definition, we
refer to https://html.spec.whatwg.org/multipage/browsers.html.

We then limit the return address to being on the same web origin as the
current page origin. When combined, these two steps achieve both scope
identifier authentication and binding to the underlying encrypted TLS
transport.

We do not need to take any additional steps to prevent message replay. OpenID
Connect already includes replay protection in the form of a random challenge
nonce, chosen by the service provider. We also leverage this nonce for SP
commitment, to mitigate the same-scope MitM attack outlined in Section 2.6.1.
We do this by combining both the SP-chosen nonce and the current user-facing
secure web origin – not the $\mathit{scopeId}$ – to form the nonce sent to the
IdP. This nonce is included in the signed ID Token that the identity provider
issues, and can then be verified by the service provider.

###  3.3 Implementation

We present a full implementation of the OIDC extension described in Section
3.2. It takes the form of a BISON-aware service provider and identity
provider, as well as a browser extension for the Firefox browser responsible
for handling user device tasks. The source code is available on
GitHub.131313https://github.com/iaik-jheher/BISON

The demonstrator models a minimal authentication flow in OIDC implicit flow.
The service provider, on initial startup, requests the identity provider’s key
material using OIDC Discovery. Since the IdP indicates support for BISON
derivation, the SP decides to use it going forward.

When the user indicates a desire to log in, the service provider generates a
random nonce value and a random state value. It sends these values, alongside
the desired return location, the identity provider entry point, and the
desired scope identifier, to the browser extension. It retains the random
nonce value and desired scope identifier, indexed by the random state value,
linked to the user device’s local session.

The browser extension validates that the values provided are permissible under
the criteria described in Section 3.2.1. It then prompts the user for consent
to proceed to the identity provider. When doing so, it also displays the
service provider’s origin, as well as the requested scope. This is depicted in
Figure 3. If consent is withheld, the extension returns to the service
provider with an appropriate OIDC failure message. If consent is given, it
instead proceeds as follows.

Figure 3: The BISON consent dialog.

The extension generates a suitable random blind, and a new random state value.
It performs the OPRF $\mathsf{Blind}$ operation on the scope identifier as
described in Section 3.2. It also derives a new nonce by combining the service
provider’s nonce and user-visible web origin. It then redirects the user to
the identity provider’s OIDC endpoint as specified by the service provider in
its request. To mask the service provider’s identity, it specifies a web-
accessible extension page as the return URI. The extension retains the
original state value and return URI, as well as the random blind. These values
are stored in temporary storage, indexed by the new state value.

When the user arrives at our demonstrator identity provider, it performs mock
“authentication” by allowing the user to choose between one of three pre-
defined identities. Once a choice is made, the IdP performs the OPRF
$\mathsf{Eval}$ operation as described in Section 3.2. It then creates an
appropriate signed ID Token using ECDSA on the P-256 Elliptic Curve. The IdP
then submits the token to the specified return URI (which is a browser
extension page) alongside the (extension’s) state.

Based on the specified state, the browser extension looks up the appropriate
service provider state value, random blind, and original return URI. It then
automatically forwards the received ID Token to the original return address.
It includes the original state, and the random blind that was used.

The service provider validates the ID Token’s authenticity using the ECDSA
public key material originally received as part of the identity provider’s
OIDC discovery metadata. It then looks up the expected nonce value and
expected scope identifier based on the state value provided. It validates that
the nonce claim in the received ID Token matches the expected
value.141414These steps are not particular to our implementation; it is how
OpenID Connect guarantees freshness of the response in implicit flow.

It then calculates $\mathsf{Blind}$ for the expected scope identifier and
claimed blind value, and validates that the result matches the aud claim in
the ID Token. Finally, if all of these steps have succeeded, it can derive the
user’s BISON pseudonym by $\mathsf{Unblind}$ing the ID Token’s sub claim. The
user has now been privately and securely authenticated.

###  3.4 Evaluation

We compare our OpenID Connect extension, and our implementation of it, against
a “traditional” OIDC-based authentication flow. For overhead induced by the
abstract BISON protocol, we refer to our prior evaluation in Section 2.8.
Instead, we focus on differences unique to browser-based login.

We consider the changed user experience of BISON-augmented authentication. In
BISON, the identity provider is no longer aware of the service provider’s
identity. Therefore, its UX also cannot ask the user’s consent for the
authentication. Instead, this step needs to be done by the browser. In our
proof of concept implementation, we have designed a dedicated dialog, shown in
Figure 3, for this purpose.

This dialog is displayed before the user is redirected to the identity
provider, and presents an additional step compared to traditional, non-BISON
OIDC. However, in a traditional UX flow, after the user device authenticates
to the IdP, the IdP would then commonly present an additional page requesting
user consent. This additional page is unnecessary in BISON, as consent has
already been obtained by the user device. Therefore, we conclude that BISON-
augmented OIDC does not require additional user interaction compared to
traditional OIDC; it merely changes the sequence of user interaction, shifting
user consent to be before authentication.

Additionally, we note that BISON-augmented OIDC, in contrast to unaugmented
OIDC, now requires a protocol-aware browser. We discuss this further in
Section 3.5.

###  3.5 Discussion

This section lists some additional subtle distinctions between BISON-augmented
and unaugmented OIDC. We address these differences’ impact on the practical
use of BISON, and also motivate our choice of cryptographic parameters.

##### Protocol Awareness in Browsers

One crucial benefit of OpenID Connect, which has contributed to its widespread
adoption, is that it does not require the user device to be aware of its
existence. BISON-augmented OIDC does not offer this benefit. It requires the
web browser to take an active role: verify the $\mathit{scopeId}$, perform
blinding operations, and obtain user consent using built-in dialog windows.
This requires the web browser to be aware of OpenID Connect’s existence.

A few years ago, this limitation would have relegated our work chiefly into
the realm of purely academic wish-casting; a castle on a cloud, never to be
realized in practice. But the internet moves along, and so does practicality.
Browsers are moving towards standardizing federated authentication; using
semantics to decide between legitimate and illegitimate uses of technology. We
described these efforts in Section 3.1.2.

In this environment, we believe the requirement for active browser engagement
in authentication is no longer disqualifying. We believe the time has come for
browsers to take an active role in safeguarding their users’ privacy – and we
believe that BISON is the tool to do it with.

##### Choice of OIDC flow

OpenID Connect envisions different ways (called “flows”, cf. Section 3.1) to
transmit the signed _ID Token_ from the identity provider to the service
provider.

In our PoC, we use _implicit_ flow, even though _authorization code_ flow is
common in practice. This has multiple reasons.

Most obviously, authorization code flow uses a “back-channel”, a direct
connection between the SP and IdP, to exchange the ID Token. This back-channel
presents an obvious challenge to our relationship anonymity goal; the ID Token
corresponds to a particular user’s login process, while the entity requesting
it is the service provider they logged in at. To maintain relationship
anonymity, the service provider would thus need to connect to the identity
provider without revealing its identity. While such an anonymous connection is
possible [20], realizing this in practice is not trivial.

We now consider the primary benefit of authorization code flow compared to
implicit flow: service provider authentication. When redeeming the
authorization code for the ID Token, the service provider commonly provides a
pre-shared secret to authenticate itself. This prevents a malicious user, or
service provider impersonator, from obtaining the ID Token and identifying
information. In BISON, however, the service provider cannot authenticate to
the identity provider – this would be antithetical to an anonymous connection
to the identity provider. Instead, the user authenticates the service provider
for the given $\mathit{scopeId}$; authentication towards the identity provider
is thus rendered unnecessary.

Therefore, we do not consider the use of implicit flow to be a downside,
assuming standard safety measures – such as the use of POST redirects with the
ID Token – are taken.151515We also refer to previous work by Kroschewski and
Lehmann[36] for additional discussion on the implicit flow as a privacy-
enabling tool.

##### User obtains their pseudonym

In traditional OpenID Connect, when using the authorization code flow, the ID
Token (and the claims contained therein) are invisible to the user. This means
that the user does not learn the pseudonym that is exposed (in the sub claim)
to the service provider.

When using OpenID Connect using implicit flow, as happens with BISON-augmented
OIDC for the reasons described previously, the user learns the ID Token. Since
the user also knows $r$, that means they can also derive their BISON pseudonym
$\mathsf{userId}\cdot\mathsf{ScopeId}$ using the same method as the SP.

We do not view this as a weakness of BISON; we believe that users _in general_
should have awareness of what information about them is exchanged. Regardless,
we still note this departure from the knowledge model of traditional OIDC.

However, we also note that the user still does not obtain their
$\mathsf{userId}$; this information is always private to the IdP.

##### Choice of cryptographic parameters

When instantiating BISON, we use _ristretto255_ as a prime-order group for two
reasons: First, it is compatible with the widely used Curve25519. Second, and
consequently, ristretto255 had existing available
Java161616https://github.com/cryptography-cafe/curve25519-elisabeth and
JavaScript171717https://github.com/facebook/ristretto255-js implementations.

In general, BISON can be instantiated over any prime-order group on which the
DLP and DDHP are hard. Prime-Order OPRFs have similar requirements; here, the
CFRG draft suggests, in addition to ristretto255, the decaf448, P-256, P-384,
and P-521 curve groups [16]. Our particular choice of ristretto255 is made
solely out of operational convenience.

The choice of SHA-512 also matches the CFRG draft, and is a natural fit for
the ristretto255 group. Since SHA-512 is a standardized cryptographic hash
function, fast, secure implementations of it are widely available.

##  4 Related Work

Table 1:  Overview of privacy-focused SSO systems. Feature supported ,
partially supported , or unsupported

|  | Not broken |  Relationship Anonymity |  Pseudonym Unlinkability | Sybil Resistance | Stateless |  Client Unmodified | Asynchronous
---|---|---|---|---|---|---|---|---
OIDC | [45] |  |  |  |  |  |  |
OIDC w/ PPID | [45, 8.1] |  |  |  |  |  |  |
Shibboleth | [14] |  |  |  |  |  |  |
BrowserID | [52] |  [23] |  |  |  |  |  |
PseudoID | [18] |  |  |  |  |  |  |
POIDC | [30] |  |  1 |  2 |  |  |  |
SPRESSO | [24] |  |  |  |  |  |  |
UPPRESSO | [29] |  |  1 |  |  |  |  |
EL PASSO | [56] |  |  |  |  |  |  |
BISON |  |  |  |  |  |  |  3 |

1\. Only when assuming a very generous definition of a honest-but-curious
identity provider.

2\. Only in the “Pairwise POIDC” variant, which requires ZK-proofs.

3\. We discuss OIDC protocol awareness in browsers in Section 3.5.

We survey existing protocols for delegated authentication, and in Table 1,
compare them against our privacy goals.

We begin with protocols that are currently, or were previously, being used in
real-world applications.

Baseline _OpenID Connect_ (OIDC) [45] is not private. It discloses the service
provider’s identity to the identity provider, and the user’s identity to the
service provider. OIDC optionally supports _Pairwise Pseudonymous Identifiers_
(PPIDs) to enable unlinkability between colluding SPs.181818see Section 3.1
This fundamentally requires the IdP to be aware of the SP’s identity.

_Shibboleth_ is a SSO system based on SAML. It supports pseudonym
unlinkability by means of “persistent identifiers”, which are unique to the
combination of SP, IdP, and
user.191919https://shibboleth.atlassian.net/wiki/spaces/SHIB/pages/1929379856/IdPUserAuthnConfig
Just like OpenID Connect’s PPIDs, the derivation process can only be performed
if the SP’s identity is known to the IdP.

_BrowserID_ [52] was a short-lived initiative by the Mozilla Foundation
(branded as Mozilla Persona) to embed secure delegated authentication in the
browser. In contrast to the systems mentioned above, it succeeded in
protecting User-SP relationship anonymity; but it did not even attempt to
provide pseudonym unlinkability, choosing to identify users by their email
address. Further, Fett et al. discovered attacks against BrowserID [22]. They
also exploit design flaws in BrowserID to allow arbitrary parties to query
users’ login status [23]. Mozilla decommissioned the service in 2016.

Next, we will move on from protocols employed in existing software, and list
approaches explored in academic literature.

_PseudoID_ [18] uses blind signatures to extend OpenID, the precursor of
OpenID Connect, with privacy features. It introduces a blind signer that
issues pseudonym tokens to an user, that the user then uses to authenticate at
the IdP. This enables unlinkability since a user can use a separate pseudonym
for each SP. However, while the IdP does not learn which “real” user is
authenticating at a specific SP, it nevertheless can link multiple visits of
the same pseudonymous user.

BrowserID inspired _SPRESSO_ [24]. It provides user-SP relationship anonymity,
but not pseudonym unlinkability, as email addresses continue to be used as
user identifiers.

_POIDC_ [30] extends OIDC to prevent the IdP from learning at which SPs users
authenticate. It then extends this to _pairwise POIDC_ , which uses zero-
knowledge proofs to prevent colluding SPs from tracking users. Zero-knowledge
proofs introduce nontrivial complexity to implementations. This complexity,
and a lack of standardization, often hinders a protocol’s adoption in
practice, or inclusion in other standards [51]. Further, ZKPs have non-trivial
calculation overhead, exceeding that of BISON by orders of magnitude; pairwise
POIDC with SHA-256 requires 110ms, as opposed to BISON’s 3ms (see Section
2.8). This is needed, as in POIDC the IdP does not participate in the
computation of the pseudonym. Further, POIDC avoids browser modifications by
requiring the SP and IdP to provide trustworthy JavaScript code to the user.
This strains the definition of a honest-but-curious identity provider; instead
of merely performing authentication truthfully, POIDC’s IdPs actively act
contrary to their own data collection interests. By contrast, BISON does not
expose sensitive privacy-breaking information to code controlled by the
identity provider.

The idea of using blinded evaluation to derive pseudonyms has also
independently been explored by _UPPRESSO_ [29]. However, its design is
inflexible, and narrowly tailored to its use case. By contrast, BISON is
flexible, and can be easily adapted to fit any protocol. UPPRESSO, like POIDC,
asks the IdP to provide trustworthy JavaScript code to the user, which then
acts to protect the user from the IdP’s own behavior.

_EL PASSO_ [56] is a complex delegated authentication system that achieves
both relationship anonymity and pseudonym unlinkability. In exchange, it
requires storing a user secret on the client device. As discussed in Section
2.2, this is a significant downside in general; the same is true of EL PASSO.
If a user secret is lost, it envisions an out-of-band procedure to “replace”
the user secret while updating a commitment at the identity provider. This
limits Sybil resistance, as the user obtains a new set of pseudonyms as a
result of the replacement.

_Other approaches_ rely on blockchains [6], distributed IdPs [4, 5, 25], or
hardware features like TEE or SGX [28, 55]. Reaching further, credential-based
so-called “user-centric” systems are often proposed an alternative to
delegated authentication approaches, e.g., Idemix [12, 11], U-Prove [39],
ABC4Trust [42], and ZKlaims [47]. They store the login information
(credentials) on the user device and don’t involve the IdP in the
authentication process. This need for a state on the user client, and the
difficulty of key management and key backups [32, 31] have limited their
practical adoption thus far [30]. Several works survey and evaluate privacy
aspects of SSO systems in the wild, e.g., [53, 54, 19]. Finally, Brandão et
al. [10] discuss nation-scale identification and authentication systems for
credential management. The paper analyzes the US’ _Federal Cloud Credential
Exchange_ and the _UK’s gov.uk verify_ , which propose a brokered ID
architecture but suffer from serious privacy and security shortcomings.

##  5 Conclusion

In this work, we have solved a fundamental challenge of delegated
authentication: how does one derive a privacy-preserving scoped pseudonym in a
trustworthy manner, when at the same time the identity provider must not learn
its scope.

These two privacy goals, each of which is clearly desirable in its own right,
seemed to be at odds in a naïve approach: if the identity provider does not
know the scope or the pseudonym, how can they produce a signature over either?
Many existing solutions deployed in the real world, such as OpenID Connect, do
not address this question, and instead treat the identity provider as a fully
trustworthy “super-party” to the protocol. This has wide-ranging privacy
implications, as it allows a single central party to amass large amounts of
highly sensitive association data during regular operation.

To address this shortcoming, we presented the BISON protocol for pseudonym
derivation. Inspired by Oblivious Pseudo-Random Functions, it enables User-SP
relationship anonymity towards the identity provider while maintaining other
desirable properties, such as pseudonym unlinkability, Sybil resistance, and
statelessness. BISON is lightweight and uses only simple cryptographic
operations. Therefore, it is easy to understand, implement, and reason about.
BISON also does not add any additional parties or requests to the standard
authentication flow. For each goal, we provided a security proof,
demonstrating that BISON meets the goals described.

We went on to outline how BISON can be integrated into any existing
authentication protocol. Assuming a small well-defined set of requirements is
fulfilled, BISON then provides its privacy guarantees to the underlying “host”
protocol. We also showed that this integration has negligible overhead; BISON
only requires four elliptic curve scalar-point multiplications and four hash
function evaluations. When instantiated using common cryptographic parameter
choices, a full BISON derivation takes $\approx 3$ milliseconds on an average
office laptop, even without any effort having been expended towards optimizing
its performance.

We then further illustrated BISON’s practicality by specifying an extension to
the widely-used OpenID Connect authentication protocol. This extension allows
opt-in BISON-based derivation for pseudonyms, entirely within OIDC’s existing
message structure. At a time when browser vendors are moving towards
standardizing delegated authentication on the web, this is an important
contribution. We provided a demonstrator for our extension. It consists of a
service provider, identity provider, and browser extension for the Firefox
browser.

We believe BISON represents an important milestone on the road towards a
privacy-preserving internet.

## Availability

As mentioned in Section 3.3, our work includes a full implementation of our
OIDC extension; this consists of BISON-aware service and identity providers
(in Kotlin), as well as a browser extension for the Firefox browser (in
JavaScript). The source code is publicly available on
GitHub.202020https://github.com/iaik-jheher/BISON

## Acknowledgements

This work was supported by the European Union’s Horizon 2020 research and
innovation program under grant agreement № 101020416 (ERATOSTHENES). Further,
we are grateful to Maria Eichlseder and Stefan Kreiner for inspirational
discussions.

## References

  * [1] Authenticating users with Sign in with Apple.  https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple.  Accessed: 2023-09-04.
  * [2] Relationship anonymity.  In Encyclopedia of Cryptography and Security (2nd Ed.), page 1041\. Springer, 2011.
  * [3] P Abel.  Consumer perceptions of online registration and social sign-in.  Blue Research for Janrain Inc. Retrieved on, 2012.
  * [4] Shashank Agrawal, Peihan Miao, Payman Mohassel, and Pratyay Mukherjee.  PASTA: password-based threshold authentication.  In CCS, pages 2042–2059. ACM, 2018.
  * [5] Carsten Baum, Tore Kasper Frederiksen, Julia Hesse, Anja Lehmann, and Avishay Yanai.  PESTO: proactively secure distributed single sign-on, or how to trust a hacked server.  In EuroS&P, pages 587–606. IEEE, 2020.
  * [6] Yousra Belfaik, Yassine Sadqi, Yassine Maleh, Said Safi, Lo’ai Ali Tawalbeh, and Khaled Salah.  A novel secure and privacy-preserving model for openid connect based on blockchain.  IEEE Access, 11:67660–67678, 2023.
  * [7] Gerrit Bleumer.  Unlinkability.  In Encyclopedia of Cryptography and Security (2nd Ed.), page 1350\. Springer, 2011.
  * [8] Gerrit Bleumer.  Untraceability.  In Encyclopedia of Cryptography and Security (2nd Ed.), pages 1351–1352. Springer, 2011.
  * [9] Dan Boneh.  The decision diffie-hellman problem.  In Joe P. Buhler, editor, Algorithmic Number Theory, pages 48–63, Berlin, Heidelberg, 1998. Springer Berlin Heidelberg.
  * [10] Luís T. A. N. Brandão, Nicolas Christin, George Danezis, and anonymous.  Toward mending two nation-scale brokered identification systems.  Proc. Priv. Enhancing Technol., 2015(2):135–155, 2015.
  * [11] Jan Camenisch and Els Van Herreweghen.  Design and implementation of the _idemix_ anonymous credential system.  In CCS, pages 21–30. ACM, 2002.
  * [12] Jan Camenisch and Anna Lysyanskaya.  An efficient system for non-transferable anonymous credentials with optional anonymity revocation.  In EUROCRYPT, volume 2045 of LNCS, pages 93–118. Springer, 2001.
  * [13] Sílvia Casacuberta, Julia Hesse, and Anja Lehmann.  SoK: Oblivious pseudorandom functions.  In 2022 IEEE 7th European Symposium on Security and Privacy (EuroS&P), pages 625–646, 2022.
  * [14] Shibboleth Consortium.  Shibboleth.  https://www.shibboleth.net/products/, 2023.
  * [15] Francisco Corella and Karen P Lewison.  Nstic, privacy and social login.  W3C Workshop on Identity in the Browser, 2011.
  * [16] Alex Davidson, Armando Faz-Hernandez, Nick Sullivan, and Christopher A. Wood.  Oblivious pseudorandom functions (oprfs) using prime-order groups.  https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/, 2023.
  * [17] Henry de Valence, Jack Grigg, Mike Hamburg, Isis Lovecruft, George Tankersley, and Filippo Valsorda.  The ristretto255 and decaf448 groups.  https://datatracker.ietf.org/doc/draft-irtf-cfrg-ristretto255-decaf448/, 2020\.
  * [18] Arkajit Dey and Stephen Weis.  Pseudoid: Enhancing privacy in federated login.  In Hot Topics in Privacy Enhancing Technologies, pages 95–107, 2010\.
  * [19] Yana Dimova, Tom van Goethem, and Wouter Joosen.  Everybody’s looking for ssomething: A large-scale evaluation on the privacy of oauth authentication on the web.  Proc. Priv. Enhancing Technol., 2023(4):452–467, 2023.
  * [20] Roger Dingledine, Nick Mathewson, and Paul F. Syverson.  Tor: The second-generation onion router.  In USENIX, pages 303–320. USENIX, 2004.
  * [21] John R. Douceur.  The sybil attack.  In IPTPS, volume 2429 of LNCS, pages 251–260. Springer, 2002.
  * [22] Daniel Fett, Ralf Küsters, and Guido Schmitz.  An expressive model for the web infrastructure: Definition and application to the browserid SSO system.  CoRR, abs/1403.1866, 2014.
  * [23] Daniel Fett, Ralf Küsters, and Guido Schmitz.  Analyzing the browserid SSO system with primary identity providers using an expressive model of the web.  In ESORICS (1), volume 9326 of LNCS, pages 43–65. Springer, 2015.
  * [24] Daniel Fett, Ralf Küsters, and Guido Schmitz.  SPRESSO: A secure, privacy-respecting single sign-on system for the web.  In CCS, pages 1358–1369. ACM, 2015.
  * [25] Tore Kasper Frederiksen, Julia Hesse, Bertram Poettering, and Patrick Towa.  Attribute-based single sign-on: Secure, private, and efficient.  Proc. Priv. Enhancing Technol., 2023(4):35–65, 2023.
  * [26] Ruti Gafni and Dudu Nissim.  To social login or not login? exploring factors affecting the decision.  Issues in Informing Science and Information Technology, 11(1):57–72, 2014.
  * [27] Mohammad Ghasemisharif, Amrutha Ramesh, Stephen Checkoway, Chris Kanich, and Jason Polakis.  O single sign-off, where art thou? an empirical analysis of single sign-on account hijacking and session management on the web.  In USENIX, pages 1475–1492. USENIX Association, 2018.
  * [28] Chengqian Guo, Fan Lang, Qiongxiao Wang, and Jingqiang Lin.  Up-sso: Enhancing the user privacy of sso by integrating ppid and sgx.  In 2021 International Conference on Advanced Computing and Endogenous Security, pages 01–05, 2022.
  * [29] Chengqian Guo, Jingqiang Lin, Quanwei Cai, Fengjun Li, Qiongxiao Wang, Jiwu Jing, Bin Zhao, and Wei Wang.  UPPRESSO: untraceable and unlinkable privacy-preserving single sign-on services.  CoRR, abs/2110.10396, 2021.
  * [30] Sven Hammann, Ralf Sasse, and David A. Basin.  Privacy-preserving openid connect.  In AsiaCCS, pages 277–289. ACM, 2020.
  * [31] Felix Hörandner and Franco Nieddu.  Cloud data sharing and device-loss recovery with hardware-bound keys.  In ICISS, volume 11952 of LNCS, pages 196–217. Springer, 2019.
  * [32] Felix Hörandner and Christof Rabensteiner.  Horcruxes for everyone - A framework for key-loss recovery by splitting trust.  In TrustCom/BigDataSE, pages 50–57. IEEE, 2019.
  * [33] Eiji Kitamura.  Federated credential management api.  https://developer.chrome.com/docs/privacy-sandbox/fedcm/, 2022.
  * [34] Maina Korir, Simon Parkin, and Paul Dunphy.  An empirical study of a decentralized identity wallet: Usability, security, and perspectives on user control.  In SOUPS @ USENIX, pages 195–211. USENIX Association, 2022\.
  * [35] Jan Krämer, Daniel Schnurr, and Michael Wohlfarth.  Winners, losers, and facebook: The role of social logins in the online advertising ecosystem.  Manag. Sci., 65(4):1678–1699, 2019.
  * [36] Maximilian Kroschewski and Anja Lehmann.  Save the implicit flow? enabling privacy-preserving RP authentication in openid connect.  Proc. Priv. Enhancing Technol., 2023(4):96–116, 2023.
  * [37] Christian Mainka, Vladislav Mladenov, Jörg Schwenk, and Tobias Wich.  Sok: Single sign-on security - an evaluation of openid connect.  In EuroS&P, pages 251–266. IEEE, 2017.
  * [38] Kevin S McCurley.  The discrete logarithm problem.  In Proc. of Symp. in Applied Math, volume 42, pages 49–74. USA, 1990.
  * [39] Wojciech Mostowski and Pim Vullers.  Efficient u-prove implementation for anonymous credentials on smart cards.  In SecureComm, volume 96 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, pages 243–260. Springer, 2011.
  * [40] Andreas Pfitzmann and Marit Hansen.  A terminology for talking about privacy by data minimization: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management, 2010.  v0.34.
  * [41] Blaz Podgorelec, Lukas Alber, and Thomas Zefferer.  What is a (digital) identity wallet? A systematic literature review.  In COMPSAC, pages 809–818. IEEE, 2022.
  * [42] Kai Rannenberg, Jan Camenisch, and Ahmad Sabouri, editors.  Attribute-based Credentials for Trust: Identity in the Information Society.  Springer, 2015.
  * [43] Josyula R. Rao and Pankaj Rohatgi.  Can pseudonymity really guarantee privacy?  In USENIX. USENIX Association, 2000.
  * [44] W3C Recommendation.  Web authentication: An api for accessing public key credentials.  https://www.w3.org/TR/webauthn-2/, 2021.
  * [45] Nat Sakimura, John Bradley, Michael B. Jones, Breno de Medeiros, and Chuck Mortimore.  Openid connect core 1.0.  https://openid.net/specs/openid-connect-core-1_0.html, 2014.
  * [46] Nat Sakimura, John Bradley, Michael B. Jones, and Edmund Jay.  Openid connect discovery 1.0.  https://openid.net/specs/openid-connect-discovery-1_0.html, 2014\.
  * [47] Martin Schanzenbach, Thomas Kilian, Julian Schütte, and Christian Banse.  Zklaims: Privacy-preserving attribute-based credentials using non-interactive zero-knowledge techniques.  In ICETE (2), pages 325–332. SciTePress, 2019.
  * [48] Amir Sharif, Roberto Carbone, Giada Sciarretta, and Silvio Ranise.  Best current practices for oauth/oidc native apps: A study of their adoption in popular providers and top-ranked android clients.  Journal of Information Security and Applications, 65:103097, 2022\.
  * [49] Sandra Steinbrecher and Stefan Köpsell.  Modelling unlinkability.  In Privacy Enhancing Technologies, volume 2760 of LNCS, pages 32–47. Springer, 2003.
  * [50] San-Tsai Sun, Eric Pospisil, Ildar Muslukhov, Nuray Dindar, Kirstie Hawkey, and Konstantin Beznosov.  What makes users refuse web single sign-on?: an empirical investigation of openid.  In SOUPS, page 4. ACM, 2011.
  * [51] Xueyan Tang, Lingzhi Shi, Xun Wang, Kyle Charbonnet, Shixiang Tang, and Shixiao Sun.  Zero-knowledge proof vulnerability analysis and security auditing.  IACR Cryptol. ePrint Arch., page 514, 2024.
  * [52] Mozilla Identity Team.  Persona / browserid.  https://github.com/mozilla/persona, 2016.
  * [53] Kailong Wang, Guangdong Bai, Naipeng Dong, and Jin Song Dong.  A framework for formal analysis of privacy on SSO protocols.  In SecureComm, volume 238 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, pages 763–777. Springer, 2017.
  * [54] Maximilian Westers, Tobias Wich, Louis Jannett, Vladislav Mladenov, Christian Mainka, and Andreas Mayer.  Sso-monitor: Fully-automatic large-scale landscape, security, and privacy analyses of single sign-on in the wild.  CoRR, abs/2302.01024, 2023.
  * [55] Rongwu Xu, Sen Yang, Fan Zhang, and Zhixuan Fang.  MISO: legacy-compatible privacy-preserving single sign-on using trusted execution environments.  In EuroS&P, pages 352–372. IEEE, 2023.
  * [56] Zhiyi Zhang, Michal Król, Alberto Sonnino, Lixia Zhang, and Etienne Rivière.  EL PASSO: efficient and lightweight privacy-preserving single sign on.  Proc. Priv. Enhancing Technol., 2021(2):70–87, 2021.
  * [57] Maximilian Zinkus, Tushar M. Jois, and Matthew Green.  Sok: Cryptographic confidentiality of data on mobile devices, 2021.

Paper history:

  * •

2023 October: Unsuccessful submission to USENIX ’24 (Fall)

  * •

2024 May: Publication of revised pre-print