Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

Filip Skokan <> Fri, 31 January 2020 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B769E120804; Fri, 31 Jan 2020 06:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3pLKBdelYLwt; Fri, 31 Jan 2020 06:46:48 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 873A312007C; Fri, 31 Jan 2020 06:46:47 -0800 (PST)
Received: by with SMTP id f129so8972410wmf.2; Fri, 31 Jan 2020 06:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=WYr16KlwCMsD9sDusPFNVZU1DILvnJ+/rKwkR4Ud5O0=; b=SiyCNKtEE350zJsS+BB1rEKU+aMjWjtueKdmo7VlbuBau6Vu86r7fvpO22AEAhA0RM ju1hZPL2EU6VGHLEcCFgUpVMPsSvvj6FU4XbpCUqLXyvkI3zEQhp+c8Md7IkbGQzNJ8O qmWJp1bS3RpGtMs+llajgdaW2DV3683R/gLhg/SBHJFki/EvovQtbLMaIduY3y+Wq7PQ I2xFpbr2aZ5pINKXdKhUKF8KFaGNazEsrK7T1DWSdNvm6Zhyc/dV5VqhIbrGmaiXH/cu 05vxZXHVXYdiePBKdpHrolpu/oNqWGd+YKHmV3alvxFRNMhkIjyj6WLuc0feBgy34SjP dL3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=WYr16KlwCMsD9sDusPFNVZU1DILvnJ+/rKwkR4Ud5O0=; b=cjZRhMuQnJfroZ2UyVx92Fkb400lB/TEq/7MdgeVPQ4Yyuz9uM9He3WXed48nLdcrZ s02jxvZfGA6C0SJpwu/ia/QfGhesF3fY6ixpk0tbh2r5HSo2K0M0WW+I1X6edczPZ3sV zk4BEdjjQqhf+4cv4Ex99/JApykUa9sHIiz8PzIPjtIM0AfSUSiDFBMgJIMdhqpkrxlv i0G4lZ1HE81t5FjWQ5PzDkIBqPxbrTj6xfdez9qiqpSLouiutZ6hsA2J+sXlyskMlVxH cZZPBRsJMVjT0KjY0YrVmM3m/h/NMygyQ5SEPSTdPI7S3ZZ3e6ByYdimbNbMxR8d9RHv 2Iag==
X-Gm-Message-State: APjAAAU0OoxDTBpTa3JfdVO0g+qRF0EadAKuio3WPsAZm5iGCNXbCyZr qr4NlfVBHD0otUpxzLSSjw==
X-Google-Smtp-Source: APXvYqyGf15WyfNmCrugFRFXn5awUao7hl4g7lLNUDzzKF26BM0rIH/jDma/2tAA74LUGSIqpHGcPw==
X-Received: by 2002:a05:600c:2207:: with SMTP id z7mr12724086wml.138.1580482005713; Fri, 31 Jan 2020 06:46:45 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id e8sm11937489wrt.7.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:46:45 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Filip Skokan <>
Mime-Version: 1.0 (1.0)
Date: Fri, 31 Jan 2020 15:46:44 +0100
Message-Id: <>
References: <>
In-Reply-To: <>
To: Benjamin Kaduk <>, The IESG <>, "" <>, oauth <>, "" <>
X-Mailer: iPhone Mail (17C54)
Archived-At: <>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jan 2020 14:46:52 -0000

I also agree and support that client_id outside of the request object be usable for the purposes described earlier, given that it is also a MUST it be present in the request object with the same value as outside. 

Odesláno z iPhonu

