Function auth_token_to_json 

fn auth_token_to_json(bytes: &[u8]) -> FieldValue

Parse an authorization_token byte value into JSON.

Draft-11 Section 8.2.1.1 Figure 4 gives the Token four fields, three of them optional, with the first deciding which of the others are on the wire:

TOKEN {
  Alias Type (i),
  [Token Alias (i),]
  [Token Type (i),]
  [Token Value (..)]
}

Table 3 spells out which: DELETE (0x0) and USE_ALIAS (0x2) are “an Alias but no Type or Value”, REGISTER (0x1) is “an Alias, a Type and a Value”, and USE_VALUE (0x3) is “no Alias and there is a Type and Value”. So the second varint is the Alias on three of the four forms and the Token Type on one.

So the second varint has to be read against the Alias Type rather than named ahead of it: token_type is its name on USE_VALUE alone, and on the other three forms it is the Alias. crate::auth_token::TokenAliasType is the same table in code, and draft-13’s renderer branches on it the same way.

What a value it cannot read renders as

The raw bytes, as fields::params and every other draft’s renderer do. Field extraction runs on a message that has already decoded, so it has no refusal to give: what a peer sent is what there is to show.

Draft-11 is the one draft where nothing public can hand this a value its own decoder did not already hold to the structure. check_authorization_tokens runs AuthorizationToken::decode over every 0x01 on the way in, and this draft alone keeps the token out of the setup namespace — so setup_option_name, which exists precisely to hand one draft bytes another draft’s peer sent, answers path for a setup 0x01 and never arrives here. The reads are if let anyway, because that guarantee belongs to two functions in a different file and a renderer that panics on the bytes it was handed is wrong whether or not today’s call graph reaches it. Drafts 12 and 13, which moved the token to 0x03 in both namespaces, are where the same unwrap was reachable.