Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)
Brian Campbell <bcampbell@pingidentity.com> Fri, 03 March 2017 22:33 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06DF129642 for <id-event@ietfa.amsl.com>; Fri, 3 Mar 2017 14:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heIqQW2PMo-a for <id-event@ietfa.amsl.com>; Fri, 3 Mar 2017 14:33:07 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0946A12963E for <id-event@ietf.org>; Fri, 3 Mar 2017 14:33:07 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id s15so67233603ywg.0 for <id-event@ietf.org>; Fri, 03 Mar 2017 14:33:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jj78CohlXjEdlePpe00z/2mh9v565GDtFlSsCiDMcNQ=; b=CV0Iq+5RBKKMATML3KXbZ76P0vg2FJ9M0r3jFluTgsw2mM+8Jv510urvwA4IFPKc3E RJygJ19qQDvSaLq9NGkF0eQ4HbqzKxd3HCvwHuwggqy0VI8gQY3LY3dNeCxQGrbaA+VH 9XefR0F6581DlunM81akTi8N3mIH2jJSMgetw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jj78CohlXjEdlePpe00z/2mh9v565GDtFlSsCiDMcNQ=; b=lN5sZ6z3Oy0BDVpgmlZsBff7//PcCGtNCSJOUzjjiAHdGPf8NDEvrFfwYmLSkKLhR9 ekGiy9hG1sTCTrdEVuxWLKjIdcL4M64SKbmB39wO+ClEf5hOMqkADFbO1enojfY6U+Hu PzfYD6eVP7FR9E+Vz4Zzsh8yvQuTCKEwbECngp42yx2cl5PU7kNi9NcUY7UwYGWwJFBL oefkWjNH/bVV3PpDBY92iqDP1Y8gKm+cwCMCVR+6SdwLiWKUDZNuoXQcL/wZ3u1VQvHW o6xwY1pThzeTcw2aP/5gT33SRRp1eAgw+tC9CNxgBy1YC7rcCDma7K9tCOnVsbgahijb bnVg==
X-Gm-Message-State: AMke39mXwz75ZpvW+/4sG33vcpgpxkb1EfVPiue/5f2ieuCOmunmXoP6iv2is4OS0WMswcNRK57zmlSK/H0g0/Rw
X-Received: by 10.129.98.70 with SMTP id w67mr3320110ywb.184.1488580386101; Fri, 03 Mar 2017 14:33:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.43.4 with HTTP; Fri, 3 Mar 2017 14:32:35 -0800 (PST)
In-Reply-To: <8bc987ed-a3e1-424e-ae76-51d89ae1be39@default>
References: <4611E3C8-9772-44EA-940D-077E1EA6247F@oracle.com> <CAAP42hAPZOHn-37wYrOy7OcvNuqWdXtSSMHxb_AoW7kXeAy4wA@mail.gmail.com> <CY4PR21MB050423CEEA9AB0CC64F0973FF5290@CY4PR21MB0504.namprd21.prod.outlook.com> <CAAP42hD8FbZSKWiorKSZHqiidak4Gf071xKTD2d9EvZa13mt5g@mail.gmail.com> <CY4PR21MB05047835E14B3D375C0538F6F5290@CY4PR21MB0504.namprd21.prod.outlook.com> <CAAP42hB63GC9=7nqiayjnD9i5RG7Yu7CJVCtDZpNWTgLMrDJ8w@mail.gmail.com> <0D17E1B4-D8C1-4241-8D11-8C0C700DD1D5@oracle.com> <CAAP42hANJNA62Zkhpv96snpk7O8-cUfwMtooCuhyN242vEMkfA@mail.gmail.com> <CAGdjJpLEX06CsLFH4u4YicP1qbW1Q8yjFhZjSovFRJzQv7B1bQ@mail.gmail.com> <CAAP42hAQwK1qPAymbgLNa2bjgBFABHC2VwD5NmrF+iB+zZ__wA@mail.gmail.com> <CY4PR21MB050400C17BDCA9B45C2DB65CF5280@CY4PR21MB0504.namprd21.prod.outlook.com> <CAGdjJpK1UktDPOBT5AXSQS=MYOHz2mbAdiFt8m5AQbyc59ufKA@mail.gmail.com> <CY4PR21MB050423283AFC0A890DEC696EF5280@CY4PR21MB0504.namprd21.prod.outlook.com> <CAGdjJp+kwyw3T7MBKyWyXjewaGrOUVR5=WADu74hGudj_zYqAw@mail.gmail.com> <CAGdjJp+pS+RLKm8fGpv9XO1gz4jYfCPUF+pqgE1KpWJ6dnbheg@mail.gmail.com> <CAAP42hDbdwQfYQ13ksYnO0N89uWo1F1Muu=Rih7n3w++8omfwg@mail.gmail.com> <CAGdjJpLgtSOyNCjsJS7h7vnPBdjN8uHZZZpMuBQ0X4o12WJ_Jw@mail.gmail.com> <CAAP42hCAEPExj=F1ub4upRJwmNaWoKmJJxwgj6MTyPB0CCyNWA@mail.gmail.com> <CA+k3eCS_EHFUd2Vwhdqjp53AtfUBYnz+Hmpj-V7tR7d5uUGX9A@mail.gmail.com> <8756C464-C727-48FD-9486-7183BA04DD7B@oracle.com> <A54424D8-6B80-45F0-80B5-A442F07FFB31@oracle.com> <CAGdjJpKZZ1EJ+a0ohS+gHGegkDAb8Fxi7J_UJCkgDo05M4uy0w@mail.gmail.com> <CY4PR21MB0504818A385D6910BCAD913CF52B0@CY4PR21MB0504.namprd21.prod.outlook.com> <CAGdjJpJ6KciN2VRGg3KejAK7-jdhz1i_b6P3pzTk7f6Abnb5Jg@mail.gmail.com> <8bc987ed-a3e1-424e-ae76-51d89ae1be39@default>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 03 Mar 2017 15:32:35 -0700
Message-ID: <CA+k3eCQGzJf466sfDV8_xXo9n6M96Yc5NMScdvHX_mBAxXyxaw@mail.gmail.com>
To: Vivek Biswas <vivek.biswas@oracle.com>
Content-Type: multipart/alternative; boundary="001a11471bae226f7a0549db2198"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/7Re8abQtVau16QIA2O3AFx_2ITQ>
Cc: William Denniss <wdenniss@google.com>, Mike Jones <Michael.Jones@microsoft.com>, Phil Idm Hunt <phil.hunt@oracle.com>, ID Events Mailing List <id-event@ietf.org>, Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 22:33:11 -0000
The JWT/JWS header is covered by the signature. On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas <vivek.biswas@oracle.com> wrote: > I am not a big fan of defining type within the header field of the JWT > since the header field is not signed and decisions can be influenced by > doing MIM attacks. > > > > See article > > https://auth0.com/blog/critical-vulnerabilities-in- > json-web-token-libraries/ > > This attack is also known as “"Algorithm choice as an attack vector" > > Similar attack can be done with respect to the “type”. > > > > If a type is required it should be defined within the body which is signed. > > > > Regards > > Vivek Biswas, CISSP > > Consulting Member @Security > > Oracle Corporation, San Jose > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Thursday, March 02, 2017 6:17 PM > *To:* Mike Jones > *Cc:* William Denniss; Brian Campbell; ID Events Mailing List; Phil Hunt > > *Subject:* Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: > Clarifying use of sub and iss in SET tokens) > > > > On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > It’s not a legal JWT implementation if it doesn’t implement “crit”. Per > https://tools.ietf.org/html/rfc7515#section-4.1.11, “This Header > Parameter MUST be understood and processed by implementations”. If you > know of implementations that don’t support it, we should lobby to get them > fixed, rather than trying to work around bugs in those implementations. > > > > Thanks for clarifying. Then Brian's proposal is definitely viable. > > > > Again, doing general-purpose JWT work is not in the scope of this working > group. (The OAuth WG owns that.) Doing SecEvent-specific JWT work is in > scope. > > > > I totally understand that Mike, but to me it looked like there is no good > solution in scope for this working group, so I suggested we escalate. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Thursday, March 2, 2017 4:35 PM > *To:* Phil Hunt <phil.hunt@oracle.com> > *Cc:* Brian Campbell <bcampbell@pingidentity.com>; William Denniss < > wdenniss@google.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events > Mailing List <id-event@ietf.org> > *Subject:* Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: > Clarifying use of sub and iss in SET tokens) > > > > I did not realize that typ is a header. Shouldn't ideally the SET purpose > or "type" be a claim rather? > > > > I doubt that any existing libraries take crit into account. Can anyone > point to a library that does look at crit? With that in mind, crit does not > help much IMO, we might just as well define a type claim. > > > Marius > > > > On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt <phil.hunt@oracle.com> wrote: > > PS. This is another of Yaron’s threads….”Avoiding SETS being confused as > access tokens” > > > > > > Phil > > > > Oracle Corporation, Identity Cloud Services & Identity Standards > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > > > On Mar 2, 2017, at 8:03 AM, Phil Hunt <phil.hunt@oracle.com> wrote: > > > > Interesting! +1 > > > > Phil > > > > Oracle Corporation, Identity Cloud Services & Identity Standards > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > > > > On Mar 2, 2017, at 7:53 AM, Brian Campbell <bcampbell@pingidentity.com> > wrote: > > > > Not that it makes a difference helping the situation here but "typ" is a > JOSE header rather than a JWT claim (see https://tools.ietf.org/html/ > rfc7515#section-4.1.9 and https://tools.ietf.org/html/ > rfc7516#section-4.1.11 and https://tools.ietf.org/html/rfc7519#section-5.1 > ). > > That got me thinking, however, that maybe the "crit" JOSE header ( > https://tools.ietf.org/html/rfc7515#section-4.1.11) might be useful here. > Assuming JWT/JOSE implementations support "crit" per spec (they *should* > but that might be an optimistic assumption) then it could be used to > address the 'clients already written that don't check for it' problem. > Something like a new "set" header that gets marked as critical. I.e. as > just a strawman, > > { > "alg":"ES256", > > "crit":["set"], > > "set":true > > } > > says that the receiver must understand and process the "set" header, which > existing OIDC and OAuth JWT consumers wouldn't. > > Honestly not sure if that's a good idea or not. But wanted to throw it out > there. > > > > > > > > On Wed, Mar 1, 2017 at 7:05 PM, William Denniss <wdenniss@google.com> > wrote: > > > > > > On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <mscurtescu@google.com> > wrote: > > On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <wdenniss@google.com> > wrote: > > > > On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <mscurtescu@google.com> > wrote: > > On Wed, Mar 1, 2017 at 4:50 PM, William Denniss <wdenniss@google.com> > wrote: > > As a concrete example, let's say an RP that supports OIDC decides to also > implement RISC/SET. When they read the spec and decide on implementation > they realize that they also have to modify the existing OIDC implementation > so it does not accept Id Token looking JWTs that have an "events" claim. It > is very easy to miss this requirement. But more important, when the next > JWT application is implemented they might have to yet again update the > existing OIDC implementation, and so forth. > > > > Why would the RISC implementation reuse the same iss/aud pair as the OIDC > implementation? > > > > iss naturally would be the same in most cases. I would argue that aud > would also naturally be the same, the client id, since that is the intended > recipient. Having aud be the URL of the target endpoint for example (the > only suggestion I am aware of), is hackish at best. The same endpoint could > be shared by multiple clients in some cases. Also, this couples creating > the SET with delivery details > > > > Why not change iss for RISC? https://issuer.google.com/risc for example. > > > > Because iss/sub basically forces the iss to be the exact same as in the Id > Token. And separate iss requires separate signing keys. > > > > We'd have to host the keys multiple times, but they *could* still be the > same keys, right? > > > > > > If it didn't, there's no issue! > > > > There might be no issue for SET, but we are going to run into this problem > over and over again. > > > > > > Isn't this the simplest approach? Given that "typ" isn't mandated by JWT, > I think that this is therefore the implied method for segregating JWTs by > the usage intent. > > > > Not sure what you mean by "this". Replacing typ with unique iss/aud > combinations? > > > > Our issue is that we have a common token format JWT, that multiple systems > will consume which have different concerns. Reading RFC7519, I don't see > any way to separate those concerns, other than with iss/aud. RFC7519 > doesn't say "each spec that uses JWT should use a unique combination of > claims such at no other spec could accidently interpret it as meant for > them" (and I'm not convinced this is scalable, or desirable). Nor does it > require the use of a type claim to achieve the usage segregation, and it's > too late to add one now. > > > > I totally agree that we have no ideal solution here. Having each > application define its own URN (or some schema) for aud might work, even if > ugly. This is similar to merging typ into aud. Do we have any concrete > proposals here? > > > > Defining a structured aud format could solve this, I agree – like you say, > it's merging type into aud in a way that's backwards compatible. > Personally I don't mind that approach, but I recall some resistance to it. > > > > Some kind of separation based on iss or aud I think is going to be the > safest and most scalable solution. > > > > Why is it too late to use typ? > > > > Because of all the clients already written that don't check for it. > > > > > > > > > > On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <mscurtescu@google.com> > wrote: > > Mike, me providing a bulletproof example is irrelevant I think. I am > trying to convey a general idea. My point is that having to continuously > update existing implementations with new validation rules is error prone > and less likely to happen that having to do one generic update. > > > Marius > > > > On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > Except that your example isn’t one in which there’s an actual problem. > For all response_types except for “code”, the ID Token must have a “nonce” > claim matching the request in order to be validated. SETs won’t have this > claim. For response_type=code, the ID Token must be retrieved from the > Token Endpoint to be valid. But SETs aren’t returned as the id_token value > from the Token Endpoint. There isn’t a channel in which an attacker can > successfully substitute a SET for an ID Token and have it validate as an ID > Token. > > > > Following the advice to also verify that there isn’t an “events” claim in > an ID Token provides redundancy and is good hygiene but isn’t actually even > necessary to prevent substitution attacks. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Wednesday, March 1, 2017 4:22 PM > *To:* Mike Jones <Michael.Jones@microsoft.com> > *Cc:* William Denniss <wdenniss@google.com>; Phil Hunt (IDM) < > phil.hunt@oracle.com>; ID Events Mailing List <id-event@ietf.org> > > > *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in SET > tokens > > > > > > As a concrete example, let's say an RP that supports OIDC decides to also > implement RISC/SET. When they read the spec and decide on implementation > they realize that they also have to modify the existing OIDC implementation > so it does not accept Id Token looking JWTs that have an "events" claim. It > is very easy to miss this requirement. But more important, when the next > JWT application is implemented they might have to yet again update the > existing OIDC implementation, and so forth. > > > > One simpler fix would be to modify the OIDC implementation once to look > for the correct "typ" claim (assuming one is defined). The security > considerations in the SET spec could specify that due to iss/aud overlap it > is crucial that typ is validated in all related implementations. > > > > I understand that typ cannot be standardized by the SET spec for other > specs (but it could definitely clearly define it for SET), but I think the > sooner we do that for all relevant specs the better. > > > > > > > Marius > > > > On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > 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> > 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> > 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 > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > >
- [Id-event] Thread: Clarifying use of sub and iss … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Marius Scurtescu
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Marius Scurtescu
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Marius Scurtescu
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Marius Scurtescu
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Marius Scurtescu
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Brian Campbell
- [Id-event] Making SETs distinct as JWTs (was: Re:… Phil Hunt
- Re: [Id-event] Making SETs distinct as JWTs (was:… Phil Hunt
- Re: [Id-event] Making SETs distinct as JWTs (was:… Marius Scurtescu
- Re: [Id-event] Making SETs distinct as JWTs (was:… Mike Jones
- Re: [Id-event] Making SETs distinct as JWTs (was:… Marius Scurtescu
- Re: [Id-event] Making SETs distinct as JWTs (was:… Brian Campbell
- Re: [Id-event] Making SETs distinct as JWTs Benjamin Kaduk
- Re: [Id-event] Making SETs distinct as JWTs (was:… Vivek Biswas
- Re: [Id-event] Making SETs distinct as JWTs (was:… Brian Campbell
- Re: [Id-event] Making SETs distinct as JWTs (was:… Phil Hunt (IDM)
- Re: [Id-event] Making SETs distinct as JWTs (was:… Mike Jones
- Re: [Id-event] Making SETs distinct as JWTs (was:… Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Justin Richer
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Justin Richer
- Re: [Id-event] Making SETs distinct as JWTs Yaron Sheffer
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Benjamin Kaduk
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … William Denniss
- Re: [Id-event] Thread: Clarifying use of sub and … Benjamin Kaduk
- Re: [Id-event] Thread: Clarifying use of sub and … Justin Richer
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt
- Re: [Id-event] Thread: Clarifying use of sub and … Marius Scurtescu
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … Benjamin Kaduk
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones
- Re: [Id-event] Thread: Clarifying use of sub and … Phil Hunt (IDM)
- Re: [Id-event] Thread: Clarifying use of sub and … Benjamin Kaduk
- Re: [Id-event] Thread: Clarifying use of sub and … Mike Jones