I noticed the open issue quoted below while perusing the diffs of some new
I-Ds today and it reminded me that I'd been meaning to comment on that very
issue.
"Should all claims continue to be required to be understood by
implementations using them when used in a security-related context
or should a means of declaring that specific claims may be safely
ignored if not understood should be defined? This is related to
the similar JOSE issue about whether all header fields must
continue to be understood."
I've been reluctant to weigh in on the similar JOSE discussion for lack of
confidence about the right answer but I do have a lot of experience working
with identity and security type tokens that may be relevant to the issue in
the JWT context. In my experience many consumers of such tokens will
process the special attributes/claims that it knows about (i.e. aud, iss,
exp, etc.) and pass the remaining values to the application layer as (not
necessarily expected but potently useful) additional claims about the
subject. In fact, I recently wrote a JWT/JWS based OAuth access token
implementation that does exactly that (which a colleague of mine
successfully tested with a MS JWT implementation although I don't know what
claims he used).
Maybe that's not the best approach but I believe it's fairly common and, as
such, that must understand requirement in JWT is likely to be ignored by
many, which can result in a neglected spec requirement and/or potential
interoperability issues.
My 2 cents,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
