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

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 14 May 2020 06:57 UTC

Return-Path: <vladimir@connect2id.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 525BB3A0BD4 for <oauth@ietfa.amsl.com>; Wed, 13 May 2020 23:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OrWChVaZpVHf for <oauth@ietfa.amsl.com>; Wed, 13 May 2020 23:57:28 -0700 (PDT)
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 27BEF3A0BE1 for <oauth@ietf.org>; Wed, 13 May 2020 23:57:28 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Z7o3jXwEMf1qNZ7o5jZeNg; Wed, 13 May 2020 23:57:27 -0700
X-CMAE-Analysis: v=2.3 cv=GON27dFK c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=SMEE0oRgF1s8rFqhd5MA:9 a=swtiq8cPB2_r5MFh:21 a=wpilc7wLf2bsV4Zh:21 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <DM6PR00MB0682FB5ABDAE909C7156564DF5AB0@DM6PR00MB0682.namprd00.prod.outlook.com> <A00DFA90-F7AB-4E54-AEE0-BCD98C45BF9D@lodderstedt.net>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUVOQkZRWmFvRUJDQUNu UDJZTURleDlmbmYrbmlMZ2xUSEdLdW95cFVTVktQUWVLREhIZUZRVnpoUmtlK0hCCkVaQndt QTlUa1ora0VoeXJOcWliRFBrUFlWUG1vMjN0TThtYk5jVFZRcXBtTjdOd2dNcHFrcWNBcU5z SXlCdHQKMDlEaldPUVZtNTdBM0sreXVYSTdTZE5FcmR0NzlwMnhRc2VPaHFTQzkrTGdXdXlo K21ac2wyb0ZENGdsRkZmSwpTQ01wMmpBVFhyQU1lR3ppZ1RuVytYZTB0Unpyd0ZOOXpxeWtL eGhVcTlvSGcxY052b0R0Znhnc2M5eXNWSGJ4Ck0vUE04bzlsZ2ozWVRRd0tNQmNDRmNsVHFv aGppN01MZlEwOGVRbythY0tUd0MxV1J6ZUx0OVBrbkd0M0M0VG0KdmRDbDBjMUJRVFRUTmlG OTZIdTRrYmFpQklic2Z4Sk9SOCtWQUJFQkFBRzBMRlpzWVdScGJXbHlJRVI2YUhWMgphVzV2 ZGlBOGRteGhaR2x0YVhKQVkyOXVibVZqZERKcFpDNWpiMjAraVFFK0JCTUJBZ0FvQlFKVUdX cUJBaHNqCkJRa0paZ0dBQmdzSkNBY0RBZ1lWQ0FJSkNnc0VGZ0lEQVFJZUFRSVhnQUFLQ1JB WjB2VXlPcXJpUWw2MkIvd08KTzBzMkpDL1F2TzZ3OWlTc1JoQ09hL0paaSt3TytsMDFWN2VH Q1ExY1lmMVcyNlk3aUtpVWxZNC9LeitjcjY5RApwTXRrdjNVcERUR2VqS0Vmc3BMVXh6NVZv M1Q0b0FLYlR0TnRWSVpML1h4SDMvSmhKNzE5Smo0ZUxvZTkvZGpLCmtHWVRYMk81Yk1rOFRw TzFERGpiSXc0cjlYS0k5WklrOTZ6bEtuWnZyZzdIbzdvT2wwWklmOEF6Y3ZkcVpFVW8KZ0R3 eXI4dXdPVStqSXl1eG1PVHRoZXBCelhDTmpqQmpuYzhJMS8vOVlwcEFJYUdKNW5uWGVsVlZE MS9keU9zegpvZ2VydnpGTkFORUlPdk52Q2Q5RzV1NGVzN3FrREtXS1k3L0xqMXRGK3RNckRU ck9oNkpxVUtiR05lVFVCOERsClB2SW9OeXFIVVlmQkVMZHB3MU5kdVFFTkJGUVphb0VCQ0FE YlBQTjJjOWl5aWYxcklpQTNpK09BTDIraldsVXcKeU0xaGNmdkE5enpZZ1FDRmJsTlprM2x6 a0d1a2tDZFNneUUzZGliQjdUclAvN2NQdVNWcDRzWi8vUGRTZVlTUAowTnBVUklpOU9xajRy M0RsUjF3YVI0ZzFwVlB3WEFoWXZoc1ZEMTlSRGRNYXNZQnFlbnUrRlhUdlJLVkIzZXJYCkJv WGtCcGhoVzRla01oK0UrMjFDcDJrYUlmM1ZFNGVLOTU2NXFGVmVtNTdDdFRDcWJwTThFbExi eVFlSEVsMDcKYlRyVThCQ25tQkpyOWJnK2gwR3A2czAyUGdlYndYa2lSNWlHZEFORHJZSEVt RGozWFlkVjhWRmxuNExSSmV1agpkR3NaUXBDOWFRdUZNaEQ1Njk2aWljZWxxSGRkTkxaMFNP TG5iOEl4Y1RuVTdISWp4TXBnUEJoUEFCRUJBQUdKCkFTVUVHQUVDQUE4RkFsUVphb0VDR3d3 RkNRbG1BWUFBQ2drUUdkTDFNanFxNGtLUE13ZitQK3pmSHQxL0wrbGEKMU9zelU4TVhsYXJD SHRSd3FmMFJPd1VWQjVQbUxxR1lxWFNVTjhxWEZZMzhuSUdOaHhEL0hBeDhJWnJsWjM0RgpU OUhINjJoQjN3bXd2ek8rSkRsNjN5cTAwT0pueXdBYVJVVFNJd2M2U25UUVRndTBRU0hpZE9H NHlFWFROWERNCkUxNGtPNUZ2ZGxwNmQyL3ZSRFo3b0JjdjZiWDdnMzFIVWU1bmFpNS9qWHFR Qmlra2dJSTZtc3Q0R0w4MDNXTGEKTlZ2QVViTGdlMjVndmdkQmRQZ01wY2tOeWEweXpvOXZI TVFEREFoTm9MMWVBWjlNcUcxcXQySVZWRTRkZ0hkTgpHVWJSRVoyOFd1ci8vZ05UcGFtYTZl UnJ4N2JPdVZ4ZjRldUtiTXhUTXZIQVA2YkpkSXVlblppVDZTWkpMYnBjCmhIaCtyZ1oyclE9 PQo9WVc3NAotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
Organization: Connect2id Ltd.
Message-ID: <66c55a6c-2c02-1c6f-c8e0-19ba57c98fa4@connect2id.com>
Date: Thu, 14 May 2020 09:57:22 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <A00DFA90-F7AB-4E54-AEE0-BCD98C45BF9D@lodderstedt.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050306080606010502000209"
X-CMAE-Envelope: MS4wfGm5JMeyJlh34LZIFRpk5AnwFZfStlO4x7V8RPGCQh0CN4lVnP82YQpHZcRFmJXPIxbiPxGdJpfcGUEFbNdjrPTyYPFFSf5mvZRhzIkI174IjGPP0KEm FY3adwhAPLnnlGfzingTgbdQKYinqd/+WH00U9htcWjj5qUMScSQ7Z8y
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/WVBS6wmRTR_HGV52KS6_qCjUKeo>
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: Thu, 14 May 2020 06:57:30 -0000

+1 for require_request_objects AS metadata parameter.

The natural place for this parameter for me would be the JAR spec .

Vladimir

On 12/05/2020 09:27, Torsten Lodderstedt wrote:
> Hi all,
>
> I initially raised the question whether the AS should be able to require request objects for all clients (in the same way as we decided to let the AS required PAR for all clients) but this topic was never discussed later on. 
>
> I suggest to add a server metadata parameter “require_request_objects” so the AS can indicate its policy to clients. 
>
> I think the best place to define this parameter would be JAR, if that is not possible any longer, we could use a different PAR-specific name and add it to PAR.
>
> What do you think?
>
> best regards,
> Torsten. 
>
>> On 1. May 2020, at 17:56, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
>>
>> 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> 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> 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), 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> 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
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> 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.
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov