`sub` field

[ym-corey]

In JWT spec and this doc, the sub field is a string. In the provided example, the sub field is a nested json object. Is the idea that this will be a stringified json?

Should this instead be additional claims at the top layer of the JWT obj?

[jaredmoscow]

@ym-corey it seems like there are two options for this.

1. Stringify the JSON object: this structured data could store as a JSON string within sub
   example: "{"identifierValue":"28f6dc889e...fe167","identifierType":"email","identifierFormat":"sha256"}"

2. Use Additional Claims at the Top Level: Instead of embedding structured data within sub, move the relevant fields to separate claims in the JWT payload.
   example:
   "sub": "28f6dc889e...fe167",
   "identifierType": "email",
   "identifierFormat": "sha256"

in this sub probably assumes the role of the current identifier value field? if that is the case, we'd be introducing a breaking change due to claim and payload restructuring.

is there a preferred method?

[lpolya-tl]

@ym-corey @jaredmoscow I would suggest the best way forward is option 1 since it already exists in the spec and I don't believe it goes against the JWT guidelines

[bmayd]

We are discussing updates to the DDRF in the Global Privacy Working Group, among them the sub field definition. Though not final, the consensus is that we want to define the sub claim to be the identifierValue and include identifierType and IdentifierFormat as additional separate claims. A specific reason for this, aside from concerns about normalization, is that it would allow recipients to use the sub claim value directly, without having to parse JSON. So what Jared included as option 2, above:

Use Additional Claims at the Top Level: Instead of embedding structured data within sub, move the relevant fields to separate claims in the JWT payload.
example:
"sub": "28f6dc889e...fe167",
"identifierType": "email",
"identifierFormat": "sha256"