| Internet-Draft | pseudonym credential | August 2020 |
| Miller | Expires 25 February 2021 | [Page] |
User authentication and attributes are exchanged online today between organizations based on bilateral business arrangements, with user consent and privacy provided as desired by the organization(s) involved.¶
Multipass is a system intended for an organization to issue credentials unilaterally, where other organizations can evaluate credentials without having a relationship to the issuing party. This is accomplished by leveraging a software agent, which allows this exchange to be done in a manner that is able to respect user privacy and support informed decisions around disclosure.¶
This specification provides a mechanism and credential format for creating a privacy preserving pseudonym that is unique to each combination of a verifier, subject, and issuer. It builds upon techniques used in Privacy Pass [PrivacyPass] and provides a mechanism for secure account linking and recovery with user consent.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 February 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Multipass describes a process for retrieving and handling a set of credentials from a single issuer, known as a Multipass Container. These containers are single use, cryptographically verifiable statements by a particular issuer, containing or referencing credentials of various types - representing subject attributes, authentication, and authorization. Multipass also defines mechanisms to prove possession of a key associated with the container to the verifier, and for verifying the credentials were asserted by the issuer.¶
This specification describes the data expected in a request by a holder for a particular type of pseudonym credential, the process to be performed by the holder during a presentation request, as well as the cryptographic format of the resulting presentation back to the verifier.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings.¶
Certain security-related terms are to be understood in the sense defined in [SECURITY]. These terms may include, but are not limited to, "air gap", "anonymity", "assymmetric cryptography", "attribute", "authentication", "authorization", "certificate", "challenge-response", "credential", "data integrity", "domain", "domain name", "enclave", "encryption", "ephemeral key", "expire", "fresh", "identifier", "identity", "identity proofing", "integrity", "privacy", "private key", "proof-of-possession", "protocol", "public key", "repudiation", "sign", "signature", "single sign-on", "steganography", "trust", "validate", "validity period", "verify", and "zero-knowledge proof"¶
Unless otherwise noted, all the protocol parameter names and values are case sensitive.¶
This specification also leverages the terms and roles defined in [draft-waite-multipass-retrieval]¶
Most credentials are created around one or more specific attributes relating to a subject, they are a mechanism of conveying attribute information in some form. A pseudonym credential is different in that it is unrelated to any other existing attributes, it instead enables the subject to generate a pairwise pseudonym unique to the verifier on demand. This value will be consistent for a single subject across the lifetime of their relationship with the issuer and to the given verifier.¶
The primary purpose of this pseudonym credential is to support the creation of a new account on a verifier by relying on the subject's relationship with an external issuer, similar to typical social login systems but with significant added privacy. A key part of such functionality is the ability to recover access to the verifier account, which is satisified here by providing a new pseudonym credential that can be used to proove association with the same pseudonym.¶
Privacy Pass [PrivacyPass] was created as a cryptographic solution for distributing one-time use tokens securely while also protecting the privacy of the token holder from being uniquely tracked and correlated as they use multiple tokens. A key part of that solution introduces a "discrete logarithm equivalence proof" or DLEQ proof that is used to ensure no hidden tracking is embedded in the tokens.¶
The DLEQ proof is adapted to this specification to construct secure and privacy preserving pairwise pseudonym credentials. We leverage this to allow offline generation of a verifiable pseudonym by the holder without requiring new interactions with the issuer. With verifiability, the subject is prevented from generating multiple pseudonyms in an attempt to represent themselves as any number of unique shadow or puppet accounts to a verifier.¶
Leaking of the shared secret 'u' does not allow another party to impersonate the subject unless the issuer is compromised as well. However, a known value of 'u' allows for a verifier to determine the subject's pseudonym for any given rpid.¶
Unvalidated use of a rpid allows one party to ask for the pseudonym of another party. It is possible that a wallet will not be able to confirm the calling verifier due to issues such as insufficient platform capabilities in which case an alternative would be for the RPID to be converted to a resolvable JWKS endpoint, which could then be used to encrypt the message to the verifier service.¶
It is also possible that there would be insufficient information to determine a RPID due to offline usage, in which case the subject may need to be adequately informed and consent to unvalidated usage as a fall-back mechanism.¶
If the issuer can observe value uR, it can attempt to correlate this value by calculating uR against all known values of 'u' across its user accounts. When exposing user identity, the value should not be based solely on uR and public information on the issuer.¶
For this reason it is recommended that the value uR (or some derivative of uR) is persisted in secret, used solely for account recovery purposes. If public user identifiers are derived from uR, the process should also involve a persistent secret to prevent issuer correlation.¶
The issuer must give the holder a message containing three values: 1. A randomly generated elliptic curve point 'P' 1. A correlation secret shared between the issuer and the user, 'u' 1. The combination of the point and secret, 'uP'¶
The values P and uP are sent signed by the issuer against an advertised public key. This forms a one time use pseudonym token, and is expected to be bundled into the one-time-use claims token.¶
When the holder wishes to expose a pseudonym with a particular verifier, it calculates a verifier point R. This value is stable, based on the requested value "rpid", hashed to a curve point. This verifier identifier should be unique to a verifier, such as being the scheme and host name of a website, either directly or indirectly through a trust relationship with a particular application. It is expected that this value has the same semantics as WebAuthn, and is the HTTP/HTTPS origin URL of the requesting website. 1. The client will verify the "rpid" is appropriate for the verifier and hash the value to a point on the curve R 1. The client will calculate value uR 1. The client will calculate the (c,s) values for the ZK-DLEQ(R:uR == P:uP) 1. The client communicates uR, c, s, and the signed message from the issuer containing P and uP with the verifier 1. The verifier uses its own derivation of R from rpid, the points uR, P and uP, and the DLEQ proof (c,s) to verify uR is using the same secret value as uP 1. Point uR and the issuer identity are used together as stable, unique identifier by the verifier.¶
Lorem ipsum dolor sit amet.¶
Lorem ipsum dolor sit amet.¶
Lorem ipsum dolor sit amet.¶
Lorem ipsum dolor sit amet.¶
Lorem ipsum dolor sit amet.¶
Lorem ipsum dolor sit amet.¶