Many thanks to every one who provided feedback on the
privacy postures of
which was announced in the
blog post. The paper was discussed on the
Identity Commons mailing list
and we also received feedback at the
where we presented the paper, and at
IIW 16, where we
showed a poster summarizing the paper. In this post I will recap the
feedback that we have received and the revisions that we have made to
the paper based on that feedback.
Steven Carmody pointed out that
SWITCH, the Swiss InCommon federation,
has developed an extension of Shibboleth called
that allows the identity or attribute provider to ask the user for
consent before disclosing attributes to the relying party. Ken
Klingestein told us that the
Privacy NSTIC pilot is developing a privacy manager that will let
the user choose what attributes will be disclosed to the the relying
party by the Shibboleth identity provider. We have added references
to these Shibboleth extensions to Section 4.2 of the paper.
The original paper explained that, although a U-Prove token does not
provide multishow unlinkability, the user may obtain multiple tokens
from the issuer, and present different tokens to different relying
parties. Christian Paquin said that a U-Prove
credential is defined as a batch of such tokens, created simultaneously by an
efficient parallel procedure. We have added this definition of a
U-Prove credential to Section 4.3.
Christian Paquin also pointed out that a U-Prove token is a
mathematical concept that can be embodied in a variety of
technologies. He sent me a link to the
embodiment, which was used in CardSpace. We have explained this
and included the link in Section 4.3.
Tom Jones said that what we call anonymity is
called pseudonymity by others. In fact, column 9, labeled
“Anonymity”, covers both pseudonymity, as provided, e.g., by an Idemix
pseudonym or an uncertified key pair or a combination of a user ID and
a password when the user ID is freely chosen by the user, and full
anonymity, as provided when a relying party learns only attributes
that do not uniquely identify the user. I think it is not
unreasonable to view anonymity (the service provider does not learn
the user’s “name”) as encompassing pseudonymity (the service provider
learns a pseudonym instead of the “real name”).
Nat Sakimura provided a lot of feedback, for which we are grateful.
He said that Google and Yahoo implemented OpenID Pairwise
Pseudonymous Identifiers (PPID), i.e. different identifiers for
the same user provided to different relying parties, before ICAM
specified its OpenID profile. We have noted this in
Section 4.2 of the revised paper and changed the label of row 8 to “OpenID (without PPID)”.
He also said that OpenID Connect supports an ephemeral identifier,
which provides anonymity. I was able to find a discussion of an
ephemeral identifier in the archives of the OpenID Connect mailing
list, but no mention of it in any of the OpenID Connect
specifications; so ephemeral identifiers may be added in the future,
but they are not there yet.
Nat also argued that OpenID Connect provides multishow unlinkability
by different parties and by the same party. I disagree, however. The
Subject Identifier in the ID Token makes OpenID Connect authentication
events linkable. Furthermore, OpenID is built on top of OAuth, whose
purpose is to provide the relying party with access to resources owned
by the user by means of an access token. In a typical use case the
relying party gets access to the user’s account at a social network
such as Facebook, Twitter or Google+. It is unlikely that two relying
parties who share information cannot determine that they are both
accessing the same account, or that a relying party cannot determine
that it has accessed the same account in two different occasions.
Nat said that OpenID Connect can be used for two-party authentication
using a “Self-Issued OpenID Provider”. We have added a checkmark to
row 11, column 1 of the table to indicate this, and an explanation to
He also said that OpenID Connect provides group 4 functionality by
allowing the relying party to obtain attributes from “distributed
attribute providers”. We have mentioned this in Section 4.4 of the
revised version of the paper.
Finally, Nat said:
Just by reading the paper, I was not very clear what is the
requirement for Issue-show unlinkability. By issuance, I imagine it
means the credential issuance. I suppose then it means that the
credential verifier (in ISO 29115 | ITU-T X.1254 sense) cannot tell
which credential was used though it can attest that the user has a
valid credential. Is that correct? If so, much of the technology in
group 2 should have n/a in the column because they are independent of
the actual authentication itself. They could very well use anonymous
authentication or partially anonymous authentication (ISO 29191).
The technologies in group 2 are recursive authentication technologies.
The relying party directs the browser to the identity or attribute
provider, which recursively authenticates the user and provides a
bearer credential to the relying party based on the result of the
inner authentication. In all generality there may be multiple inner
authentications, as the identity or attribute provider may require
multiple credentials. So the authentication process may consist of a
tree of nested authentications, with internal nodes of the tree
involving group 2 technologies, and leaf nodes other technologies.
However, rows 5-11 (group 2) are only concerned with the usual case
where the user authenticates to the identity or attribute provider as
a returning user with a user ID and a password or some other form of
two-party authentication; we have now made that clear in Section 4.2
of the revised paper. In that case there is no issue-show
We have also made a couple of other improvements to the paper,
motivated in part by the feedback:
We have replaced the word possession with the
word ownership in the definition of closed-loop authentication
(Section 2), so that it now reads: authentication is closed-loop
when the credential authority that issues or registers a credential is
later responsible for verifying ownership of the credential at
authentication time. The motivation for this change is that, in
group 2, the credential is the information that the identity or
attribute provider has about the user, and is thus kept by the
identity or attribute provider rather than by the user.
We have added a distinction between two forms of multishow
unlinkability, a strong form that holds even if the credential
authority colludes and shares information with the relying parties,
and a weak form that holds only if there is no such collusion. The
technologies in group 2 that provide multishow unlinkability provide
the weak form, whereas Idemix anonymous credentials provide the strong