Tie the WWW-Authenticate around the keys and max-age.

[dvorak42]

Currently the issuer-key, token-key, and max-age are not versioned inside the WWW-Authenticate, meaning that either we need current parsing of a scheme to ignore unknown fields in the scheme challenge (the outermost layer defined in RFC7235), we have to introspect the challenge field to then figure out how to parse the outer keys/max-age fields, or we have to use a different scheme name whenever we want to change those.

One potential fix is to encapsulate the whole blob of data in an "outer" challenge structure:

struct {
    uint8_t version;
    TokenChallenge token_challenge;
    opaque issuer_key<1..2^16-1>;
    opaque token_key<1..2^16-1>;
    uint32_t max_age;
} PATAuthenticateChallenge;

WWW-Authenticate: PrivateAccessToken challenge=abc..., PrivateAccessToken challenge=def...

Where abc/def are PATAuthenticateChallenge(s).

Additionally we can potentially rename TokenChallenge to get rid of the extra layering.

[tfpauly]

In general, I'd like to keep the keys and max-age fields separate.

However, there are things in a generic token model that need to be specified that we should consider:

• What crypto / algorithms are used for the token? RSA blind signatures in this case...
• What is the meaning of the token? Per-origin rate-limited, generic non-limited, geo-based, etc.

[tfpauly]

Type could be -> Issuance Protocol

[chris-wood]

There seems to be a hierarchy of "things", including the scheme, issuance protocol, and issuance protocol details. It seems to make sense if we arrange things in the following way:

• Scheme: generic anonymous credential authentication
• Issuance protocol (type): PAT or PrivacyPass or whatever
• Issuance protocol details (version? algorithm?) : Blind RSA or POPRF or whatever

Ideally, also, the challenge is bound to the scheme, issuance protocol, and issuance protocol details, which would require some changes. Is this a useful framing?