Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

Francesca Palombini <francesca.palombini@ericsson.com> Thu, 08 April 2021 09:47 UTC

Return-Path: <francesca.palombini@ericsson.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 1CC993A0AB4; Thu, 8 Apr 2021 02:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 qqWuFlQ_tRDf; Thu, 8 Apr 2021 02:47:28 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150078.outbound.protection.outlook.com [40.107.15.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2153A0AB1; Thu, 8 Apr 2021 02:47:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KLj5/EJ/BRIptKZuRjdGI05zf8b/JiGCzSl7TDAXy9kNS93hG5PhD+7noupvlsG2Bmm/mp3pL1jjnj5tEt/E8QcUP02r//aAPJn/YYbOKO7iDrjuiAPaP7hx6lKXq2ZsA1UPiWiQncqEkp0WJgjLjMQwpSyHRZRvQqOE234hCBijfcbp5uxqttThaVDoddrTBa3NroYSpTTapxdNSMMbHSuP/Et2fmBPZncavj9Z9aHxcW/jmk5H2tBCyysiRrdvMT5MO/nQDEQwG6zxdKfRgxpVdmUm8k7BCJqM4y32K9z3ttAYdAKLm+JQDwa9hLzQ+8x2fiRh129OTDHA6pr7Fw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KltulfR+gEZ237wxcc9HMErP3Vl0X2KW1MmjvpV7/J8=; b=FSZ/Sd53fAkiW9YxDPgGuNvsaWbDheHLpisVt6ChhBAXOaYpSLSieA+iJULNjkbkD70AvKsB7KE+8hDk/TwjMmdvAH+EzvIag/m/0N4zEeZp/0nlYs5rp+FxauJe+/QXnmVi0gRqAha39uUWXOm2ppXbpcGxOtzRmYL60TIQwSpUdnGPULRuVEDW/M1uXLExTUpSmzYAVOjpjQW3Ly3sUi4WskP+0zhllB4JysmYn/HOhPHQFTDOHShOIkqC7X31V9iJAKBAJqyleIkGYTp2qNldz/CY/3XoCXvdAxm7Ebwj4qebPQNDAqVMx5BL0n1zg0rLB9YFcAZMomSaTWu/kA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KltulfR+gEZ237wxcc9HMErP3Vl0X2KW1MmjvpV7/J8=; b=U0lMfiGc9FjkzZ9ZuEK2jgSafGMxi92ORWBsjOguL3aaNh6gSNfLoVXKdBoB2jPRrCZUpM1mlctb/e0bYy1Uaa7zMDHwb2EtTlS1LR2nOQE7WC1k+2Lu8fgper5I6FqYIqAuBCR8tuMZciGRlHoGAGRO4pGHVIThKMUJm6AUCXM=
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB3452.eurprd07.prod.outlook.com (2603:10a6:7:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.8; Thu, 8 Apr 2021 09:47:24 +0000
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4020.017; Thu, 8 Apr 2021 09:47:24 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-oauth-jwsreq@ietf.org" <draft-ietf-oauth-jwsreq@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>
Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)
Thread-Index: AdcsMekdJv5IcULvQ1qzavuY873M4wAOwfAA
Date: Thu, 8 Apr 2021 09:47:24 +0000
Message-ID: <B9106236-D189-4431-BBBF-5D46118453C6@ericsson.com>
References: <DM5PR00MB04213AEA322C464E10D0E02FF5749@DM5PR00MB0421.namprd00.prod.outlook.com>
In-Reply-To: <DM5PR00MB04213AEA322C464E10D0E02FF5749@DM5PR00MB0421.namprd00.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:41:17Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cdfb0104-3004-44ad-80cf-5c9eac18df57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
user-agent: Microsoft-MacOutlook/16.47.21031401
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none; microsoft.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:1ba8:147a:eb00:3c1d:e0b2:6f4d:a5e4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2ccdd39c-6ee8-45b8-5744-08d8fa735057
x-ms-traffictypediagnostic: HE1PR07MB3452:
x-microsoft-antispam-prvs: <HE1PR07MB3452906FE3D84FDF8C920B2E98749@HE1PR07MB3452.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wtCNU7xVw8Y4lE/UgDi+/d4dK+Nw/zus3lDnxmSR3IQXgyTWxX8AiHbTpjnGdBcYzsEBZBF1tevUFTAkEL7dHRLpYPXko8tCy4ugxMHP5U5O/v24+emP4PnGtWH/IH7yOp82al2BXSrZNcIdDkBcjosoRUvqrhintn3NCIrZdvi+wU/614wuwIDQ/iDDbx9XpW4UIb3yT1QEmyMX8I7SdvAaDQqSW6CykjhhpSKa7DbvCw1RQ/xHWKqm0KWxaJQXWViekj65I5MDv2M0HyltxoRVoJWLoOe9dJ9C8Xj+Kv1a0nNvT9uILkUuSN7OyWcnWmYXDsEdF1sqn4DRxN4+4AnLFlpheUcv6lWw42dfCbL5IqzEyKKbYYCo0eWba4DIRkiapK81zSQERt6NpRf4BZe+vbwxO40c8BTOrMPZu8dTFEnznuoo4WT0ZrBcPAadr3so4WmELbcqd88ebGHiuM4zTyOqR7v7tRIaiq1s5R+/DuhqmRF1Nz7dpkfTk5V5bHgnM/jv8kq7HFMn6+TviUsCLIoWhxUZmOGH9HhhpbpUZFH11G4AmKzMC3OXHtRehEUBfsL8TmvZ8hIg6eCgNmiqnpBgKINZIgWVvru7V/CLsIHIKauSzo7EWLDzHZxWMF9BoJF8gEDLLFO1HQQ2HMu4KP5ae/n6EGLXkwMslQEQhyfGd++04N4WV3FVlqQ4iS/mHbCCZHPK4K/sdv0V7A8MYtV5edm4l0T30NUMD31ORN2+zzt5Mf6P3SdrLtOMp6rEcnabJXO3PN1odkeFuQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(44832011)(8936002)(2616005)(76116006)(66476007)(186003)(110136005)(64756008)(8676002)(4326008)(66446008)(54906003)(66946007)(6512007)(316002)(66556008)(478600001)(53546011)(36756003)(966005)(33656002)(6486002)(6506007)(86362001)(83380400001)(5660300002)(2906002)(71200400001)(38100700001)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?cUFwR2lLbnoxRHNTMVZGVys2czJCSkFkdUVDbVRxcjlVSmEwWjJIcE1INTZE?= =?utf-8?B?elpwQmpYcnlNcmR4ajcybkRRMnBiNW1Xazk5eTMxTTZCR2FvdXE1WDRlVmdw?= =?utf-8?B?cHhzajJ3TGlBeStGODFPdkhIUGlvYU1pS1hzTThhOHY2VURTbmN4RUZUUnVt?= =?utf-8?B?RmNVWHMyS1VKTGhwRmczcmRpbGFhWno0VVlpN05FOHpyWit0UGlLQkszYjBq?= =?utf-8?B?bld3UW1DeTVqUkFqeHNNSXdHcjB4SWpxK2NBSkVTVHNPWkM2VVVONWY0dkJ2?= =?utf-8?B?OUNDZHNvcThNTFJCRWh1Q0p3QUtjOVQ5a2JDeXFLZ1d2MStVdjd5TnJVQ0dR?= =?utf-8?B?alp3eHk3YzNJOGVuK3EvSEhUWERTNGFxMzNHb2N1OE5BcjRWVEpKSEE3RzZ2?= =?utf-8?B?NFJKWk1XVVRNN280Zm9oQTdqTzNnblVLU0hOTkQzN3VFcHRNd2pOclFiRlJ1?= =?utf-8?B?ZzZQeXZyeEYyR3dnbVE5d0FJWDJSbDJKdUQ3THVUelRRaUU3ZDBXNmY1b0Nn?= =?utf-8?B?ZEl1VExoZjlZZ2Nqd2d3NDFqTXUzWEJFcXhxdWtwbkF4TDZ2d2VFTThPSzhl?= =?utf-8?B?QituZnRlQWViWVNlOXQ3cHJBeFIvVXl3UG55RmZtSmxldzBneWMvNEdpTmdO?= =?utf-8?B?SkcwZTZwNURqRTJlTWlheVlCZ0tMSVNCalRKdklKZm9LeXlXRkJJNVRUZU02?= =?utf-8?B?MUJlZFQ5Z1dKd05FU3hNdDcwSzRWRnpZc0toK3AyYWxqMlFVRlhQNmhBa2NX?= =?utf-8?B?WDNpWkZIV1Q0MS9XT2pta3FWRlkycDZ5bUh2RDNHMUd0OUVhUlhHUExuREt0?= =?utf-8?B?YndQb2ozT0pNVVh5OVh6Tk5Gc2tRcmdVQVJITXYya2UrUjBrZE5OYXBzSEZt?= =?utf-8?B?RFI2MlA1NEQxYkFPSGVpQzFCaVhBSDd0ZVRRbWUzaFhFa0lGMndCRlMzbFhR?= =?utf-8?B?T1B5OXhMOXhURVhpSFJGU0JmRmYwUGN6WnlyaWpQLzVBZEdxRzlrVEJJZElF?= =?utf-8?B?WFJNMENjY3BsaUtXRVNubzE3U0hmTzFpU0xISGQwcTRsbmYrdDd4SDdrT0ht?= =?utf-8?B?c3RNUi9rTERBV3hZMHN5SUMyWlAwVWh2UnBSTUFsZnFCRVVxTVhNVFdPczZF?= =?utf-8?B?TkpERlIxY2lpSjRGV0pNbVgrbzdvZnI3VnVtRlQvN3FEZkE0QTNVb2FwdXNk?= =?utf-8?B?d295SGNOWDdVY0J4bEhFeExLRFVLdmgwM1NUR1k3OUJCcmlYT0xIeGo4T291?= =?utf-8?B?K1VQa3E3eDJPcDJKTmUydU14bzJLdjFuMERNMHo4Ympydkx4SmNFTE0vWUJx?= =?utf-8?B?L2xVUjdJVTRCNWE5QVlzdGV1YW5HMXRZWUtmTUgvQThuSktDa0ZlbnFHcllQ?= =?utf-8?B?RU45eUZhVFNEZnZacWlKdHNFWG44R2VFSDFXaythVm1HSEkvRVFLUVRzY3Ew?= =?utf-8?B?bU9IRGFnaUhWZzVoeXMwSTdVQXRadzBqWVpVNWFNY1gzMWRlQ2wxUWphczl4?= =?utf-8?B?UmJTdkVENS9jRmNNRW50TC9QVGRFWEpnN1NIZ0srWlpBQU5NQUtHaVVta21O?= =?utf-8?B?K2pxSkp4STRMU2hmTzV1UmVKVlNNOVNmUUZ0cVE4citpSUxpSXM0UkNoUUU4?= =?utf-8?B?SnVNVTJod3pocFJNOWVGSXRoOTVkYTVma2grR0k4SnIyVmZZNEcvYVRLY0hZ?= =?utf-8?B?L1pjclJFUjRmdTBtdmc4QmwrcWszdnRqbTRoMFdjMGxQeE5oVFpwMVgzaFl5?= =?utf-8?B?WitLbnNvSFFFZHpLLzJWdndJQlV5S252T29XVnFRREtLaWNXUDRnUytwVnBN?= =?utf-8?B?SHljUDcvaG1jR1lJQ3FFaFk2cGxNNDR2anBuZDNvRk1vVHQ3ZGRmTmpPMFV3?= =?utf-8?B?ZlVmQzNDV20vbUVwaVpuUEtIQnhmVVR4VHhDY05Ub0JHQmc9PQ==?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <F8949F2A9AF9BA4BA5D7483BC40CDAF9@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ccdd39c-6ee8-45b8-5744-08d8fa735057
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 09:47:24.7300 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1GcQGi5fsJhnR3RR5WFg5WhDs8DJBx9VMDNBS8+76DX4gLl0v3v9ayMne5iGBaL7qI9c+RbvgT8DxEQBcNLI8prO/x422ndu2ljBzy5vsjRYt+ieU487kDX+C9X71aWm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3452
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/COJAqqkv_uz7GrFoqYjo9mLTvOw>
Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)
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: Thu, 08 Apr 2021 09:47:33 -0000

