Re: [OAUTH-WG] PAR - Can AS/client require request object?

Mike Jones <Michael.Jones@microsoft.com> Fri, 01 May 2020 15:56 UTC

Return-Path: <Michael.Jones@microsoft.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 3EEBC3A15E5 for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 08:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=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=microsoft.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 MCDuXJwAYDm0 for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 08:56:42 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650115.outbound.protection.outlook.com [40.107.65.115]) (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 CEF483A154E for <oauth@ietf.org>; Fri, 1 May 2020 08:56:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K5drbMIgHvaW5WrccwyowaHyXBOKLz0WTP8Th+YDEw17s8SEB3nUkJuGbs/YOKl59AL7qeMCRFjYBBdUGRa9JgLZcYQ+X8v0JEpO+trDSmD+1+6GECXez+eUfQJgTftoX183IGI8DU0CdrBU52a4/CwzVrNXZ563y8wgXELBg/2xnM3SNACPGLmBoaK+qF1Q6hW9NiqZg5oBFafDdSm72hUxDR7EuKHg/wSzyEBdpruG8ll6Ap9nF8WU7ovWleWhUfdZDGznLzf75FVVI/KMhQkVRYnKdxv/U7Yw2P5DTiQIjd6ez/TLVFYZ/BwUhR8U2clxdopI/LRL73gRepXh+Q==
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=Ugtz0+8vDvLhtVKBpp7gltbIiYTKdBAMABd4dxoGLYk=; b=CB0mRC4vu1GMtR8AkXx+YY8pOVzFL6fiCLxyRXs5siRWOwfMIxEd7YvIbKY4jrfraUGwg9jusdHocFHdSygmYpmwdEqzDTin+Qq3YcvaPKUGuadgSxlGliZ8faamgNPcGtJ3xvTAUKQFUXEXVD2sL+VRlmprDC8VUCtsGOa3hOA3kEHryXWvFiSseP5KL6ad/ZyK5gtoVEQcOBawoqQ2AU9ckRhQwXPlmORkBfOuQxvIrYlKFCEDcBRZH/hMrdELyVhYtP/5r2YJFsV+yopKeF/tICnD0o751R3+WG316wa6RqfTIG/UW6CMJNJVUs/D0EdsAY4Iacqw7w915sHCfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ugtz0+8vDvLhtVKBpp7gltbIiYTKdBAMABd4dxoGLYk=; b=QlK98t2qI9vOGP+WSOL2/0ZKMaZriA6gokquxkIU17nF6fQgWxTAm9VroA/TaoBTFWjgLUGy+USAaieKk18g7EZS3JEnH8v7m/X8weyUccFnaho7WLBXUbSdFYxPIeWCgzxEUDf2au7tk3solfTm9G+tX49KsLSWCdbJ4qMOccE=
Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM5PR00MB0376.namprd00.prod.outlook.com (2603:10b6:4:a0::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2992.0; Fri, 1 May 2020 15:56:39 +0000
Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::1834:c740:72aa:48dc]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::1834:c740:72aa:48dc%8]) with mapi id 15.20.3003.000; Fri, 1 May 2020 15:56:39 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
CC: oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] PAR - Can AS/client require request object?
Thread-Index: AdYf0RcM+SMXXXDgR7umPh9q+QpXmQ==
Date: Fri, 1 May 2020 15:56:38 +0000
Message-ID: <DM6PR00MB0682FB5ABDAE909C7156564DF5AB0@DM6PR00MB0682.namprd00.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=17b1b879-5aeb-4f2a-8bc1-000040be05b2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-05-01T15:56:11Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c455573f-be6e-48c3-1332-08d7ede83c0f
x-ms-traffictypediagnostic: DM5PR00MB0376:
x-microsoft-antispam-prvs: <DM5PR00MB03767D3163220D7FE8475FC9F5AB0@DM5PR00MB0376.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 0390DB4BDA
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: avLUnNGLveuFDSeYlPUlunj6Pj6M0fXnj+e3mZ6CHGh3yG1VvfwNXeAev4SNakKeZm5y7scN3z8ZvgYDuOWXlVY/AAbSkGi5jbLFD+jv8zagfFaiyRqxDiT4o+dTaVo+0+RQNpLxwgJ50xcbpSffHrSyu78Wor+iIoQ4EffbqYFatjZbtAVuiAyK5AJrvtH6Uoev4L1AHrCrw50USkWn6aB8PiookHQFOoPgr3m3jHLpNGEyTYSmF16XX38n9JT1UZtqH+xCr9r1FpkhZF1ihH9fhpc7YSnOpSAdlcIwjvZMMxXZTtKSolFpO2Ho3X/BbCvAVXJMhI/AlDyIl+zp4c9CeBztuhfvYOUA3IVsxCfkI/LenM5WTFnC1qRWTLHnftO6NSz+KE6PUkmhdq7QOIZH59wB8tNngCmRk5+ifzoSViMyuEUeDW1aNsj6MB43R0L6G9vtpNezM6uypEX1OXOon7Gk8UA969vZRD/utsYbkVnVBMVpK+xxK/xkdQxX5Vb+kp45pWwvrKoRqfUmKw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0682.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(396003)(376002)(366004)(76116006)(5660300002)(8990500004)(66556008)(66476007)(8936002)(8676002)(64756008)(66446008)(66946007)(2906002)(86362001)(7696005)(52536014)(33656002)(966005)(71200400001)(82950400001)(316002)(66574012)(10290500003)(4326008)(9686003)(186003)(82960400001)(26005)(55016002)(6506007)(478600001)(53546011)(110136005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: ceCQf7/9gV5X+u+BCBqJ95e7+6nYiN7wAhQvq8UuEHB3L4vy3v9VOnosZ3mYgipmXqpt0g6oDYRdcI0fk97bLN/r2Vq8TZNZcUm3VWyJRgnhi/Rdr74/bSbzcLwKQ9hcfeOmrZwLUeHCAwuf1j7eBfvZDf8LsOxDi89n4b1dCTsauZ0/nNvroDEGL2bymmbj8oA29ONqriV50zq4V4l3oqQ9kMgUY/TxzGa8pJxu/bsJ5Zuo6PJ+IjQifHpYglyM0wpEHCZb6o7SqUVfaGH2cUtA/dn1cgvIQeIQixvSDKJ8xg9O6YfS6SKP9++sfqXDJeZkTCY6ZbSrXdAqZR/jbIcL/BRU8FPu+gLRP8GiU433H2OKZar7r87kscmOyUYttHhASIS+2xScKKqol+opUzcBiCNYqUsF7Y26eB1dIsCrjxkxhV75qms5k7UBMl6arlol4lWCn+58F1kzRXDX2rKVQVn7rg7d47AoDhLPW/x01FpXLtDZ9EZIOPERAtcnMCQX319EJFN/O+KYHOnzqggmZbDz0bVHlny3R455q66oo1bQn1iJncyMvcYI9DEyJ8K4G0aSH7jntjBRuM1XcSo24Pc4gmPKFAZyEBWpBTTnDnZFAOBFY2492v+sOKr+XxHNFHBQVVfbBzYIrnVK7Ifpxxmc2UR0UzVFI7a8j21D3V2+BJxvhFLXnEXrsK2z+a5cD691eTG/mBUpHF7jM6yvNaSS+r5ZXyn8To2F6VrzN73r2Q6imdQhljE4taU6Zn4QWsEUXltstc4AYo4ORajLoVit2H9KB2q/hqJ8fTo=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0682FB5ABDAE909C7156564DF5AB0DM6PR00MB0682namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0682.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c455573f-be6e-48c3-1332-08d7ede83c0f
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2020 15:56:39.0537 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 79CXMtdojvi2wYWqDKpedxAM2nNIJ+fa8x17dVoAwennHkxofiNuaLyKy7S3J6HLTaHp8kG8M2UvcCF1R5+XgA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0376
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ci7jS8cKFIojda3mMk-NW86dBtA>
Subject: Re: [OAUTH-WG] PAR - Can AS/client require 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: Fri, 01 May 2020 15:56:45 -0000

Works for me.

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
Sent: Friday, May 1, 2020 2:51 AM
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?

Filip´s proposal works for me.

Are there any objections?

Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org<mailto:40pingidentity.com@dmarc.ietf.org>> schrieb am Mo. 27. Apr. 2020 um 20:57:
While there are certainly different permutations and contexts of use that could be imagine, I tend to agree with Filip here in not seeing a strong need to define new PAR specific metadata around signing/encryption of the request object.

On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan <panva.ip@gmail.com<mailto:panva.ip@gmail.com>> wrote:
Considering there's going to be a setting that forces clients to use PAR (other mailinglist thread), then we should rely on the existing `request_object_signing_alg` presence to indicate a Request Object must be used (as suggested by this upcoming OIDC Core errata<https://bitbucket.org/openid/connect/issues/1045/signalling-that-a-request-object-must>)t>), regardless of it being PAR or JAR. I don't see the need for a PAR specific metadata, for one - implementations wouldn't be easily able to re-use of existing pipelines, two - yes the contexts differ but do you think clients will be using both channels at the same time? And even if so, the Request Object is the same therefore its applicable to both channels the same.

Best,
Filip Skokan


On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org<mailto:40lodderstedt.net@dmarc.ietf.org>> wrote:
Hi all,

this is one of the topics we quickly flipped through in the virtual meeting last week.

I see the following open questions:
- Can the client require its instances to use request objects only.
- Are there further requirements on the properties of these objects? Signed only, Signed and encrypted, algorithms?
- Can an AS require ALL clients to use request objects only?
- Further requirements here as well?
- Is this tied to PAR or relevant for JAR as well?

In my opinion, client as well as AS should be able to control enforced use of request objects.

I could imagine the setting for JAR request objects (“request" parameter) and request objects in the PAR context differ, as the first case goes through the user’s browser whereas the PAR case goes direct from client to AS via a TLS protected channel. I therefore feel the settings should be PAR specific.

What do you think?

best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.