> 31. 1. 2020 v 15:31, Mike Jones <>rg>:
> I also agree that we must allow client_id to be expressed outside of the signed request, as described by Nat.
>                -- Mike
> -----Original Message-----
> From: OAuth <> On Behalf Of John Bradley
> Sent: Friday, January 31, 2020 6:25 AM
> To: Nat Sakimura <>om>; Benjamin Kaduk <>
> Cc: oauth <>rg>;; The IESG <>rg>;
> Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
>> From the discussions I have had, I agree with Nat's assment.
> John B.
>> On 1/31/2020 12:06 AM, Nat Sakimura wrote:
>> Hi
>> Re: JWT
>> I understand your concern and we can put some explanatory notes. 
>> Having said that, JAR is still a valid JWT, I think :-)
>> Re: client_id
>> We actually discussed client_id issues with OpenID Connect WG Call 
>> yesterday as well.
>> I hear a pretty strong voice from the developer community that they 
>> want client_id as a query parameter and it should not pose a security 
>> issue as long as it is required to match what is in the JWT. In fact, 
>> that was the position taken in the WG last call. So, in effect, WG is 
>> actually pushing back the change IESG wanted.
>> As I understand it, there are two points to be made:
>> (1) If client_id is not in the query parameter, then it MUST be in the 
>> JWT header OR MUST be supplied as a query parameter in some encrypted 
>> JAR case
>> (2) To check if requst_uri is a registered and valid URI, not having 
>> client_id in the query parameter will have performance impacts in a 
>> large AS.
>> The encryption case (1) can be solved by adding client_id in the JWT 
>> Header but it will not solve (2).
>> So, IMHO, putting client_id back to the query parameter (and MUST 
>> match the value in JWT) is a way to go.
>> Since that was the position by the WG at the WG Last Call, I do not 
>> feel that it needs to be brought back to the WG last call, but that is 
>> your call.
>> Best,
>> Nat Sakimura
>>> On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk <> wrote:
>>> Hi Nat,
>>> Now it is my turn to apologize for taking a long time.
>>> I think I see the general direction these changes are going in, and 
>>> it's a reasonable approach to the unfortunate situation we find 
>>> ourselves in with respect to JWT claims vs. OAuth parameters.  In 
>>> effect, what we're doing is making a "profile" (for lack of a better 
>>> term) of JWT, that leverages the mechanisms and algorithms of JWT but 
>>> uses a different registry for interpreting the claims in the token 
>>> (that is, OAuth Parameters vs. JWT Claims).  We can tell that this 
>>> "profile" of JWT is being used because of the context in which the JWT is transferred/received: if it's the "request"
>>> parameter, that's part of the definition of the OAuth Parameter, and 
>>> if it's the result of dereferencing a "request_uri", the 
>>> application/oauth.authz.req+jwt media-type clearly indicates how the 
>>> contents should be interpreted.
>>> However, the changes in the -20 do not give the reader much of any 
>>> hint as to this being what's expected to happen, and that stock RFC 
>>> 7519 JWT is
>>> *not* what's in use.  So I'd request that we take a close look at how 
>>> the document uses "JWT" vs. "JWT encoding" (etc.); add an explicit 
>>> statement that while the JWT encoding is in use, the contents are to 
>>> be interpreted by interpreting the JWT claims as OAuth Parameters 
>>> (and not as per the IANA registry of JWT claims); and add some 
>>> discussion (similar to the above) about how the application context 
>>> makes it unambiguous whether the JWT-encoded claims are standard JWT 
>>> claims or OAuth Parmaters as per this document.
>>> With respect to my second ("discuss discuss") point, Nat and I did 
>>> have a discussion in-person and I accept that there may be some 
>>> scenarios in which skipping the authorization dialogue is 
>>> appropriate, so the example can remain.
>>> Moving on from my Discuss position, I do get the sense from the 
>>> ongoing discussion on the list that there's not clear agreement about 
>>> the current formulation that requires all parameters (but "request" 
>>> and "request_uri") to be in the JAR, especially with respect to 
>>> "client_id" that might be needed to unpack the JAR in some cases!  So 
>>> I'm not sure whether the WG wants to bring the document back to the 
>>> WG to iron out those issues before it returns to the IESG.  I'm a 
>>> little reluctant to switch my position to "No Objection" until we 
>>> have a clearer picture of what the WG wants to do on this front -- in 
>>> my understanding, we can't really publish the document without at 
>>> least some solution ("client_id") for the encrypted-request key-lookup case.
>>> Thanks,
>>> Ben
>>> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
>>>> Hi
>>>> Took a long time but finally all the changes needed to resolve the
>>>> comments are (hopefully) applied as -20.
>>>> There is one change that impacts the process: the draft now has IANA 
>>>> request so it needs to be referred back to IANA.
>>>> The IETF datatracker status page for this draft is:
>>>> Best,
>>>> Nat Sakimura
>>>> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker <>rg>:
>>>>> Benjamin Kaduk has entered the following ballot position for
>>>>> draft-ietf-oauth-jwsreq-19: Discuss
>>>>> When responding, please keep the subject line intact and reply to 
>>>>> all email addresses included in the To and CC lines. (Feel free to 
>>>>> cut this introductory paragraph, however.)
>>>>> Please refer to
>>> C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&amp;sd
>>> ata=6ZSWckU9w8S1oDEUz%2BgKPguV2UFjyfzKrOIt9V4qXRQ%3D&amp;reserved=0
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>> The document, along with other ballot positions, can be found here:
>>>>> 6612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63716077521867674
>>>>> 0&amp;sdata=eaeSN%2BgKTCDiy502GPNm459JjYuOj5o77Tp%2B6QAw3HY%3D&amp;
>>>>> reserved=0
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>> DISCUSS:
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>> This is a "discuss discuss" -- it's an important question and I'd 
>>>>> like to talk about it, but it's not clear that any change to the 
>>>>> document will be needed.
>>>>> Once this (and some of the more substantive items in the Comment
>>>>> section) is resolved, I'd be happy to ballot Yes.
>>>>> The introduction notes as an advantage of JWT that:
>>>>>   (d)  (collection minimization) The request can be signed by a third
>>>>>        party attesting that the authorization request is compliant
>>> with
>>>>>        a certain policy.  For example, a request can be 
>>>>> pre-examined
>>> by
>>>>>        a third party that all the personal data requested is strictly
>>>>>        necessary to perform the process that the end-user asked for,
>>>>>        and statically signed by that third party.  The authorization
>>>>>        server then examines the signature and shows the conformance
>>>>>        status to the end-user, who would have some assurance as to the
>>>>>        legitimacy of the request when authorizing it.  In some cases,
>>>>>        it may even be desirable to skip the authorization dialogue
>>>>>        under such circumstances.
>>>>> I'm pretty uncomfortable about suggesting that the authorization 
>>>>> dialogue can/should be skipped; do we need to keep this example?
>>>>> Maybe just talking about what an expected use case could be would 
>>>>> help alleviate my unease.
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>> COMMENT:
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>> Section 1
>>>>>   While it is easy to implement, the encoding in the URI does not
>>> allow
>>>>>   application layer security with confidentiality and integrity
>>>>>   protection to be used.  While TLS is used to offer communication
>>>>> nit: this wording is a little hard to read; it might be easier to 
>>>>> reorder to "does not allow application layer security to be used to 
>>>>> provide confidentiality and integrity protection".
>>>>>   The use of application layer security allows requests to be prepared
>>>>>   by a third party so that a client application cannot request more
>>>>>   permissions than previously agreed.  This offers an additional
>>> degree
>>>>>   of privacy protection.
>>>>> (side note) what would an example of such a third party be.  (We
>>> already
>>>>> have the resource owner, the client, and the authorization server ...
>>>>> maybe it's a fourth party?)
>>>>>   Furthermore, the request by reference allows the reduction of over-
>>>>>   the-wire overhead.
>>>>> We only barely mentioned by-reference at this point (one line in 
>>>>> the Abstract), so I'd suggest "passing the request by reference".
>>>>>   (4)  its development status that it is an RFC and so is its
>>>>>        associated signing and encryption methods as [RFC7515] and
>>>>>        [RFC7516]
>>>>> nit: I'd suggest "its development status as a Proposed Standard, 
>>>>> along with the associated signing and encryption methods [RFC7515]
>>> [RFC7516]."
>>>>>   (c)  (confidentiality protection) The request can be encrypted so
>>>>>        that end-to-end confidentiality can be provided even if the TLS
>>>>>        connection is terminated at one point or another.
>>>>> nit: TLS is always terminated at or before the user-agent, though.  
>>>>> So maybe the user agent needs to get called out here as well (there 
>>>>> could of course be TLS termination earlier than the user-agent in 
>>>>> some cases, too).
>>>>>   2.  When the client does not want to do the crypto.  The
>>>>>       Authorization Server may provide an endpoint to accept the
>>>>>       Authorization Request through direct communication with the
>>>>>       Client so that the Client is authenticated and the channel 
>>>>> is
>>> TLS
>>>>>       protected.
>>>>> How can you "not want to do [the] crypto" but still be doing TLS 
>>>>> (with crypto)?  Perhaps we're looking for "not want to pay the 
>>>>> additional overhead of JWS/JWE cryptography on top of TLS"?
>>>>> Section 1.1
>>>>> RFC 8174 has updated BCP 14 boilerplate text to use.
>>>>> Section 3
>>>>> nit: should this section be 2.3 to get wrapped into "terminology"?
>>>>> It might also be worth putting references in for the terms, though 
>>>>> they are largely common knowledge at this point.
>>>>> Section 4
>>>>>   A Request Object (Section 2.1) is used to provide authorization
>>>>>   request parameters for an OAuth 2.0 authorization request.  It MUST
>>>>>   contains all the OAuth 2.0 [RFC6749] authorization request
>>> parameters
>>>>>   including extension parameters.  The parameters are represented 
>>>>> as
>>>>> nit: "all the parameters" kind of sounds like "all that are defined".
>>>>> But I think the intent here is "any parameter used to process the 
>>>>> request must come from the request object and URL query parameters 
>>>>> are ignored", so maybe "MUST contain all the parameters (including
>>> extension
>>>>> parameters) used to process the OAuth 2.0 [RFC6749] authorization 
>>>>> request; parameters from other sources MUST NOT be used", akin to 
>>>>> what we say down in Sections 5 and 6.3.
>>>>> But we need to be careful about the wording to not exclude the 
>>>>> usage of the "request" and "request_uri" query parameters to  find 
>>>>> the Request Object!
>>>>>   the JWT claims.  Parameter names and string values MUST be 
>>>>> included
>>>>> nit: maybe "the JWT claims of the object"?
>>>>>   any extension parameters.  This JSON [RFC7159] constitutes the JWT
>>>>>   Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
>>>>>   signed or signed and encrypted.
>>>>> nit: I  think we want "This JSON [RFC7159] object".
>>>>> (Long quote incoming)
>>>>>   The following is an example of the Claims in a Request Object before
>>>>>   base64url encoding and signing.  Note that it includes extension
>>>>>   variables such as "nonce" and "max_age".
>>>>>     {
>>>>>      "iss": "s6BhdRkqt3",
>>>>>      "aud": ";;sdata=L2bwEdfW4tbnTI5FSJTCC%2BkI3EA6CqNNqZ5FzT0JnRs%3D&amp;reserved=0",
>>>>>      "response_type": "code id_token",
>>>>>      "client_id": "s6BhdRkqt3",
>>>>>      "redirect_uri": ";;sdata=XBvLTF0JuNuz7I3c7pBel0GNSN0lcYqvoHCNagAwrSU%3D&amp;reserved=0",
>>>>>      "scope": "openid",
>>>>>      "state": "af0ifjsldkj",
>>>>>      "nonce": "n-0S6_WzA2Mj",
>>>>>      "max_age": 86400
>>>>>     }
>>>>>   Signing it with the "RS256" algorithm results in this Request Object
>>>>>   value (with line wraps within values for display purposes only):
>>>>>     eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
>>>>>     F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
>>>>>     c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
>>>>>     JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
>>>>>     bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
>>>>>     Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
>>>>>     ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
>>>>>     ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
>>>>>     Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
>>>>>     wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
>>>>>     ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
>>>>>     sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
>>>>>     dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
>>>>>     luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
>>>>>     F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
>>>>>     KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
>>>>>     0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
>>>>>     ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
>>>>>     iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>>>>> Decoding the base64 of the body, we see:
>>>>> {
>>>>> "iss": "s6BhdRkqt3",
>>>>> "aud": 
>>>>> "
>>>>> %7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011d
>>>>> b47%7C1%7C0%7C637160775218676740&amp;sdata=L2bwEdfW4tbnTI5FSJTCC%2B
>>>>> kI3EA6CqNNqZ5FzT0JnRs%3D&amp;reserved=0",
>>>>> "response_type": "code id_token",
>>>>> "client_id": "s6BhdRkqt3",
>>>>> "redirect_uri": 
>>>>> "
>>>>> d011db47%7C1%7C0%7C637160775218676740&amp;sdata=XBvLTF0JuNuz7I3c7pB
>>>>> el0GNSN0lcYqvoHCNagAwrSU%3D&amp;reserved=0",
>>>>> "scope": "openid",
>>>>> "state": "af0ifjsldkj",
>>>>> "nonce": "n-0S6_WzA2Mj",
>>>>> "max_age": 86400,
>>>>> "claims":
>>>>>  {
>>>>>   "userinfo":
>>>>>    {
>>>>>     "given_name": {"essential": true},
>>>>>     "nickname": null,
>>>>>     "email": {"essential": true},
>>>>>     "email_verified": {"essential": true},
>>>>>     "picture": null
>>>>>    },
>>>>>   "id_token":
>>>>>    {
>>>>>     "gender": null,
>>>>>     "birthdate": {"essential": true},
>>>>>     "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>>>>>    }
>>>>>  }
>>>>> }
>>>>> I'm not sure where the "claims" claim is coming from -- 6749 
>>>>> doesn't seem to talk about it.  (Note that this example is used 
>>>>> later on as
>>>>> well.)
>>>>> Section 5.2.1
>>>>>   It is possible for the Request Object to include values that are to
>>>>>   be revealed only to the Authorization Server.  As such, the
>>>>>   "request_uri" MUST have appropriate entropy for its lifetime.  For
>>>>>   the guidance, refer to of [RFC6819].  It is RECOMMENDED
>>>>>   that it be removed after a reasonable timeout unless access control
>>>>>   measures are taken.
>>>>> It sounds like a link to 
>>>>>;;sdata=QtofXDXbUc2U2ieJYh0wFHXGivLFuU64GhsxCW9pD9M%3D&amp;reserved=0 might also be useful.
>>>>> Section 5.2.2
>>>>> Do we want to remind the reader that the other query parameters are
>>> just
>>>>> for backwards compatibility?
>>>>> Section 5.2.3
>>>>>   The following is an example of this fetch process:
>>>>>     GET /request.jwt HTTP/1.1
>>>>>     Host:
>>>>> It's useful to show good hygeine in examples; can we get the extra 
>>>>> entropy in this request that we have in the previous example(s)?
>>>>> Section 6.2
>>>>>   The Authorization Server MUST perform the signature validation 
>>>>> of
>>> the
>>>>>   JSON Web Signature [RFC7515] signed request object.  For this, the
>>>>>   "alg" Header Parameter in its JOSE Header MUST match the value 
>>>>> of
>>> the
>>>>>   pre-registered algorithm.  The signature MUST be validated against
>>>>>   the appropriate key for that "client_id" and algorithm.
>>>>> Does "the pre-registered algorithm" concept exist in the specs 
>>>>> outside of draft-ietf-oauth-jwt-bcp?
>>>>> Section 9
>>>>> The error codes we list in Section 7 are already registered, for the
>>>>> OIDC usage.  Do we want to say anything about that?   (I guess it would
>>>>> be disallowed by process to try to update the existing registration 
>>>>> to also point at this document.)
>>>>> Section 10
>>>>> We probably also want to reference draft-ietf-oauth-jwt-bcp.
>>>>> Section 10.1
>>>>>   When sending the authorization request object through "request"
>>>>>   parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>>>>>   using JWE [RFC7516] with then considered appropriate algorithm.
>>>>> Up in Section 5 we only allow (a) signed and (b) signed then 
>>>>> encrypted; similarly, in Section 4 we reiterate "signed then 
>>>>> encrypted".  Why is
>>> it
>>>>> okay to talk about just "signed or encrypted" here?
>>>>> Section 10.2
>>>>>   (b)  Verifying that the symmetric key for the JWE encryption is the
>>>>>        correct one if the JWE is using symmetric encryption.
>>>>> Similarly to the previous point, you also need to check the 
>>>>> signature, which will always be there.
>>>>>   (d)  Authorization Server is providing an endpoint that provides a
>>>>>        Request Object URI in exchange for a Request Object.  In 
>>>>> this
>>>>> I don't think this is a complete sentence (and it's definitely not 
>>>>> a parallel construction with (a)-(c)!).  I think perhaps a crisp 
>>>>> one-line summary of this method would be "Delegating the 
>>>>> authorization check to
>>> a
>>>>> separate "Request Object to Request Object URI" endpoint on the 
>>>>> Authorization Server".  (The writing in the rest of this paragraph
>>> could
>>>>> also use an editing pass.)
>>>>>   (e)  A third party, such as a Trust Framework Provider, provides an
>>>>>        endpoint that provides a Request Object URI in exchange for a
>>>>>        Request Object.  The same requirements as (b) above apply.  In
>>>>>        addition, the Authorization Server MUST know out-of-band that
>>>>>        the Client utilizes the Trust Framework Operator.
>>>>> The Authorization Server also has to trust the third-party provider 
>>>>> to actually do its job and not misbehave, right?
>>>>> Section 10.3
>>>>> I'm not entirely sure what "[t]he endpoints ithat come into 
>>>>> question in this specification" is supposed to mean -- is it just 
>>>>> "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"?
>>>>>   In [RFC6749], while Redirection URI is included, others are not
>>>>>   included in the Authorization Request.  As the result, the same
>>>>>   applies to Authorization Request Object.
>>>>> nit: included in what?
>>>>> Section 10.4
>>>>> It's probably also worth citing the generic URI security 
>>>>> considerations from RFC 3986, here.
>>>>> Section 10.4.1
>>>>>   "request_uri", and (d) do not perform recursive GET on the
>>>>>   "request_uri".
>>>>> nit: remove the "do" in order to make the construction parallel.
>>>>> Section 12.1
>>>>>   It is often hard for the user to find out if the personal data asked
>>>>>   for is strictly necessary.  A Trust Framework Provider can help the
>>>>>   user by examining the Client request and comparing to the proposed
>>>>>   processing by the Client and certifying the request.  After the
>>>>>   certification, the Client, when making an Authorization Request, can
>>>>>   submit Authorization Request to the Trust Framework Provider to
>>>>>   obtain the Request Object URI.
>>>>> side note: In my head the act of certification was the act of 
>>>>> making
>>> the
>>>>> translation to a Request Object URI, so I'm kind of curious where 
>>>>> my vision differs from reality.
>>>>> The third paragraph seems to mostly just be describing the 
>>>>> procedure of how this flow works, which would not necessarily be 
>>>>> specific to the privacy considerations section.
>>>>> Section 12.2.2
>>>>>   Even if the protected resource does not include a personally
>>>>>   identifiable information, it is sometimes possible to identify the
>>>>>   user through the Request Object URI if persistent per-user Request
>>>>>   Object URI is used.  A third party may observe it through 
>>>>> browser
>>>>> nit: need an article for "persistent per-user Request Object URI" 
>>>>> (or make it plural, as "URIs are used").
>>>>>   Therefore, per-user Request Object URI should be avoided.
>>>>> nit: I think this is better as "static per-user Requeste Object URIs"
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list