Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
John Bradley <ve7jtb@ve7jtb.com> Sat, 11 January 2020 19:36 UTC
Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07185120096 for <oauth@ietfa.amsl.com>; Sat, 11 Jan 2020 11:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 0PW3WIg7g8GK for <oauth@ietfa.amsl.com>; Sat, 11 Jan 2020 11:36:34 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 3954E12004C for <oauth@ietf.org>; Sat, 11 Jan 2020 11:36:33 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id w47so5336091qtk.4 for <oauth@ietf.org>; Sat, 11 Jan 2020 11:36:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ybQrghtEi9G6bISKZu25fg2b7bEmPynvaszBcs+NYyI=; b=PWrznKcHEzAktYNFHkbI7RwNRlJSZl+sFPW5LlreId71/osS6E8tICUmS7YPPFrw3w 0tY57DGvUas6jeWi7tO7JtpGlLdTtJyen5gGofwp4F61FeI5XWSKm+AbMl+YMcrWwBFG 02wXCjeHwXKc4tcfnwG1SSlSJVSZKSP5IUGzxW/cUFT7a6jR9p/oHkrL6vHJh6EYzT2o PKeYnKq+Ueq3pkcVw0/fGTPerlAw2weXZEBXVtZjydj//+1V5ny7NUn3AvuTpyjM1f+7 An60Z/8ZfhXASYVLzMO7LC0lBBBMt0tNlV3Rf3ZYNNGXahMdu5QgP/uJxvD0xrXgW4/4 8snA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=ybQrghtEi9G6bISKZu25fg2b7bEmPynvaszBcs+NYyI=; b=cdTdRmpaCxwaBOSUlMblejuk72zbftLvCEXR8fONx+gkIDLL/3ONDyU4YXrwTI0Knx 5t08gs1/wEcaEuoXRW13QpC3VVqeuBKlh6mwrc1DRq8ETJ8ca3tdRC6A80t0+z3J9Wud 4dARNi1QzKjLDt9aFax3/rwFvJW/63WC6PTO2mmEXJxZGVxt9pTzjDxP+lQCyEaIsoyO w2YGl5Az9KqjSh9+4IftYALzAb5tNxhhkKpBJn8qnjnM2PrAL/y6M/w7RmKNreUFbRpr D7d/0iaYgTn7Y7ItsRZ5vCttEXb42X/BXvCcLfaP4TaxbuWzws5BU9IX/rVfLPHNC532 +Utw==
X-Gm-Message-State: APjAAAXfPnxmtNcKvw2MqeZmOrARRQwT7fUpFyJr89ZG86eqQ5w+3TCx Dy1m8pWV2Qaw08Gz3LBAxyeM0H3hpwdg5PVb
X-Google-Smtp-Source: APXvYqxsacvcdcBwxt7F8GXXqXF8V+HSdLBdRQdJ3kWIRcrSmUV530ok2Ul/ozoua4wL8XB8v7aaMQ==
X-Received: by 2002:aed:3f32:: with SMTP id p47mr8062523qtf.374.1578771391629; Sat, 11 Jan 2020 11:36:31 -0800 (PST)
Received: from [192.168.86.36] ([191.115.91.53]) by smtp.gmail.com with ESMTPSA id c13sm2656908qko.87.2020.01.11.11.36.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jan 2020 11:36:30 -0800 (PST)
To: Vladimir Dzhuvinov <vladimir@connect2id.com>, Mike Jones <Michael.Jones@microsoft.com>
Cc: IETF oauth WG <oauth@ietf.org>
References: <fc3805e5-e908-00db-a734-990721371ab2@connect2id.com> <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com> <CAANoGhK0-n6V_RogvVZ=8J8AQCEUUVJQn4_7wSWYixeQM8aZsw@mail.gmail.com> <CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0@CH2PR00MB0843.namprd00.prod.outlook.com> <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com>
Date: Sat, 11 Jan 2020 16:36:25 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com>
Content-Type: multipart/alternative; boundary="------------3584F9716D5265D80C78EBAC"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HPgjKsasNqZMbFpgeYrzaHfvW6U>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2020 19:36:37 -0000
Yes JAR is not prohibiting paramater replication in the header. I will see if i can add something in final edits to call that out. John B. On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote: > > Thanks Mike for the rfc7519 section-5.3 > <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this > parameter replication be used for client_id or the client_id ass "iss" > even though it isn't explicitly mentioned in the JAR spec? > > On 11/01/2020 02:58, John Bradley wrote: >> Right we just don't say to put the iss there in OIDC if it's >> symetricly encrypted. > > OIDC doesn't have the symmetric key selection issue, I suppose that > why the possibility to replicate params to the JWE header isn't > mentioned at all. OIDC requires the top-level query params to > represent a valid OAuth 2.0 request, and there client_id is required. > If the client_id is present the client registration together with any > present client_secret can be retrieved. > > I reread the JAR spec, this is the only place that mentions handling > of symmetric JWE. > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2 > >> (b) Verifying that the symmetric key for the JWE encryption is the >> correct one if the JWE is using symmetric encryption. > > > Vladimir > > >> >> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>> wrote: >> >> The technique of replicating JWT claims that need to be publicly >> visible in an encrypted JWT in the header is defined at >> https://tools.ietf.org/html/rfc7519#section-5.3. (Thanks to Dick >> Hardt for bringing this need to my attention as we were finishing >> the JWT spec.) >> >> >> >> -- Mike >> >> >> >> *From:* OAuth <oauth-bounces@ietf.org >> <mailto:oauth-bounces@ietf.org>> *On Behalf Of * John Bradley >> *Sent:* Friday, January 10, 2020 2:15 PM >> *To:* Vladimir Dzhuvinov <vladimir@connect2id.com >> <mailto:vladimir@connect2id.com>> >> *Cc:* IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>> >> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization >> Request (JAR) vs OIDC request object >> >> >> >> The intent was to do that, but specs change once the OAuth WG and >> IESG get there hands on them. >> >> >> >> Being backwards compatible with OIDC is not a compelling argument >> to the IESG. >> >> >> >> We were mostly thinking of asymmetric encryption. >> >> >> >> Specifying puting the issuer and or the audience in the headder >> has come up in the past but probably is not documented. >> >> >> >> John B >> >> >> >> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov >> <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote: >> >> Yes, putting the client_id into the JWE header is a way >> around the need >> to have the client_id outside the JWE as top-level authZ >> request parameter. >> >> Unfortunately this work around isn't mentioned anywhere, I >> just checked >> the most recent draft-ietf-oauth-jwsreq-20. >> >> Our DDoS attack mitigation (for OIDC request_uri) also relies >> on the >> presence of client_id as top-level parameter, together with >> requiring >> RPs to register their request_uri's (so that we don't need to >> build and >> store an index of all request_uri's). I just had a look at >> "DDoS Attack >> on the Authorization Server" and also realised the request_uri >> registration isn't explicitly mentioned as attack prevention >> ("the >> server should (a) check that the value of "request_uri" >> parameter does >> not point to an unexpected location"). >> >> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1 >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0> >> >> To be honest, I feel quite bad about the situation with JAR >> we are in >> now. For some reason I had the impression that OAuth JAR was >> going to be >> the OIDC request / request_uri for general OAuth 2.0 use, as >> with other >> OIDC bits that later became general purpose OAuth 2.0 specs. >> >> I find it unfortunate I didn't notice this when I was >> reviewing the spec >> in the past. >> >> Vladimir >> >> >> On 10/01/2020 22:39, Filip Skokan wrote: >> > Vladimir, >> > >> > For that very case the payload claims may be repeated in >> the JWE protected header. An implementation wanting to handle >> this may look for iss/client_id there. >> > >> > Odesláno z iPhonu >> > >> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov >> <vladimir@connect2id.com <mailto:vladimir@connect2id.com>>: >> >> >> >> I just realised there is one class of JARs where it's >> practially >> >> impossible to process the request if merge isn't supported: >> >> >> >> The client submits a JAR encrypted (JWT) with a shared >> key. OIDC allows >> >> for that and specs a method for deriving the shared key >> from the >> >> client_secret: >> >> >> >> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0> >> >> >> >> If the JAR is encrypted with the client_secret, and there >> is no >> >> top-level client_id parameter, there's no good way for the >> OP to find >> >> out which client_secret to get to try to decrypt the JWE. >> Unless the OP >> >> keeps an index of all issued client_secret's. >> >> >> >> >> >> OP servers which require request_uri registration >> >> (require_request_uri_registration=true) and don't want to >> index all >> >> registered request_uri's, also have no good way to process >> a request_uri >> >> if the client_id isn't present as top-level parameter. >> >> >> >> >> >> Vladimir >> >> >> >> >> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote: >> >>> >> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley >> <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>: >> >>>> I think Torsten is speculating that is not a feature >> people use. >> >>> I’m still trying to understand the use case for merging >> signed and unsigned parameters. Nat once explained a use >> case, where a client uses parameters signed by a 3rd party >> (some „certification authority“) in combination with >> transaction-specific parameters. Is this being done in the wild? >> >>> >> >>> PS: PAR would work with both modes. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0> >> > -- > Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- [OAUTH-WG] JWT Secured Authorization Request (JAR… Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Dominick Baier
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … n-sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Takahiko Kawasaki
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Dominick Baier
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Nat Sakimura
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Nat Sakimura
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Joseph Heenan
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Jim Manico
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Brian Campbell
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Joseph Heenan
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Author… John Bradley
- Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Au… Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Mike Jones
- Re: [OAUTH-WG] JWT Secured Authorization Request … Joseph Heenan
- Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Au… Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … George Fletcher
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Rob Otto