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

[Mike Jones <[e-mail]>]

Yes, adding another general-purpose JWT type claim was discussed on the mailing list.  My sense of that discussion was that people mostly agreed that doing that was new JWT work, and therefore in the scope of the OAuth working group, and not SecEvent-specific work, and so out of scope for the SecEvent working group.

If we write Security Considerations on the topic, they should be likewise scoped to use cases in which SETs are used, and not try to write new Security Considerations that apply to all JWTs.  Thus, it’s fine for the SET spec to say, for instance, that applications in which more than one kind of JWT can be signed by the same issuer, one kind of which is a SET, should take appropriate application-specific measures to ensure that the different kinds of JWTs cannot be confused for one another.  But beyond suggesting that these applications use the “events” claim to distinguish between SETs and other kinds of JWTs, trying to write specific general-purpose JWT guidance is out of scope for this working group.

                                                                -- Mike

From: Marius Scurtescu [mailto:[e-mail]]
Sent: Wednesday, March 1, 2017 3:55 PM
To: William Denniss <[e-mail]>
Cc: Phil Hunt (IDM) <[e-mail]>; Mike Jones <[e-mail]>; ID Events Mailing List <[e-mail]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event