Hi Mike!

Thanks for the quick reply. It looks good to me, just one answer to point 4. :

    4. -----

       specified in the "alg" Header Parameter.  If a "kid" Header Parameter
       is present, the key identified MUST be the key used, and MUST be a
       key associated with the client.  Algorithm verification MUST be

    ...

       same parameter is provided in the query parameter.  The Client ID
       values in the "client_id" request parameter and in the Request Object
       "client_id" claim MUST be identical.  The Authorization Server then

    FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then? Same comment "... MUST be identical" - is any error returned if it's not?

    Mike> I believe that the responses to these validation errors are already described in the following paragraph, which says "If signature validation fails, the Authorization Server MUST return an 'invalid_request_object' error to the client in response to the authorization request."

FP: As I read it, the first paragraph says: 

   The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  If a "kid" Header

Then follows up with a number of other checks that need to be done (the text I quoted in my original comment). And then ends with the sentence you quoted:

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

Same for the second - the text I reported is followed by:

  The Authorization Server then
   validates the request as specified in OAuth 2.0 [RFC6749].

And then again from the text you quoted:

   If the validation fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].

So while reading I considered that the validation (either of the signature for par 1 or of the request for par 2) is separate from the additional checks. The intent of it could be made clear by a minor addition in each par:

1st paragraph:

