| RFC 9577 | Privacy Pass Authentication | June 2024 |
| Pauly, et al. | Standards Track | [Page] |
This document defines an HTTP authentication scheme for Privacy Pass,a privacy-preserving authentication mechanism used for authorization.The authentication scheme specified in this document can be used by Clientsto redeem Privacy Pass tokens with an Origin. It can also be used byOrigins to challenge Clients to present Privacy Pass tokens.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9577.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Privacy Pass tokens are unlinkable authenticators that can be used toanonymously authorize a Client (see[ARCHITECTURE]).Tokens are generated by token Issuers, on the basis of authentication,attestation, or some previous action such as solving a CAPTCHA. A Clientpossessing such a token is able to prove that it was able to get a tokenissued, without allowing the relying party redeeming the Client's token(the Origin) to link it with the issuance flow.¶
Different types of authenticators, using different token issuance protocols,can be used as Privacy Pass tokens.¶
This document defines a common HTTP authentication scheme([HTTP],Section 11), "PrivateToken", that allows Clients to redeem variouskinds of Privacy Pass tokens.¶
Clients and relying parties (Origins) interact using this scheme to perform thetoken challenge and token redemption flow. In particular, Origins challengeClients for a token with an HTTP authentication challenge (using theWWW-Authenticate response header field). Clients can then react to thatchallenge by issuing a new request with a corresponding token (using theAuthorizationrequest header field). Clients generate tokens that match the Origin's tokenchallenge by running one of the token issuance protocols defined in[ISSUANCE]. The act of presenting a token in anAuthorization request header field is referred to as "token redemption". Thisinteraction between the Client and Origin is shown below.¶
In addition to working with different token issuance protocols, this schemeoptionally supports the use of tokens that are associated with Origin-chosencontexts and specific Origin names. Relying parties that request and redeemtokens can choose a specific kind of token, as appropriate for its use case.These options (1) allow for different deployment models to prevent double-spending and (2) allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens.¶
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.¶
Unless otherwise specified, this document encodes protocol messages in TLSnotation from[TLS13],Section 3.¶
This document uses the terms "Client", "Origin", "Issuer", "issuance protocol",and "Token" as defined in[ARCHITECTURE]. It additionallyuses the following terms in more specific ways:¶
WWW-Authenticate HTTP header field. This challenge identifies a specifictoken Issuer and issuance protocol. Token challenges optionally includeone or both of the following: a redemption context (seeSection 2.1.1.2) anda list of associated Origins. These optional values can thenbe bound to the token that is issued.¶Authorization HTTP header field.¶Token redemption is performed using HTTP authentication([HTTP],Section 11), with the scheme "PrivateToken". Origins challengeClients to present a token from a specific Issuer (Section 2.1). Once aClient has received a token from that Issuer or already has a valid tokenavailable, it presents the token to the Origin (Section 2.2). The process ofpresenting a token as authentication to an Origin is also referred toas "spending" a token.¶
In order to prevent linkability across different transactions, Clientswill often present a particular "PrivateToken" only once. Origins can link multipletransactions to the same Client if that Client spends the same token value morethan once. As such, Origins ought to expect at most one unique tokenvalue, carried in one request, for each challenge.¶
The rest of this section describes the token challenge and redemption interactionsin more detail.¶
Origins send a token challenge to Clients in aWWW-Authenticate header fieldwith the "PrivateToken" scheme. This authentication scheme has two mandatory parameters:one containing a token challenge and another containing thetoken-key used forproducing (and verifying) a corresponding token.¶
Origins that support the "PrivateToken" authentication scheme need to handlethe following tasks in constructing theWWW-Authenticate header field:¶
token-key toinclude inWWW-Authenticate token challenges. The Issuer name is included inthe token challenge, and the Issuertoken-key is used to populate theWWW-Authenticate header parameter.¶Once these decisions are made, Origins construct theWWW-Authenticate headerby first constructing the token challenge as described inSection 2.1.1.Origins send challenges as described inSection 2.1.2, and Clients processthem as described in Sections 2.1.3 and2.1.4.¶
This document defines the default challenge structure that can be used acrosstoken types, although future token typesMAY extend or modify the structureof the challenge; seeSection 6.2 for the registry informationthat establishes and defines the relationship betweentoken_type and thecontents of the TokenChallenge message.¶
All token challengesMUST begin with a 2-octet integer that defines thetoken type, in network byte order. This type indicates the issuance protocolused to generate the token and determines the structure and semantics of the rest ofthe structure. Values are registered in an IANA registry; seeSection 6.2. ClientsMUSTignore challenges with token types they do not support.¶
Even when a given token type uses the default challenge structure,the requirements on the presence or interpretation of the fields can differacross token types. For example, some token types might require thatorigin_infois non-empty, while others allow it to be empty.¶
The default TokenChallenge message has the following structure:¶
struct { uint16_t token_type; opaque issuer_name<1..2^16-1>; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>;} TokenChallenge;¶The structure fields are defined as follows:¶
token_type is a 2-octet integer, in network byte order, as describedabove.¶issuer_name is an ASCII string that identifies the Issuer, using the format of aserver name as defined inSection 2.1.1.1. This name identifies the Issuer that is allowed toissue tokens that can be redeemed by this Origin. The field that stores this string in the challengeis prefixed with a 2-octet integer indicating the length, in network byte order.¶redemption_context is a field that is either 0 or 32 bytes, prefixed with a singleoctet indicating the length (either 0 or 32). If the value is non-empty, it is a 32-byte valuegenerated by the Origin that allows the Origin to require that Clients fetch tokensbound to a specific context, as opposed to reusing tokens that were fetched for othercontexts. SeeSection 2.1.1.2 for example contexts that might be useful inpractice. Challenges withredemption_context values of invalid lengthsMUST be ignored.¶origin_info is an ASCII string that either is empty or contains one or moreOrigin names that allow a token to be scoped to a specific set of Origins. EachOrigin name uses the format of a server name as defined inSection 2.1.1.1. The stringis prefixed with a 2-octet integer indicating the length, in network byte order.If empty, any non-Origin-specific token can be redeemed. If the string containsmultiple Origin names, they are delimited with commas (",") without any whitespace.If this field is not empty, the OriginMUST include its own name as one of thenames in the list.¶Iforigin_info contains multiple Origin names, this means the challenge is validfor any of the Origins in the list, including the Origin that issued the challenge(which must always be present in the list if it is non-empty; seeSection 2.1.3).This can be useful in settings where Clients pre-fetch and cache tokens for a particularchallenge -- including theorigin_info field -- and then later redeem these tokenswith one of the Origins in the list. SeeSection 2.1.4 for more discussion abouttoken caching.¶
Server names contained in a token challenge are ASCII strings that contain a hostnameand optional port, where the port is implied to be "443" if missing. The names use theformat of the authority portion of a URI as defined inSection 3.2 of [URI].The namesMUST NOT include a "userinfo" portion of an authority. For example, a validserver name might be "issuer.example.com" or "issuer.example.com:8443",but not "issuer@example.com".¶
The TokenChallenge redemption context allows the Origin to determine thecontext in which a given token can be redeemed. This value can be a uniqueper-request nonce, constructed from 32 freshly generated random bytes. Itcan also represent state or properties of the Client session. Some exampleproperties and methods for constructing the corresponding context are below.This list is not exhaustive.¶
Preventing double-spending on tokens requires the Origin to keep stateassociated with the redemption context. An empty redemption context is notbound to any property of the Client request, so state to prevent double-spendingneeds to be stored and shared across all Origin servers that can accept tokens untiltoken-key expiration or rotation. For a non-empty redemption context, thedouble-spend state only needs to be stored across the set of Origin servers that willaccept tokens with that redemption context.¶
Origins that share redemption contexts, i.e., by using the same redemptioncontext, choosing the same Issuer, and providing the sameorigin_info field inthe TokenChallenge, must necessarily share state required to enforcedouble-spend prevention. Origins should consider the operational complexity of thisshared state before choosing to share redemption contexts. Failure tosuccessfully synchronize this state and use it for double-spend prevention canallow Clients to redeem tokens to one Origin that were issued after aninteraction with another Origin that shares the context.¶
When used in an authentication challenge, the "PrivateToken" scheme uses thefollowing parameters:¶
challenge, which contains a base64url TokenChallenge value, encoded per[RFC4648]. This document follows the default padding behavior described inSection 3.2 of [RFC4648], so the base64url valueMUST include padding.As an authentication parameter (auth-param from[HTTP],Section 11.2),the value can be either a token or a quoted-string and might be required tobe a quoted-string if the base64url string includes "=" characters. Thisparameter is required for all challenges.¶token-key, which contains a base64url encoding of the public key foruse with the issuance protocol indicated by the challenge. See[ISSUANCE]for more information about how this public key is used by the issuance protocolsdescribed in that specification. The encoding ofthe public key is determined by the token type; seeSection 6.2.As withchallenge, the base64url valueMUST include padding. As anauthentication parameter (auth-param from[HTTP],Section 11.2), thevalue can be either a token or a quoted-string and might be required to be aquoted-string if the base64url string includes "=" characters. This parameterMAY be omitted in deployments where Clients are able to retrieve the Issuer keyusing an out-of-band mechanism.¶max-age, which is an optional parameter that consists of the number of seconds forwhich the challenge will be accepted by the Origin.¶The header fieldMAY also include the standardrealm parameter, if desired.Issuance protocolsMAY define other parameters, some of which might be required.ClientsMUST ignore parameters in challenges that are not defined for the issuanceprotocol corresponding to the token type in the challenge.¶
As an example, theWWW-Authenticate header field could look like this:¶
WWW-Authenticate: PrivateToken challenge="abc...", token-key="123..."¶
It is possible for theWWW-Authenticate header field to include multiplechallenges ([HTTP],Section 11.6.1). This allows the Origin to indicatesupport for different token types or different Issuers, or to include multiple redemptioncontexts. For example, theWWW-Authenticate header field could look like this:¶
WWW-Authenticate: PrivateToken challenge="abc...", token-key="123...", PrivateToken challenge="def...", token-key="234..."¶
Origins should only include challenges for different types of issuanceprotocols with functionally equivalent properties. For instance, both issuanceprotocols in[ISSUANCE] have the same functional properties, albeit withdifferent mechanisms for verifying the resulting tokens during redemption.Since Clients are free to choose which challenge they want to consume whenpresented with options, mixing multiple challenges with different functionalproperties for one use case is nonsensical. If the Origin has a preferencefor one challenge over another (for example, if one uses a token typethat is faster to verify), it can sort it to be first in the listof challenges as a hint to the Client.¶
Upon receipt of a challenge, a Client validates the TokenChallenge structurebefore taking any action, such as fetching a new token or redeeming a tokenin a new request. Validation requirements are as follows:¶
token_type is recognized and supported by the Client;¶origin_info field is non-empty, the name of the Origin that issued theauthentication challenge is included in the list of Origin names. Comparisonof the Origin name that issued the authentication challenge against elementsin theorigin_info list is done via case-insensitive equality checks.¶If validation fails, the ClientMUST NOT fetch or redeem a token based on thechallenge. ClientsMAY have further restrictions and requirements aroundvalidating when a challenge is considered acceptable or valid. For example,Clients can choose to ignore challenges that list Origin names for which thecurrent connection is not authoritative (according to the TLS certificate).¶
Caching and pre-fetching of tokens are discussed inSection 2.1.4.¶
Clients can generate multiple tokens from a single TokenChallenge and cachethem for future use. This improves privacy by separating the time of tokenissuance from the time of token redemption, and also allows Clients to avoidthe overhead of receiving new tokens via the issuance protocol.¶
Cached tokens can only be redeemed when they match all of the fields in theTokenChallenge:token_type,issuer_name,redemption_context, andorigin_info.Clients ought to store cached tokens based on all of these fields, toavoid trying to redeem a token that does not match. Note that each tokenhas a unique Client nonce, which is sent in token redemption (Section 2.2).¶
If a Client fetches a batch of multiple tokens for future use that are boundto a specific redemption context (theredemption_context in the TokenChallengewas not empty), ClientsSHOULD discard these tokens upon flushing state such asHTTP cookies[COOKIES], or if there is a networkchange and the Client does not have any Origin-specific state like HTTP cookies.Using these tokens in a context that otherwise would not be linkable to theoriginal context could allow the Origin to recognize a Client.¶
The output of the issuance protocol is a token that corresponds to the Origin'schallenge (seeSection 2.1).¶
A token is a structure that begins with a 2-octet field that indicates a tokentype, whichMUST match thetoken_type in the TokenChallenge structure. This valuedetermines the structure and semantics of the rest of the token structure.¶
This document defines the default token structure that can be used acrosstoken types, although future token typesMAY extend or modify the structureof the token; seeSection 6.2 for the registry information thatestablishes and defines the relationship betweentoken_type and the contentsof the token structure.¶
The default token message has the following structure:¶
struct { uint16_t token_type; uint8_t nonce[32]; uint8_t challenge_digest[32]; uint8_t token_key_id[Nid]; uint8_t authenticator[Nk];} Token;¶The structure fields are defined as follows:¶
token_type is a 2-octet integer, in network byte order, as describedabove.¶nonce is a 32-octet value containing a Client-generated random nonce.¶challenge_digest is a 32-octet value containing the hash of theoriginal TokenChallenge, SHA-256(TokenChallenge), where SHA-256 is as definedin[SHS]. Changing the hash function to somethingother than SHA-256 would require defining a new token type and token structure(since the contents ofchallenge_digest would be computed differently),which can be done in a future specification.¶token_key_id is a Nid-octet identifier for the token authenticationkey. The value of this field is defined by thetoken_type and correspondingissuance protocol.¶authenticator is a Nk-octet authenticator that is cryptographically boundto the preceding fields in the token; seeSection 2.2.3 for more informationabout how this field is used in verifying a token. Thetoken_type and correspondingissuance protocol determine the value of theauthenticator field and how it is computed.The value of constant Nk depends ontoken_type, as defined inSection 6.2.¶Theauthenticator value in the token structure is computed over thetoken_type,nonce,challenge_digest, andtoken_key_id fields. A token is considered validif token verification succeeds; seeSection 2.2.3 for details aboutverifying the token and itsauthenticator value.¶
When used for Client authorization, the "PrivateToken" authenticationscheme defines one parameter,token, which contains the base64url-encodedtoken structure. As with the challenge parameters (Section 2.1), the base64urlvalueMUST include padding. As an authentication parameter (auth-param from[HTTP],Section 11.2), the value can be either a token or aquoted-string and might be required to be a quoted-string if the base64urlstring includes "=" characters. All unknown or unsupported parameters to"PrivateToken" authentication credentialsMUST be ignored.¶
Clients present this token structure to Origins in a new HTTP request usingtheAuthorization header field as follows:¶
Authorization: PrivateToken token="abc..."¶
For context-bound tokens, Origins store or reconstruct the contexts of previousTokenChallenge structures in order to validate the token. A TokenChallenge canbe bound to a specific TLS session with a Client, but Origins can also accepttokens for valid challenges in new sessions. OriginsSHOULD implement some formof double-spend prevention that prevents a token with the same nonce from beingredeemed twice. Double-spend prevention ensures that Clients cannot replay tokensfor previous challenges. SeeSection 5.2 for more information about replayattacks. For context-bound tokens, this double-spend prevention can require no stateor minimal state, since the context can be used to verify token uniqueness.¶
A token consists of some input cryptographically bound to anauthenticatorvalue, such as a digital signature. Verifying a token consists of checking thattheauthenticator value is correct.¶
Theauthenticator value is as computed when running and finalizing the issuanceprotocol corresponding to the token type with the following values as the input:¶
struct { uint16_t token_type; uint8_t nonce[32]; uint8_t challenge_digest[32]; uint8_t token_key_id[Nid];} AuthenticatorInput;¶The values of these fields are as described inSection 2.2.1. The cryptographicverification check depends on the token type; seeSections 5.4 and6.4 of[ISSUANCE] for verification instructions for the issuanceprotocols described in that specification. As such, the security properties of thetoken, e.g., the probability that one can forge anauthenticator value withoutinvoking the issuance protocol, depend on the cryptographic algorithm used bythe issuance protocol as determined by the token type.¶
When a Client receives one or more token challenges in response to a request,the Client has a set of choices to make:¶
The approach to these choices depends on the use case of the application, aswell as the deployment model (seeSection 4 of [ARCHITECTURE] for discussionof the different deployment models).¶
Some applications of tokens might require Clients to always present a tokenas authentication in order to successfully make requests. For example, a restrictedservice that wants to only allow access to valid users but wants to do so without learningspecific user credential information could use tokens that are based on attesting usercredentials. In these kinds of use cases, Clients will need to always redeem atoken in order to successfully make a request.¶
Many other use cases for Privacy Pass tokens involve open services that must workwith any Client, including those that either cannot redeem tokens or can only sometimes redeemtokens. For example, a service can use tokens as a way to reduce the incidence ofpresenting CAPTCHAs to users. In such use cases, services will regularly encounterClients that cannot redeem a token or choose not to. In order to mitigate the riskof these services relying on always receiving tokens, Clients that are capable ofredeeming tokens can ignore token challenges (and instead behave as if they were a Clientthat either doesn't support redeeming tokens or is unable to generate a new token, by notsending a new request that contains a token to redeem) with somenon-trivial probability. SeeSection 5.1 of [ARCHITECTURE] for further considerationsregarding avoiding discriminatory behavior across Clients when using Privacy Pass tokens.¶
Clients might also choose to not redeem tokens in subsequent requests when thetoken challenges indicate erroneous or malicious behavior on the part of thechallenging Origin. For example, if a Client's ability to generate tokens via anAttester and Issuer is limited to a certain rate, a malicious Origin could sendan excessive number of token challenges with unique redemption contextsin order to (1) cause the Client to exhaust its ability to generate new tokens or (2) overwhelm issuance servers. Based on the specific deployment, the limits here will vary, but ClientsSHOULD have some implementation-specific policy to minimize the number of tokens that can be retrieved by Origins.¶
A single response from an Origin can include multiple token challenges.For example, a set of challenges could include different token typesand Issuers, to allow Clients to choose a preferred Issuer or type.¶
If Clients choose to respond, Clients should satisfy exactly one ofthe challenges presented. The choice of which challenge to use for redeemingtokens is up to Client policy. This can involve which token types aresupported or preferred, which Issuers are supported or preferred, or whetheror not the Client is able to use cached tokens based on the redemption contextor Origin information in the challenge. SeeSection 2.1.4 for more discussionon token caching. Regardless of how the choice is made, itSHOULD be done in aconsistent manner to ensure that the choice does not reveal information about thespecific Client; seeSection 6.2 of [ARCHITECTURE] for more details on the privacyimplications of issuance consistency.¶
Origins choose what token challenges to send to Clients; these token challenges will vary,depending on the use case and deployment model. The Origin chooseswhich token types, Issuers, redemption contexts, and Origin information to includein challenges. If an Origin sends multiple challenges, each challengeSHOULDbe equivalent in terms of acceptability for token redemption, since Clientsare free to choose to generate tokens based on any of the challenges.¶
Origins ought to consider the time involved in token issuance. Particularly,a challenge that includes a unique redemption context will prevent a Clientfrom using cached tokens and thus can add more delay before the Clientis able to redeem a token.¶
OriginsSHOULD minimize the number of challenges sent to a particular Clientcontext (referred to as the "redemption context" inSection 3.3 of [ARCHITECTURE]), to avoid overwhelming Clients and Issuerswith token requests that might cause Clients to hit rate limits.¶
In order to prevent Clients from becoming incompatible with new token challenges,OriginsSHOULD include random token types, from the reserved list of "greased"types (defined inSection 6.2), with some non-trivial probability.¶
Additionally, for deployments where tokens are not required (such as when tokensare used as a way to avoid showing CAPTCHAs), OriginsSHOULD randomlychoose to not challenge Clients for tokens with some non-trivial probability.This helps Origins ensure that their behavior for handling Clients that cannotredeem tokens is maintained and exercised consistently.¶
This section contains security considerations for the "PrivateToken" authenticationscheme described in this document.¶
All random values in the challenge and tokenMUST begenerated using a cryptographically secure source of randomness[RFC4086].¶
ApplicationsSHOULD constrain tokens to a single Origin unless the use case canaccommodate replay attacks. Replaying tokens is not necessarily a securityor privacy problem. As an example, it is reasonable for Clients to replay tokensin contexts where token redemption does not induce side effects and in whichClient requests are already linkable. One possible setting where this appliesis where tokens are sent as part of 0-RTT data.¶
If successful token redemption produces side effects, OriginsSHOULD implement ananti-replay mechanism to mitigate the harm of such replays. See[TLS13],Section 8and[RFC9001],Section 9.2 for details about anti-replay mechanisms, as well as[RFC8470],Section 3 for discussion about safety considerations for 0-RTTHTTP data.¶
The security properties of token challenges vary, depending on whether thechallenge contains a redemption context or not, as well as whether thechallenge is a per-Origin challenge or not. For example, cross-Origin tokens with emptycontexts can be reflected from one party by another, as shown below.¶
When a Client holds cross-Origin tokens with empty contexts, itis possible for any Origin in the cross-Origin set to deplete that Client'sset of tokens. To prevent this from happening, tokens can be scoped to singleOrigins (with non-emptyorigin_info) such that they can only be redeemed fora single Origin. Alternatively, if tokens are cross-Origin tokens, Clients can usealternate methods to prevent many tokens from being redeemed at once. Forexample, if the Origin requests an excess of tokens, the Client could choose tonot present any tokens for verification if a redemption had alreadyoccurred in a given time window.¶
Token challenges that include non-emptyorigin_info bind tokens to one or morespecific Origins. As described inSection 2.1.3, Clients only accept suchchallenges from Origin names listed in theorigin_info string if it is non-empty. Even if multipleOrigins are listed, a token can only be redeemed for an Origin if the challengehas a match for theorigin_info. For example, if "a.example.com" issuesa challenge with anorigin_info string of "a.example.com,b.example.com", aClient could redeem a token fetched for this challenge if and only if"b.example.com" also included anorigin_info string of"a.example.com,b.example.com". On the other hand, if "b.example.com" had anorigin_info string of "b.example.com", "b.example.com,a.example.com", or"a.example.com,b.example.com,c.example.com", the string would not match, and theClient would need to use a different token.¶
Context-bound token challenges require Clients to obtain matching tokens whenchallenged, rather than presenting a token that was obtained from a differentcontext in the past. This can make it more likely that issuance and redemptionevents will occur at approximately the same time. For example, if a Client ischallenged for a token with a unique context at time T1 and then subsequentlyobtains a token at time T2, a colluding Issuer and Origin can link this to thesame Client if T2 is unique to the Client. This linkability is less feasible asthe number of issuance events at time T2 increases. Depending on themax-agetoken challenge parameter, ClientsMAY try to add delay to the time betweenbeing challenged and redeeming a token to make this sort of linkability moredifficult. For more discussion on correlation risks between token issuance andredemption, seeSection 6.3 of [ARCHITECTURE].¶
As discussed inSection 2.1, ClientsSHOULD discard any context-bound tokensupon flushing cookies or changing networks, to prevent an Origin from using theredemption context state as a cookie to recognize Clients.¶
IANA has registered the "PrivateToken" authentication scheme in the"HTTP Authentication Schemes" subregistry of the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" as definedin[HTTP],Section 16.4.¶
IANA has created a new "Privacy Pass Token Types" registry in a new"Privacy Pass" page to list identifiers for issuance protocolsdefined for use with the Privacy Pass token authentication scheme. Theseidentifiers are 2-byte values, so the maximum possible value is0xFFFF = 65535.¶
New registrations need to list the following attributes:¶
token-key parameter; seeSection 2.1.2.¶New entries in this registry are subject to the Specification Requiredregistration policy ([RFC8126],Section 4.6). Designated experts need toensure that the token type is defined to be used for both token issuance andredemption. Additionally, the experts can reject registrations on the basisthat they do not meet the security and privacy requirements for issuanceprotocols defined inSection 3.2 of [ARCHITECTURE].¶
[ISSUANCE] defines entries for this registry.¶
This document defines several reserved values, which can be used by Clientsand servers to send "greased" values in token challenges and redemptions toensure that implementations remain able to handle unknown token typesgracefully (this technique is inspired by[RFC8701]). ImplementationsSHOULDselect reserved values at random when including them in greased messages.Servers can include these in TokenChallenge structures, either as the onlychallenge when no real token type is desired or as one challenge in a list ofchallenges that include real values. Clients can include these in tokenstructures when they are not able to present a real token. Thecontents of the token structureSHOULD be filled with random bytes whenusing greased values.¶
The initial contents of this registry consist of multiple reserved values,with the following attributes, which are repeated for each registration:¶
This section includes test vectors for the HTTP authentication scheme specifiedin this document. It consists of the following types of test vectors:¶
token-key andmax-age values.¶This section includes test vectors for the challenge and redemptionfunctionalities described in Sections 2.1 and2.2. Each test vectorlists the following values:¶
token_type:token_type is0x0002, correspondingto the issuance protocol discussed in Section6 ("Issuance Protocol for Publicly Verifiable Tokens") of[ISSUANCE].¶issuer_name:redemption_context:origin_info:nonce:token_key_id:token_authenticator_input:Test vectors are provided for each of the following TokenChallengeconfigurations:¶
These test vectors are below.¶
// Test vector 1:// token_type(0002), issuer_name(issuer.example),// origin_info(origin.example), redemption_context(non-empty)token_type: 0002issuer_name: 6973737565722e6578616d706c65redemption_context:476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bborigin_info: 6f726967696e2e6578616d706c65nonce:e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababtoken_key_id:ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708token_authenticator_input: 0002e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab8e1d5518ec82964255526efd8f9db88205a8ddd3ffb1db298fcc3ad36c42388fca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708// Test vector 2:// token_type(0002), issuer_name(issuer.example),// origin_info(origin.example), redemption_context(empty)token_type: 0002issuer_name: 6973737565722e6578616d706c65redemption_context:origin_info: 6f726967696e2e6578616d706c65nonce:e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababtoken_key_id:ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708token_authenticator_input: 0002e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688abab11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708// Test vector 3:// token_type(0002), issuer_name(issuer.example),// origin_info(), redemption_context(empty)token_type: 0002issuer_name: 6973737565722e6578616d706c65redemption_context:origin_info:nonce:e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababtoken_key_id:ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708token_authenticator_input: 0002e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababb741ec1b6fd05f1e95f8982906aec1612896d9ca97d53eef94ad3c9fe023f7a4ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708// Test vector 4:// token_type(0002), issuer_name(issuer.example),// origin_info(), redemption_context(non-empty)token_type: 0002issuer_name: 6973737565722e6578616d706c65redemption_context:476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bborigin_info:nonce:e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababtoken_key_id:ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708token_authenticator_input: 0002e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababb85fb5bc06edeb0e8e8bdb5b3bea8c4fa40837c82e8bcaf5882c81e14817ea18ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708// Test vector 5:// token_type(0002), issuer_name(issuer.example),// origin_info(foo.example,bar.example),// redemption_context(non-empty)token_type: 0002issuer_name: 6973737565722e6578616d706c65redemption_context:476ac2c935f458e9b2d7af32dacfbd22dd6023ef5887a789f1abe004e79bb5bborigin_info: 666f6f2e6578616d706c652c6261722e6578616d706c65nonce:e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababtoken_key_id:ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708token_authenticator_input: 0002e01978182c469e5e026d66558ee186568614f235e41ef7e2378e6f202688ababa2a775866b6ae0f98944910c8f48728d8a2735b9157762ddbf803f70e2e8ba3eca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd2708// Test vector 6:// token_type(0000), structure(random_bytes)token_type: 0000token_authenticator_input: 000058405ad31e286e874cb42d0ef9d50461ae703bb71a21178beb429c43c0effe587456d856f0f2bdfc216ef93d5c225e2a93e84cb686e63919788087f7ab1054aa817f09dcb919a0ed6f90fe887e8b08cd1eee44d5be8d813eda9f2656db61c932db8d73f8690604ded0120157923bbd19d5549e639e4de07530aee1d370f5187b678685715bd878dde24346751eb532a87b71ea40bbe5a13218658e303c648eb03817453690bfcbe8255081bf27ff0891cd02ee2483e48a2c494bdef696f943fa992a65303292c25d0d3f62da86a70d0b020f0ff5b90d0ff0f6abdb097d321fde04f3a1994e63bcd35a88c21236c7dc67600482223f54b25e39a250439f27ecb5ae9eb8ed548a3ec1f1d6f510d08281929c8fe088342959e35ea9b3b6f6a96fc1a8edba4ed297f4cf02d0e4482b79a11f671745d7b7db120eddd8a4c2b6501bbc895b2160b8071615d9c1b18f32e056bfee29deac6a7d6cf7b522a5badd63b9cb¶
This section includes test vectors for the contents of the HTTP authenticationheaders. Each test vector consists of one or more challenges that compriseaWWW-Authenticate header; seeSection 3.2.For each challenge, the token-type,token-key,max-age, andtoken-challengeparameters are listed. Each challenge also includes an unknown (unspecified)parameter that implementations are meant to ignore.¶
The parameters for each challenge are indexed by their positionin theWWW-Authenticate challenge list. For example,token-key-0 denotesthetoken-key parameter for the first challenge in the list, whereastoken-key-1 denotes thetoken-key for the second challenge in the list.¶
The resulting wire-encodedWWW-Authenticate header based on thislist of challenges is then listed at the end. Line folding is onlyused to fit the document-formatting constraints and is not supportedin actual requests.¶
The last challenge in this list includes Basic authentication, a greasechallenge, and a valid challenge for token type0x0001. Correct Clientimplementations will ignore the Basic and grease challenges.¶
token-type-0: 0x0002token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b0609608648016503040202a11a301806092a864886f70d010108300b0609608648016503040202a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7e225a5f0203010001max-age-0: 10token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d98005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696e2e6578616d706c65WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM_KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWiJNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtSbvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDhCRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknownChallengeAttribute="ignore-me", max-age="10"token-type-0: 0x0002token-key-0: 30820152303d06092a864886f70d01010a3030a00d300b0609608648016503040202a11a301806092a864886f70d010108300b0609608648016503040202a2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c500a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce453b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c732db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073fe49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9babd612d03cad02db134b7e225a5f0203010001max-age-0: 10token-challenge-0: 0002000e6973737565722e6578616d706c65208a3e83a33d98005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696e2e6578616d706c65token-type-1: 0x0001token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a53fabd489fac0f82bca86249a668f3a5bfab374c9max-age-1: 10token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d98005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696e2e6578616d706c65WWW-Authenticate: PrivateToken challenge="AAIADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM_KsluUsuZKIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi7pA1I-beWiJNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwyB6vGvcte155T8mKMTknaHl1fORTtSbvm_bOuZl5uEI7kPRGGiKvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE7KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0zq0mTCBz_kl0DAHwDhCRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo1Kpur1hLQPK0C2xNLfiJaXwIDAQAB",unknownChallengeAttribute="ignore-me", max-age="10", PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ignore-me", max-age="10"token-type-0: 0x0000token-key-0: 856de3c710b892e7cca1ae5eb121af42ca8e779137a11224228c9b99b0729bf84d5057d030000309b8f0d06ccffa17561f9eacd4c312e985a6bc60ffbea0610264dcb1726255313da81d665692686a1d8644f1516bf612cea009e6dff6d9a9a959fb538e1b5b2343c092992942382bdde22d5b324b1e4618ed21d7806286c2cetoken-challenge-0: 0000acc3b25795c636fd9dd8b12982394abba8777d35978e877fc8848892a217233045ac25a3d55c07c54efe6372973fee0073e77fc61bf19ab880f20edf5d627502token-type-1: 0x0001token-key-1: ebb1fed338310361c08d0c7576969671296e05e99a17d7926dfc28a53fabd489fac0f82bca86249a668f3a5bfab374c9max-age-1: 10token-challenge-1: 0001000e6973737565722e6578616d706c65208a3e83a33d98005d2f30bef419fa6bf4cd5c6005e36b1285bbb4ccd40fa4b383000e6f726967696e2e6578616d706c65WWW-Authenticate: Basic realm="grease", PrivateToken challenge="AACsw7JXlcY2_Z3YsSmCOUq7qHd9NZeOh3_IhIiSohcjMEWsJaPVXAfFTv5jcpc_7gBz53_GG_GauIDyDt9dYnUC", token-key="hW3jxxC4kufMoa5esSGvQsqOd5E3oRIkIoybmbBym_hNUFfQMAADCbjw0GzP-hdWH56s1MMS6YWmvGD_vqBhAmTcsXJiVTE9qB1mVpJoah2GRPFRa_YSzqAJ5t_22ampWftTjhtbI0PAkpkpQjgr3eItWzJLHkYY7SHXgGKGws4=",PrivateToken challenge="AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mABdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsZQ==", token-key="67H-0zgxA2HAjQx1dpaWcSluBemaF9eSbfwopT-r1In6wPgryoYkmmaPOlv6s3TJ",unknownChallengeAttribute="ignore-me", max-age="10"¶