<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">JWT-05 Section 6 defines the following rule for validating JWTs.<div><br></div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Courier; ">6. When used in a security-related context, the Decoded JWT Claim</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Courier; "> Segment MUST be validated to only include claims whose syntax</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Courier; "> and semantics are both understood and supported.</div></blockquote><br></div><div>The way I interpret this, it would mean that introducing new claims in a schema may be a risky business, because consumers according to the spec should reject the whole JWT even if only a single claim is 'unknown'.</div><div><br></div><div>The same problems may be seen in other parts of the spec where JWTs are used, where the members/claims are likely to get additions; or provider-specific values.</div><div><br></div><div>One way this could be dealt with, would be to have kind of a negotiation of what claims are supported, through metadata. (see my other posts about metadata, giving an example of this).</div><div><br></div><div>Andreas</div></body></html>