Draft: draft-ietf-privacypass-protocol

Commentary: introduces a token challenge instead of the token challenge digest , but the hex string seems to be missing in the test vector . 
 The of the issuance protocol draft is just too wide for this format . Consider using a definition list instead , transposing the table , or finding a way to remove columns . 
 A list would be better , yeah . We discussed this briefly in . 
 Fixed in 
 If you have no intention of abiding by line length limits , maybe disable the warnings . I can fill my 100 - line terminal many times over with the output of building these drafts . Some of these are genuine problems , but there is too much noise to work out which is which . 
 Fixed in . 
 I count 77 columns for the second line of the example in Section 3 : 
 This has been fixed in .
Issuer Request URI: A token request URL for generating access
tokens.  For example, an Issuer URL might be
https://issuer.example.net/example-token-request.  This parameter
uses resource media type "text/plain".
Issuer Request URI: A token request URL for generating access
tokens.  For example, an Issuer URL might be
https://issuer.example.net/request.  This parameter uses resource
media type "text/plain".
The TokenRequest.truncated_token_key_id corresponds to the
truncated key ID of a Public Key owned by the issuer.
The TokenRequest.truncated_token_key_id corresponds to the
truncated key ID of an Issuer Public Key.
Verifying a Token requires checking that Token.authenticator is a
valid signature over the remainder of the token input using the
Issuer Public Key. The function "RSASSA-PSS-VERIFY" is defined in
Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1
with SHA-384 as the PSS mask generation function (MGF), and a 48-byte
salt length (sLen).
Verifying a Token requires checking that Token.authenticator is a
valid signature over the remainder of the token input using the
Issuer Public Key.  The function "RSASSA-PSS-VERIFY" is defined in
Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1
with SHA-384 as the PSS mask generation function (MGF), and a 48-byte
salt length (sLen).
This document updates the "Token Type" Registry from AUTHSCHEME,
Section 5.2 with the following values.
This document updates the "Token Type" Registry from AUTHSCHEME,
Section 5.2 with the following entries.
issuance and redemption, see I-D.ietf-privacypass-architecture.
issuance and redemption, see ARCHITECTURE.
Additionally, the registry is to be initialized with the following
entry for Private Use.
The privacypass working group is working on HTTP-Authentication as an
instantiation of a redemption protocol and ISSUANCE as an
instantiation of the issuance protocol.
The privacypass working group is working on AUTHSCHEME as an
instantiation of a redemption protocol and ISSUANCE as an
instantiation of the issuance protocol.
Redemption context.  Tokens can be bound to a given redemption
context, which influences a client's ability to pre-fetch and
cache tokens.  For example, an empty redemption context always
allows tokens to be issued and redeemed non-interactively, whereas
a fresh and random redemption context means that the redeemed
token must be issued only after the client receives the challenge.
See Section 2.1.1 of HTTP-Authentication for more details.
Redemption context.  Tokens can be bound to a given redemption
context, which influences a client's ability to pre-fetch and
cache tokens.  For example, an empty redemption context always
allows tokens to be issued and redeemed non-interactively, whereas
a fresh and random redemption context means that the redeemed
token must be issued only after the client receives the challenge.
See Section 2.1.1 of AUTHSCHEME for more details.
Origins that admit cross-Origin tokens bear some risk of allowing
tokens issued for one Origin to be spent in an interaction with
another Origin.  In particular, depending on the use case, Origins
may need to maintain state to track redeemed tokens.  For example,
Origins that accept cross-Origin tokens across shared redemption
contexts SHOULD track which tokens have been redeemed already in
those redemption contexts, since these tokens can be issued and then
spent multiple times in response to any such challenge.  See
Section 2.1.1 of HTTP-Authentication for discussion.
Origins that admit cross-Origin tokens bear some risk of allowing
tokens issued for one Origin to be spent in an interaction with
another Origin.  In particular, depending on the use case, Origins
may need to maintain state to track redeemed tokens.  For example,
Origins that accept cross-Origin tokens across shared redemption
contexts SHOULD track which tokens have been redeemed already in
those redemption contexts, since these tokens can be issued and then
spent multiple times in response to any such challenge.  See
Section 2.1.1 of AUTHSCHEME for discussion.
Clients initiate the issuance protocol using the challenge, a
randomly generated nonce, and public key for the Issuer, all of which
are the Client's private input to the protocol and ultimately bound
to an output Token; see Section 2.2. of HTTP-Authentication for
details.  Future specifications may change or extend the Client's
input to the issuance protocol to produce Tokens with a different
structure.
Clients initiate the issuance protocol using the challenge, a
randomly generated nonce, and public key for the Issuer, all of which
are the Client's private input to the protocol and ultimately bound
to an output Token; see Section 2.2. of AUTHSCHEME for details.
Future specifications may change or extend the Client's input to the
issuance protocol to produce Tokens with a different structure.
Clients obtain the Issuer public key directly from the Origin using
the process described in HTTP-Authentication.  Clients MAY apply some
form of key consistency check to determine if this public key is
consistent and correct for the specified Issuer.  See CONSISTENCY for
example mechanisms.  Depending on the deployment, the Attester might
assist the Client in applying these consistency checks across
clients.
Clients obtain the Issuer public key directly from the Origin using
the process described in AUTHSCHEME.  Clients MAY apply some form of
key consistency check to determine if this public key is consistent
and correct for the specified Issuer.  See CONSISTENCY for example
mechanisms.  Depending on the deployment, the Attester might assist
the Client in applying these consistency checks across clients.