+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....@dmarc.ietf.org> wrote:
>>
>> Works for me.
>>
>>  
>>
>> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Torsten Lodderstedt
>> Sent: Friday, May 1, 2020 2:51 AM
>> To: Brian Campbell <bcampbell=40pingidentity....@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....@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...@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....@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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to