Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt

Brian Campbell <> Wed, 12 August 2020 17:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A22FF3A0039 for <>; Wed, 12 Aug 2020 10:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, 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 aqXLtK8CLb5Q for <>; Wed, 12 Aug 2020 10:03:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2117B3A0317 for <>; Wed, 12 Aug 2020 10:03:09 -0700 (PDT)
Received: by with SMTP id t6so3037860ljk.9 for <>; Wed, 12 Aug 2020 10:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e9i42gq+AGRw5/LxQs/MtNc3ufBqQAZOIrv8rADFiQ0=; b=BESf8aV8c9fuN7VK3+dMwri/v+fVPLU58ng81w6blUUe5j/kZHWx5dZVix6qzCeA5p RqIOXmGn8ncz/eErlPxdDwdy5TMK1DJTxsqVKFQFeJeNsrTE9MTuXf2JnXOnSCjMciLk G4KQLZL0J2LSMm/4f9OHQ4V5bdR3k+4vi74ZRF5GhNkXy5aOJ8Ys3zDshLiqjOYOe8Jj KiKVVLY79H3V4VQD0HsshC0nXHI2HqdW83ECKjH2nUcfDj0zOGMSTHQRh01n4Sug+nFt v9DX8Z2eZ5diOc6iB3QdclmgxHvFRVudT2lC9Gw1+ywfGV8rhYanCH94XjDfnmzzru7B NiUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e9i42gq+AGRw5/LxQs/MtNc3ufBqQAZOIrv8rADFiQ0=; b=ITUP0CbmWHx5aCt6cFyThKhBAs+OL4Aed8FTMVIAGW5VpgaDvg4PUjzubft29NQCpC OKNqeuOZ16bAn+QH4BFJiVmiLO8JaeMoyW+h8ZXCu4ZahG6ynWp9pd0dcERqjUcq2IFc vcZ8N17qQ0wM46CUin6ZFdrFH0IpXRgXf2PPtzVg0LIrbAOC6pNbtk0Ml4uH7D+FNf8t +i0foUIZxpHx60Z82FXf8i2HCWX1XMtNIXO/hohv/dDPxOr60CxCZ54fvfvtEXaziA7L S5bavoLScMEVVw0iYpFUEM3jVD5i+lNNaofZdD3X1y9+/ttw6QbeaSMFRsjNSVhdjPRl Ifiw==
X-Gm-Message-State: AOAM5316r1gCVPqTZXmirlNe3YaUVSRmy1dMISLt/kGKWG57EhJlHE1d AB3LMh9/YFAIqgYp1uVAxDS22xMuTbYbiWkD00AOu8WZtUd0r0xTGJC+IQWVnelIeOyhWd97gIO /hnB42Xk8/MGDfPISLjo=
X-Google-Smtp-Source: ABdhPJwKf84WZVhA+ipo9f17y78zrscnEp9q4XLFlisPvHzGn33JRu1q4MrjhWL6r3xoEUJdvw3CQcwoTn4G1TdXmJ4=
X-Received: by 2002:a05:651c:153:: with SMTP id c19mr97939ljd.170.1597251787865; Wed, 12 Aug 2020 10:03:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Wed, 12 Aug 2020 11:02:41 -0600
Message-ID: <>
To: Francis Pouatcha <>
Cc: OAuth WG <>
Content-Type: multipart/alternative; boundary="0000000000006edf7605acb12938"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt
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: Wed, 12 Aug 2020 17:03:16 -0000

I'm honestly having a hard time following what you are asking for. But
there is already the following text in sec 1 that mentions non-repudiation
via JWT-based request objects and by implication the basic request method
does not provide non-repudiation.

   The pushed authorization request endpoint fosters OAuth security by
   providing all clients a simple means for a confidential and integrity
   protected authorization request, but it also allows clients requiring
   an even higher security level, especially cryptographically confirmed
   non-repudiation, to explicitly adopt JWT-based request objects.

On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha <fpo=> wrote:

> Hello Brian,
> On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell <bcampbell=
>> wrote:
>> Hi Francis,
>> My apologies for the tardy response to this - I was away for some time on
>> holiday. But thank you for the review and feedback on the draft. I've tried
>> to respond inline below.
>> On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha <fpo=
>>> wrote:
>>> Bellow is the only remark I found from reviewing the draft draft:
>>> 2.1.  Request:
>>> requires the parameters "code_challenge" and "code_challenge_method" but
>>> mentions
>>> that RFC7636 is not required for confidential clients. I guess those
>>> two parameters have to be taken off the mandatory list and pushed to the
>>> list below.
>> The list of parameters in Section 2.1 is qualified with a "basic
>> parameter set will typically include" and is definitely not intended to
>> convey a set of required parameters. It's just a list of parameters that
>> make up a hypothetical typical request.  Perhaps some text in the section
>> or even the formatting needs to be adjusted so as to (hopefully) avoid any
>> confusion like this that the list somehow conveys normative requirements?
>>> - Using jwsreq, non repudiation is provided as request is signed (jws).
>>> This section also mentions that the request can be sent as form url
>>> encoded (x-www-form-urlencoded). In this case, there is no way
>>> to provide non repudiation unless we mention that request can be signed by
>>> client using signature methods declared by the AS (AS metadata).
>>  I am not aware of any signature methods or means of an AS declaring
>> support for a signature method in metadata that are sufficiently
>> standardized to be mentioned in the context of this draft. The "request"
>> parameter
>> can be sent to the PAR endpoint and should provide the same notation of
>> non-repudiation as does jwsreq. I think that's sufficient treatment of
>> non-repudiation for the PAR draft.
> This is the case when PAR uses "Content-type:
> application/oauth.authz.req+jwt".
> This is fine as the jws form param is signed. This is also equivalent to
> jwsreq in matter of providing non repudiation.
> Content-Type: application/x-www-form-urlencoded
> ...
> request=eyJraWQiOiJrMmJ.....3Gkk488RQohhgt1I0onw
> This is not equivalent to jwsreq. As request body is not signed. This does not provide non repudiation.
> Content-Type: application/x-www-form-urlencoded
> ...
> response_type=code&
> state=af0ifjsldkj
> It is worth mentioning this in the draft
> Best regards
> /Francis
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG

_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._