Draft: draft-ietf-privacypass-auth-scheme

Commentary: please have a look ! 
 From   in Vienna . 
 We should also clarify more explicitly how the client uses the origin name field for validating the context it is in . 
 Leaning towards allowing the being able to be a list of hostnames , with comma separation . 
 +1 to csv . We think this keeps the client impl 's simple while allowing for the flexibility of origin sets . 
 Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator ? 
 While I can understand the appeal , I 'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts . 
 perfect !
"origin_name" is an optional string containing the name of the
origin, which allows a token to be scoped to a specific origin.
The string is prefixed with a 2-octet integer indicating the
length, in network byte order.  If empty, any non-origin-specific
token can be redeemed.
"origin_info" is an optional string containing one or more origin
names, which allows a token to be scoped to a specific set of
origins.  The string is 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 contains multiple
origin names, they are delimited with commas "," without any
whitespace.
Origins MAY also include the standard "realm" attribute, if desired.
Issuance protocols MAY require other attributes.
Upon receipt of this challenge, a client uses the message and keys in
the issuance protocol indicated by the token_type.  If the
TokenChallenge has a token_type the client does not recognize or
support, it MUST NOT parse or respond to the challenge.
The header MAY also include the standard "realm" attribute, if
desired.  Issuance protocols MAY require other attributes.
Upon receipt of this challenge, a client uses the message and keys in
the issuance protocol indicated by the token_type.  If the
TokenChallenge has a token_type the client does not recognize or
support, it MUST NOT parse or respond to the challenge.  If the
TokenChallenge contains a non-empty origin_info field, the client
MUST validate that the name of the origin that issued the
authentication challenge is included in the list of origin names.
Clients MAY have further restrictions and requirements around
validating when a challenge is considered acceptable or valid.  For
example, clients can choose to reject challenges that list origin
names for which current connection is not authoritative (according to
the TLS certificate).
Token challenges that include non-empty origin_info bind tokens to
one or more specific origins.  As described in challenge, clients
only accept such challenges from origin names listed in the
origin_info string.  Even if multiple origins are listed, a token can
only be redeemed for an origin if the challenge has an exact match
for the origin_info.  For example, if "a.example.com" issues a
challenge with an origin_info string of
"a.example.com,b.example.com", a client could redeem a token fetched
for this challenge if and only if "b.example.com" also included an
origin_info string of "a.example.com,b.example.com".  On the other
hand, if "b.example.com" had an origin_info string of "b.example.com"
or "b.example.com,a.example.com" or
"a.example.com,b.example.com,c.example.com", the string would not
match and the client would need to use a different token.