Re: [Id-event] Making SETs distinct as JWTs
Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 06 March 2017 10:56 UTC
Return-Path: <yaronf.ietf@gmail.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 9C54F129636 for <id-event@ietfa.amsl.com>; Mon, 6 Mar 2017 02:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xx3Gnyhgc7GX for <id-event@ietfa.amsl.com>; Mon, 6 Mar 2017 02:56:44 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 D218F12944B for <id-event@ietf.org>; Mon, 6 Mar 2017 02:56:43 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id 1so146730296qkl.3 for <id-event@ietf.org>; Mon, 06 Mar 2017 02:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=HP/UI9xKGS1bSswH02Q2icFAWBFR08TEEpQgqqjEKAo=; b=StkuxRX8G/Lsm0LnyPdVIxnrt3bGw4nTsnkwAM49EArNtfrheyZs9/S9vwGpRdm4I6 l7WpaFsOOhmN0abHG3yokCV65ZtW2CP6FzykrsWZDFcAFQzJEz4JgoWirk4p62EnzfIi Hm7RrLrHBbY2qctWo2gzGeE0dFVuXpRQgnIWLgUELZaxhT05qrQjhFO8Bd6ixw/qk521 tDd1tE7M3d50M6h/A6XF7MYazhirnVcVifXbwrfKQJR/Sorvq3ELkkDFXrVHvGvHP9KM f2ZkCaXuwhnbp7ZRa/MXMxuoZYm44ycQVUEZvonUiljgEoih+EKdOG3z23Qjsjd1VVnZ +1WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HP/UI9xKGS1bSswH02Q2icFAWBFR08TEEpQgqqjEKAo=; b=NIqbBNQ3+cD9GTDJMwmmwLs8HtyP8+6IgbosqTgFAxROuVBPGB5dYSA4JGq5bLutUZ B1DLIU6kIkMVP5lBH5wSBWuAUf/HuQbx1e5elvNBMt5rVa8V8WKCVoksJFFTt2UiiU0c niSLWcyhmNBYvrlGi7Te30I3LokYK30jKBVPw7t5I2/OZXfB18QYjBM8nnkUinIEEvCA OPl1nOlisji16+adSmLjChkNFcpGC3i4qRdbAtJzNg10kdKFewJfWbmMXj/qZ/2VzgWQ r7463V/Mb7HwZKqch398X5I2/1tORdsp3AmwJNXdNBV/tYpjKdZ1yIaiQHvMupePP4sV qNVg==
X-Gm-Message-State: AMke39mNsexHemTSc6S1P40YFTo3l5gxuMss0Nr2/fDatIL9PzlqgtLS+7aMehddk6/Xug==
X-Received: by 10.55.73.147 with SMTP id w141mr10473231qka.205.1488797802459; Mon, 06 Mar 2017 02:56:42 -0800 (PST)
Received: from [172.18.133.122] (cowboy3.intuit.com. [65.204.229.13]) by smtp.gmail.com with ESMTPSA id o16sm13100114qkl.67.2017.03.06.02.56.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 02:56:41 -0800 (PST)
To: Phil Hunt <phil.hunt@oracle.com>, Mike Jones <Michael.Jones@microsoft.com>
References: <4611E3C8-9772-44EA-940D-077E1EA6247F@oracle.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> <CA+k3eCQGzJf466sfDV8_xXo9n6M96Yc5NMScdvHX_mBAxXyxaw@mail.gmail.com> <E8A82BD0-226B-4DBF-804D-37ACDD691DF5@oracle.com> <CY4PR21MB050460A6FBD65337CEF3F0C4F52A0@CY4PR21MB0504.namprd21.prod.outlook.com> <56CA02B5-2D01-4B55-8366-99FF5350144A@oracle.com>
From: Yaron Sheffer <yaronf.ietf@gmail.com>
Message-ID: <4ef42f10-fa5d-8324-12bf-c1c0782a6cae@gmail.com>
Date: Mon, 06 Mar 2017 12:56:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <56CA02B5-2D01-4B55-8366-99FF5350144A@oracle.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/eR5mr6TmQMvbdts3mSBzAIyYK5Q>
Cc: William Denniss <wdenniss@google.com>, Vivek Biswas <vivek.biswas@oracle.com>, Brian Campbell <bcampbell@pingidentity.com>, ID Events Mailing List <id-event@ietf.org>, Marius Scurtescu <mscurtescu@google.com>
Subject: Re: [Id-event] Making SETs distinct as JWTs
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: Mon, 06 Mar 2017 10:56:46 -0000
I would like to have separate discussion on: * Whether SETs must be signed or alg:none is legitimate (where I understand Mike's position that tightening things up might push people with different use cases away from SET). * Whether SETs can be used/abused as access tokens. I think the two questions are unrelated. Regardless if all or only some SETs are signed, they can still be portable into unintended situations. So if we can avoid such portability, e.g. by removing "sub" or forcing a "typ" field, we definitely should. Thanks, Yaron On 04/03/17 03:22, Phil Hunt wrote: > This thread here suggests that with “alg”:”none” cert could be modified > to make it look like it isn’t at SET and be used as an access token. > > If it does not matter, we need to include the conditions where > “alg”:”none” is safe to use. E.g. the assertions are shared in a > back-channel not associated with users and secured by mutual TLS so no > third party could intercept. > > > Phil > > Oracle Corporation, Identity Cloud Services & Identity Standards > @independentid > www.independentid.com <http://www.independentid.com> > phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> > > > > > > > >> On Mar 3, 2017, at 4:48 PM, Mike Jones <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>> wrote: >> >> That’s another issue that’s already been well-discussed. There are >> plenty of cases in which “alg”: “none” is the right level of integrity >> protection for JWTs – including SETs. This is the case when, for >> instance, the JWT or SET is already integrity protected by the >> transport – such as TLS. We should definitely leave the choice of >> JWT/SET algorithms up to the application – just like the base JWT spec >> did. >> >> I understand the urge to “tighten things up” but it’s often the case >> when we “tighten things up” we’d be imposing restrictions on SETs that >> would make them a poor match for particular use cases, causing them to >> not use SETs at all. The value of SETs is that they define an >> “events” claim and its usage within JWTs. Unless there are compelling >> reasons to go further, we should stop there and declare victory. >> >> -- Mike >> >> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >> *Sent:* Friday, March 3, 2017 3:34 PM >> *To:* Brian Campbell <bcampbell@pingidentity.com >> <mailto:bcampbell@pingidentity.com>> >> *Cc:* Vivek Biswas <vivek.biswas@oracle.com >> <mailto:vivek.biswas@oracle.com>>; Marius Scurtescu >> <mscurtescu@google.com <mailto:mscurtescu@google.com>>; Mike Jones >> <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>>; >> William Denniss <wdenniss@google.com <mailto:wdenniss@google.com>>; ID >> Events Mailing List <id-event@ietf.org <mailto: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) >> >> Would we want to make signing mandatory to ensure SET differentiation >> is protected (in addition to the other benefits)? >> >> Phil >> >> >> On Mar 3, 2017, at 2:32 PM, Brian Campbell <bcampbell@pingidentity.com >> <mailto:bcampbell@pingidentity.com>> wrote: >> >> The JWT/JWS header is covered by the signature. >> >> On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas >> <vivek.biswas@oracle.com <mailto: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 >> <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 >> <mailto:Michael.Jones@microsoft.com>> wrote: >> >> It’s not a legal JWT implementation if it doesn’t >> implement “crit”. >> Perhttps://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 >> <mailto:mscurtescu@google.com>] >> *Sent:* Thursday, March 2, 2017 4:35 PM >> *To:* Phil Hunt <phil.hunt@oracle.com >> <mailto:phil.hunt@oracle.com>> >> *Cc:* Brian Campbell <bcampbell@pingidentity.com >> <mailto:bcampbell@pingidentity.com>>; William Denniss >> <wdenniss@google.com <mailto:wdenniss@google.com>>; Mike >> Jones <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>; ID Events Mailing >> List <id-event@ietf.org <mailto: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 <mailto: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 <http://www.independentid.com/> >> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> >> >> >> >> >> >> >> >> >> >> On Mar 2, 2017, at 8:03 AM, Phil Hunt >> <phil.hunt@oracle.com >> <mailto:phil.hunt@oracle.com>> wrote: >> >> Interesting! +1 >> >> Phil >> >> Oracle Corporation, Identity Cloud Services & >> Identity Standards >> @independentid >> www.independentid.com <http://www.independentid.com/> >> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> >> >> >> >> >> >> >> >> >> >> On Mar 2, 2017, at 7:53 AM, Brian Campbell >> <bcampbell@pingidentity.com >> <mailto: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 >> (seehttps://tools.ietf.org/html/rfc7515#section-4.1.9 andhttps://tools.ietf.org/html/rfc7516#section-4.1.11 andhttps://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 >> <mailto:wdenniss@google.com>> wrote: >> >> >> >> On Wed, Mar 1, 2017 at 5:52 PM, Marius >> Scurtescu <mscurtescu@google.com >> <mailto:mscurtescu@google.com>> wrote: >> >> On Wed, Mar 1, 2017 at 5:30 PM, >> William Denniss <wdenniss@google.com >> <mailto:wdenniss@google.com>> wrote: >> >> >> On Wed, Mar 1, 2017 at 5:05 PM, >> Marius Scurtescu >> <mscurtescu@google.com >> <mailto:mscurtescu@google.com>> wrote: >> >> On Wed, Mar 1, 2017 at 4:50 >> PM, William Denniss >> <wdenniss@google.com >> <mailto: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 >> <mailto: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 >> <mailto: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 >> <mailto:mscurtescu@google.com>] >> *Sent:* Wednesday, >> March 1, 2017 4:22 PM >> *To:* Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>> >> *Cc:* William >> Denniss >> <wdenniss@google.com >> <mailto:wdenniss@google.com>>; >> Phil Hunt (IDM) >> <phil.hunt@oracle.com >> <mailto:phil.hunt@oracle.com>>; >> ID Events Mailing >> List >> <id-event@ietf.org >> <mailto: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 >> <mailto: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 >> <mailto:wdenniss@google.com>] >> *Sent:* Wednesday, >> March 1, 2017 >> 4:00 PM >> *To:* Marius >> Scurtescu >> <mscurtescu@google.com >> <mailto:mscurtescu@google.com>> >> *Cc:* Phil >> Hunt (IDM) >> <phil.hunt@oracle.com >> <mailto:phil.hunt@oracle.com>>; >> Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>; >> ID Events >> Mailing List >> <id-event@ietf.org >> <mailto: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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org <mailto:Id-event@ietf.org> >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org <mailto:Id-event@ietf.org> >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org <mailto: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