Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Of course, there is already a “typ” claim.  Its use is optional, since whether it’s needed is application-specific.

Your suggestion that we issue general-purpose JWT guidance about iss/aud namespaces is exactly the kind of thing that’s beyond the scope of this working group, per my just-sent reply to Marius.  Suggesting that applications use the “events” claim to distinguish between SETs and other kinds of JWTs is within the scope of this working group, because it is advice about using SETs.

                                                       -- Mike

From: William Denniss [mailto:wdenniss@google.com]
Sent: Wednesday, March 1, 2017 4:00 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: Phil Hunt (IDM) <phil.hunt@oracle.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

If JWT had a "typ" field all along, this entire discussion could be avoided, but it's too late for that now. I believe that this was actually the founding reason behind standardizing SET, introducing the "events" claim. At least, to avoid the 3+ versions of event-on-JWT that were in discussion at the time.

As with all security considerations people can not follow them and have bad things happen.

Doesn't suggesting that unrelated systems not issue tokens sharing the same iss/aud namespace make sense here as a mitigation though?  To me that's better and more scalable than every spec removing some required claim from the other specs (e.g. mandating that people can't use "sub").

On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:
We also talked about adding another claim that defines the type or purpose of the JWT ("access token", "SET", etc). In a way it is the only sane option, but it is not addressing existing implementations. Asking implementors to "be careful" is asking for trouble IMO, especially because systems evolve by incrementally adding functionality.

Marius

On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <wdenniss@google.com<mailto:wdenniss@google.com>> wrote:
OK so perhaps the "URI" thing is overly restrictive.

I guess the security consideration I'm recommending here is that you shouldn't have multiple systems that issue JWTs with the same iss/aud tuple, except when those systems are tightly coupled (as is the case with Connect & Logout).

If a shared issuer is used, then URI-based namespacing is *one* way to avoid this, but there are others.

I'm trying to avoid the need for SET to "break" possible use in access tokens (one of the stated goals in the original post) – I think having advice like this can avoid normative language that changes, and overly complicates SET.

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event