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