OLD:

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

NEW:

   If signature validation fials, or if the key identified is not associated with the client, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

2nd paragraph:

OLD:

   If the validation fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].

NEW:

   If the validation of the request or the Client ID check fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].


I think this would clarify the text, but I'll leave it up to you to decide if it's worth adding.
Thanks,
Francesca

On 08/04/2021, 06:45, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

    Thanks for your review, Francesca.  We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments.

    Responses are inline below, prefixed by "Mike>".

    -----Original Message-----
    From: Francesca Palombini via Datatracker <noreply@ietf.org> 
    Sent: Wednesday, April 7, 2021 3:29 AM
    To: The IESG <iesg@ietf.org>
    Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; oauth@ietf.org; Hannes.Tschofenig@gmx.net
    Subject: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

    Francesca Palombini has entered the following ballot position for
    draft-ietf-oauth-jwsreq-32: No Objection

    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 https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS.

    Francesca

    1. -----

       A Request Object (Section 2.1) has the "mime-type" "application/

    FP: Please use "media type" instead of "mime-type" and reference
    https://tools.ietf.org/html/rfc6838

    Mike> Thanks, updated, although referencing RFC 2046 for the term "media type" (which is not superseded by RFC 6838).

    2. -----

       The following is an example of the Claims in a Request Object before
       base64url encoding and signing.  Note that it includes the extension

    FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4.

    Mike> Reference added.

    3. -----

       If decryption fails, the Authorization Server MUST return an
       "invalid_request_object" error.

    ...

       If signature validation fails, the Authorization Server MUST return
       an "invalid_request_object" error.

    ...

       If the validation fails, then the Authorization Server MUST return an
       error as specified in OAuth 2.0 [RFC6749].

    FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request
    Object) at the same time, and it can't hurt to be precise. Also regarding the reference to RFC 6749 - can you add a specific section to reference?

    Mike> Done

    4. -----

       specified in the "alg" Header Parameter.  If a "kid" Header Parameter
       is present, the key identified MUST be the key used, and MUST be a
       key associated with the client.  Algorithm verification MUST be

    ...

       same parameter is provided in the query parameter.  The Client ID
       values in the "client_id" request parameter and in the Request Object
       "client_id" claim MUST be identical.  The Authorization Server then

    FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then? Same comment "... MUST be identical" - is any error returned if it's not?

    Mike> I believe that the responses to these validation errors are already described in the following paragraph, which says "If signature validation fails, the Authorization Server MUST return an 'invalid_request_object' error to the client in response to the authorization request."

    5. -----

       location, (b) check the content type of the response is "application/

    FP: For consistency, please change "content type" to "media type".

    Mike> Done

    				Thanks again,
    				-- Mike