Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

From: Justin Richer <[email-masked]>
Date: Tue, 1 Oct 2019 22:35:52 +0000

To be clear, PAR is not the same as XYZ. Both are going to be inputs into the conversation under txauth, and there are similarities, but they shouldn’t be conflated.

In PAR, the result has to be a URI because that’s what JAR defines as the input. With XYZ, you get returned two things: a transaction handle and an interaction URI. These are both opaque to the client.

— Justin

On Sep 30, 2019, at 8:33 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

I can understand the request URI being a URI that the client is providing the AS, but why would the client's request URI be at the AS?

As Justin has explained it in the past, the AS is returning a handle to the transaction. The only party that understands that handle as far as I know is the AS. It is meaningless to the client. Perhaps I am missing something else?
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=1389dd2f-e62a-4fac-a19a-a53f3277aa24]ᐧ

On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge <[email-masked]<mailto:[email-masked]>> wrote:
So although for this spec, request_uri is just an opaque string, it is defined more generally in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:

 Absolute URI from which the Request Object (Section 2.1) can be obtained

And in section 5.2 as:

The "request_uri" value MUST be either URN as defined in
   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230
   [RFC7230] .  The "request_uri" value MUST be reachable by the
   Authorization Server.

So this is why in the spec we have example of a URN and we have an ongoing discussion as to whether we should have a standard urn namespace that we recommend implementers use.

In the interest of keeping the specs in sync I think it makes sense to keep it a URN for this spec, but with more of an explanation as to why?

Dave

On Fri, 27 Sep 2019 at 19:22, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
If I understand the proposal correctly, the request URI is opaque to the client. Correct?

If so, why not just treat it as an opaque string?

If I were implementing the protocol, I would have the blob be a signed token so that I could verify the integrity before making a database call. It much easier to throw compute at a DDOS attack to verify a signature, than DB capacity.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=432ca2fb-c1d5-411f-aa84-23542ebab7e1]ᐧ

On Thu, Sep 26, 2019 at 2:24 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Yes, the request object is JWT-based, but the request URI is not. In other words, you can post a JWT but what you get back is a URI, not the JWT itself.  The request URI was always meant to be a reference, and originally it was explicitly a reference to a signed request object.

— Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

The URI is intended to be a reference not a value.. If the client could send a JWT it would just send a request object instead of a request URI in the first place. So the intent is that it’s random, and maybe we should just say that explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.

----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com/>

On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Aaron, some comments inline.

— Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"

Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone would be
confused about copypasting the exact string from the "request_uri"
response into the "request_uri" parameter even if it didn't start with
"urn:". If, for whatever reason, it is required that this value is
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just
"urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
using the text "example" because they don't understand why it's there,
and then it serves no purpose really.’

This field must be a URI, as per JAR:

  request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
     points to the Request Object (Section 2.1) that holds
     authorization request parameters stated in section 4 of OAuth 2.0
     [RFC6749].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an HTTP GET on the request URI, so that will need to be fixed in JAR before it goes forward. I don’t think that was always the case though, and I’m not sure how that changed.

As for the namespace, “example” is ok for an example URN. The problem with URNs is that nobody really understands how to do domain-safe fully compliant URNs. So perhaps we should instead use “urn:fdc:example.com<http://example.com>:….” Instead (as per https://tools.ietf.org/html/rfc4198).

The pushed authorization request endpoint shall be a RESTful API

I would drop the term RESTful and just say "HTTP API", as this
description is arguably RESTful at best.

Depending on client type and authentication method, the request might
also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

Not quite, those differences are for the token endpoint, and this is capturing things from the authorization endpoint. I don’t quite understand the differentiation listed here either, though.

The "request_uri" value MUST be generated using a cryptographically
strong pseudorandom algorithm

I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"? If so,
it's probably worth spelling that out as it kind of reads like it has
to be literally a random string at first glance.

The URI is intended to be a reference not a value. If the client could send a JWT it would just send a request object instead of a request URI in the first place. So the intent is that it’s random, and maybe we should just say that explicitly.

That's all for now, thanks!

----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com/>
@aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
<[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpoint”, that allows the client to push the Authorization Request payload with the AS on a backchannel connection instead of a front channel interaction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization requests to refer to the pushed request data.

We believe this simple mechanism will significantly increase OAuth security and robustness since any application can use it by just sending the parameters in the same encoding as used at the authorisation endpoint over a HTTPS-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used to push signed and encrypted request objects to the AS, i.e. it provides an interoperable way to use request objects managed at the AS for use cases requiring an even higher security level.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sakimura" <[email-masked]<mailto:[email-masked]>>, "Brian Campbell" <[email-masked]<mailto:[email-masked]>>, "Torsten Lodderstedt" <[email-masked]<mailto:[email-masked]>>, "Dave Tonge" <[email-masked]<mailto:[email-masked]>>, "Filip Skokan" <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-lodderstedt-oauth-par-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-par
Revision: 00
Title: OAuth 2.0 Pushed Authorization Requests
Document date: 2019-09-21
Group: Individual Submission
Pages: 12
URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00<https://tools.ietf..org/html/draft-lodderstedt-oauth-par-00>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par

Abstract:
This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct
request and provides them with a request URI that is used as
reference to the data in a subsequent authorization request.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--

---

From: Takahiko Kawasaki <[email-masked]>
Date: Fri, 4 Oct 2019 17:11:06 -0700

Hi Torsten,

>2.3.1.5.  Request entity too large
>
>   If the request size was beyond the upper bound that the authorization
>   server allows, the authorization server shall return a "413 Request
>   Entity Too Large" HTTP error response.

"413 Request Entity Too Large" should be changed to "413 Payload Too Large".
c.f.
https://bitbucket.org/openid/fapi/issues/256/pushed-request-object-payload-too-large

>   also include the "client_id" parameter.  The "request_uri"
>   authorization request parameter MUST NOT be provided in this case
>   (see Section 3).

How about changing to:

*the request might also include other request parameters such as the
"client_id" parameter, the "client_secret" parameter, the
"client_assertion" parameter, and so on.*

Taka

On Tue, Oct 1, 2019 at 3:36 PM Justin Richer <[email-masked]> wrote:

> To be clear, PAR is not the same as XYZ. Both are going to be inputs into
> the conversation under txauth, and there are similarities, but they
> shouldn’t be conflated.
>
> In PAR, the result has to be a URI because that’s what JAR defines as the
> input. With XYZ, you get returned two things: a transaction handle and an
> interaction URI. These are both opaque to the client.
>
> — Justin
>
> On Sep 30, 2019, at 8:33 AM, Dick Hardt <[email-masked]> wrote:
>
> I can understand the request URI being a URI that the client is providing
> the AS, but why would the client's request URI be at the AS?
>
> As Justin has explained it in the past, the AS is returning a handle to
> the transaction. The only party that understands that handle as far as I
> know is the AS. It is meaningless to the client. Perhaps I am missing
> something else?
> ᐧ
>
> On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge <[email-masked]>
> wrote:
>
>> So although for this spec, request_uri is just an opaque string, it is
>> defined more generally in
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
>>
>> * Absolute URI from which the Request Object (Section 2.1) can be
>>> obtained*
>>
>>
>> And in section 5.2 as:
>>
>>
>>> *The "request_uri" value MUST be either URN as defined in *
>>> *   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 *
>>> *   [RFC7230] .  The "request_uri" value MUST be reachable by the **
>>>  Authorization Server.*
>>
>>
>> So this is why in the spec we have example of a URN and we have an
>> ongoing discussion as to whether we should have a standard urn namespace
>> that we recommend implementers use.
>>
>> In the interest of keeping the specs in sync I think it makes sense to
>> keep it a URN for this spec, but with more of an explanation as to why?
>>
>> Dave
>>
>> On Fri, 27 Sep 2019 at 19:22, Dick Hardt <[email-masked]> wrote:
>>
>>> If I were implementing the protocol, I would have the blob be a signed
>>> token so that I could verify the integrity before making a database call.
>>> It much easier to throw compute at a DDOS attack to verify a signature,
>>> than DB capacity.
>>>
>>> ᐧ
>>>
>>> On Thu, Sep 26, 2019 at 2:24 PM Justin Richer <[email-masked]> wrote:
>>>
>>>> Yes, the request object is JWT-based, but the request URI is not. In
>>>> other words, you can post a JWT but what you get back is a URI, not the JWT
>>>> itself.  The request URI was always meant to be a reference, and originally
>>>> it was explicitly a reference to a signed request object.
>>>>
>>>> — Justin
>>>>
>>>> On Sep 26, 2019, at 10:03 AM, Aaron Parecki <[email-masked]> wrote:
>>>>
>>>> The URI is intended to be a reference not a value.. If the client could
>>>> send a JWT it would just send a request object instead of a request URI in
>>>> the first place. So the intent is that it’s random, and maybe we should
>>>> just say that explicitly.
>>>>
>>>>
>>>> aaronparecki.com
>>>> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <[email-masked]> wrote:
>>>>
>>>>
>>>> On Sep 26, 2019, at 8:30 AM, Aaron Parecki <[email-masked]> wrote:
>>>>
>>>> Hi Torsten,
>>>>
>>>> Somewhat awkwardly, the JAR spec currently states that the AS has to do
>>>> an HTTP GET on the request URI, so that will need to be fixed in JAR before
>>>> it goes forward. I don’t think that was always the case though, and I’m not
>>>> sure how that changed.
>>>>
>>>> As for the namespace, “example” is ok for an example URN. The problem
>>>> with URNs is that nobody really understands how to do domain-safe fully
>>>> compliant URNs. So perhaps we should instead use “urn:fdc:example.com:….”
>>>> Instead (as per https://tools.ietf.org/html/rfc4198).
>>>>
>>>>
>>>> Not quite, those differences are for the token endpoint, and this is
>>>> capturing things from the authorization endpoint. I don’t quite understand
>>>> the differentiation listed here either, though.
>>>>
>>>>
>>>> The URI is intended to be a reference not a value. If the client could
>>>> send a JWT it would just send a request object instead of a request URI in
>>>> the first place. So the intent is that it’s random, and maybe we should
>>>> just say that explicitly.
>>>>
>>>>
>>>> aaronparecki.com
>>>> <[email-masked]> wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> It proposes a new endpoint, called "pushed authorization request
>>>> endpoint”, that allows the client to push the Authorization Request payload
>>>> with the AS on a backchannel connection instead of a front channel
>>>> interaction. The AS provides the client with a request URI (according to
>>>> draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization
>>>> requests to refer to the pushed request data.
>>>>
>>>> We believe this simple mechanism will significantly increase OAuth
>>>> security and robustness since any application can use it by just sending
>>>> the parameters in the same encoding as used at the authorisation endpoint
>>>> over a HTTPS-protected and (for confidential clients) mutually
>>>> authenticated connection to the AS. It can also be used to push signed and
>>>> encrypted request objects to the AS, i.e. it provides an interoperable way
>>>> to use request objects managed at the AS for use cases requiring an even
>>>> higher security level.
>>>>
>>>> From: [email-masked]
>>>> To: "Nat Sakimura" <[email-masked]>, "Brian Campbell" <
>>>> [email-masked]>, "Torsten Lodderstedt" <
>>>> [email-masked]>, "Dave Tonge" <[email-masked]>, "Filip
>>>> Skokan" <[email-masked]>
>>>>
>>>>
>>>> URL:
>>>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
>>>> Htmlized:
>>>> <https://tools.ietf..org/html/draft-lodderstedt-oauth-par-00>
>>>> Htmlized:
>>>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par
>>>>
>>>>
>>>> Abstract:
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>> [email-masked]
>>>> [email-masked]
>>>> [email-masked]
>>> [email-masked]
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Oct 2019 01:12:36 +0000

So in doing an implementation of this, I ran into this problem as well. Specifically, we need to know which client we’re dealing with to fully validate the encrypted request object as well as perform the authentication. Currently, things are a little underspecified, and part of that comes from the history of this document: in the previous FAPI spec, the (required) signature of the request object acted as de-facto authentication for the client. In PAR, we not only can’t rely on the request itself being signed, we also require handling of client authentication in its many forms. That means the client ID could show up in any combination of:

 - Form parameter
 - Authorization header
 - Client assertion’s “iss" field
 - Request object’s “client_id” (and “iss”) field

If several of these are sent, they need to be consistent. And whatever value comes out needs to be consistent with the client’s authentication method.

But because JAR allows you to send in a request that is only a request object, it also seems like you could pass in just the request object with no other parameters, if I’m reading this right, which would imply that you could be expected to glean the client ID from the request object itself without it being in either a parameter or in another part of the request that’s easily accessed.

So herein lies the problem. In order to properly process the request object, you need to know which client you’re dealing with so you can validate the signing algs, keys, and all that. For signed requests that’s simple enough — parse in one step, then authenticate the client, then validate the signatures. But for encrypted JWTs it’s less clear: some methods would use only the server’s public key, but symmetric encryption algorithm/encoding pairs would use the client secret as the pairwise secret for the encryption. Which means that we need to know which client sent the request before the decryption happens.

Which in turn implies one of two things are true:

 - You can’t do a request object when it’s encrypted using a symmetric algorithm
 - You have to require the client ID from some other part of the request, such as a form parameter, auth header, or client assertion; the client_id in the request object cannot be counted on as being sufficient

In our current draft implementation of PAR, I’m turning off support for symmetric encryption in this one code path. If we can somehow count on being able to find a client_id every time, then we can refactor our implementation to parse and handle all the client stuff :before: handling the request object itself. In other words, if I always have to send something that identifies the client in addition to the request object, then I can count on that.

Thoughts?

— Justin

On Sep 30, 2019, at 11:21 AM, Brian Campbell <bcampbell=[email-masked]<mailto:bcampbell=[email-masked]>> wrote:

What this is trying to convey is that because client authentication at this Pushed Authorization Request Endpoint happens the same way as at the token endpoint (and other endpoints called directly by the client) the client_id parameter will sometimes be present but not necessarily as some types of client auth use the client_id parameter (none, client_secret_post, tls_client_auth, self_signed_tls_client_auth) and some don't (client_secret_basic, client_secret_jwt, private_key_jwt).

Although the draft does later say "The AS MUST validate the request the same way as at the authorization endpoint" which I think could reasonably be interpreted as requiring client_id.  e.g., https://tools.ietf.org/html/rfc6749?#section-4..1.1<https://tools.ietf.org/html/rfc6749?#section-4.1.1> & https://tools.ietf.org/html/rfc6749?#section-4.2.1

So perhaps the sentence in question should be removed and have client_id be a required parameter at the PAR endpoint.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Thu, 10 Oct 2019 09:07:00 +0200

> If several of these are sent, they need to be consistent.

Given that client authentication precedes processing the rest of the
request, if several client authentication methods are provided (header +
secret or secret + assertion, etc) you generally reject the request, don't
you?

Then there's the requirement for the client_id given by authentication
method (none is still an "authentication" method - client_id in the body)
to match the `iss` and `client_id` in the request object. That's already
required by JAR processing rules and also PAR.

> But because JAR allows you to send in a request that is only a request
object, it also seems like you could pass in just the request object with
no other parameters, if I’m reading this right, which would imply that you
could be expected to glean the client ID from the request object itself
without it being in either a parameter or in another part of the request
that’s easily accessed.

It was only in the original FAPI revision of PAR that allowed the request
object's signature to substitute client authentication, in the individual
draft published to IETF that's not the case anymore - hence if "only" a
request object is passed - with no client authentication (header, client_id
in body, mtls) you fail the request.

As far as requiring client_id, here's what my implementation does

> When providing form-encoded parameters - client_id must be present in the
form.
> When providing signed/encrypted request object - client_id must be
present in the request object.

I wouldn't mind always requiring client_id, and i'm not worried about it
not matching e.g. the authorization header because the client
authentication middleware in place already takes care of that.

S pozdravem,
*Filip Skokan*

On Thu, 10 Oct 2019 at 03:13, Justin Richer <[email-masked]> wrote:

> So in doing an implementation of this, I ran into this problem as well.
> Specifically, we need to know which client we’re dealing with to fully
> validate the encrypted request object as well as perform the
> authentication. Currently, things are a little underspecified, and part of
> that comes from the history of this document: in the previous FAPI spec,
> the (required) signature of the request object acted as de-facto
> authentication for the client. In PAR, we not only can’t rely on the
> request itself being signed, we also require handling of client
> authentication in its many forms. That means the client ID could show up in
> any combination of:
>
>  - Form parameter
>  - Authorization header
> If several of these are sent, they need to be consistent. And whatever
> value comes out needs to be consistent with the client’s authentication
> method.
>
> But because JAR allows you to send in a request that is only a request
> object, it also seems like you could pass in just the request object with
> no other parameters, if I’m reading this right, which would imply that you
> could be expected to glean the client ID from the request object itself
> without it being in either a parameter or in another part of the request
> that’s easily accessed.
>
> So herein lies the problem. In order to properly process the request
> object, you need to know which client you’re dealing with so you can
> validate the signing algs, keys, and all that. For signed requests that’s
> simple enough — parse in one step, then authenticate the client, then
> validate the signatures. But for encrypted JWTs it’s less clear: some
> methods would use only the server’s public key, but symmetric encryption
> algorithm/encoding pairs would use the client secret as the pairwise secret
> for the encryption. Which means that we need to know which client sent the
> request before the decryption happens.
>
>  - You have to require the client ID from some other part of the request,
> such as a form parameter, auth header, or client assertion; the client_id
> in the request object cannot be counted on as being sufficient
>
> In our current draft implementation of PAR, I’m turning off support for
> symmetric encryption in this one code path. If we can somehow count on
> being able to find a client_id every time, then we can refactor our
> implementation to parse and handle all the client stuff :before: handling
> the request object itself. In other words, if I always have to send
> something that identifies the client in addition to the request object,
> then I can count on that.
>
> Thoughts?
>
> — Justin
>
> On Sep 30, 2019, at 11:21 AM, Brian Campbell <
> bcampbell=[email-masked]> wrote:
>
>
>
> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki <[email-masked]> wrote:
>
> What this is trying to convey is that because client authentication at
> this Pushed Authorization Request Endpoint happens the same way as at the
> token endpoint (and other endpoints called directly by the client) the
> client_id parameter will sometimes be present but not necessarily as some
> types of client auth use the client_id parameter (none, client_secret_post,
> tls_client_auth, self_signed_tls_client_auth) and some don't
> (client_secret_basic, client_secret_jwt, private_key_jwt).
>
> Although the draft does later say "The AS MUST validate the request the
> same way as at the authorization endpoint" which I think could reasonably
> be interpreted as requiring client_id.  e.g.,
> https://tools.ietf.org/html/rfc6749?#section-4..1.1
> <https://tools.ietf.org/html/rfc6749?#section-4.1.1> &
> https://tools.ietf.org/html/rfc6749?#section-4.2.1
>
> So perhaps the sentence in question should be removed and have client_id
> be a required parameter at the PAR endpoint.
>
>
> *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
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Oct 2019 16:59:30 +0000

Thanks for the response. My concern is that interpretation of the requirement to “authenticate the client” could be interpreted in the FAPI draft’s sense, which is to say validating the signature on the request object and not doing anything else.

The problem comes from the fact that we’re effectively smashing together the conditions and assumptions of both the authorization endpoint and token endpoint into a new endpoint. It’s going to be messy, and we need to be very pedantic about what we mean if this draft is going to be implementable.

— Justin

> If several of these are sent, they need to be consistent.

Given that client authentication precedes processing the rest of the request, if several client authentication methods are provided (header + secret or secret + assertion, etc) you generally reject the request, don't you?

Then there's the requirement for the client_id given by authentication method (none is still an "authentication" method - client_id in the body) to match the `iss` and `client_id` in the request object. That's already required by JAR processing rules and also PAR.

> But because JAR allows you to send in a request that is only a request object, it also seems like you could pass in just the request object with no other parameters, if I’m reading this right, whic…

It was only in the original FAPI revision of PAR that allowed the request object's signature to substitute client authentication, in the individual draft published to IETF that's not the case anymore - hence if "only" a request object is passed - with no client authentication (header, client_id in body, mtls) you fail the request.

> When providing form-encoded parameters - client_id must be present in the form.
> When providing signed/encrypted request object - client_id must be present in the request object.

I wouldn't mind always requiring client_id, and i'm not worried about it not matching e.g. the authorization header because the client authentication middleware in place already takes care of that.

S pozdravem,
Filip Skokan

On Thu, 10 Oct 2019 at 03:13, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
So in doing an implementation of this, I ran into this problem as well. Specifically, we need to know which client we’re dealing with to fully validate the encrypted request object as well as perform the authentication. Currently, things are a little underspecified, and part of that comes from the history of this document: in the previous FAPI spec, the (required) signature of the request object acted as de-facto authentication for the client. In PAR, we not only can’t rely on the request itself being signed, we also require handling of client authentication in its many forms. That means the client ID could show up in any combination of:

 - Form parameter
 - Authorization header

Thoughts?

— Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Oct 2019 17:01:39 +0000

In a related note, JAR currently allows “client_id” to be optional for exactly the reason of it being included in the request object. However, it falls into the same issue where you can’t decrypt the request object without knowing which client’s keys to use, and you can’t know which client you’re dealing with without decrypting the object. I think that probably needs to be addressed in JAR.

— Justin

On Oct 10, 2019, at 12:59 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

— Justin

S pozdravem,
Filip Skokan

 - Form parameter
 - Authorization header

Thoughts?

— Justin

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 22 Oct 2019 19:43:14 +0300

Thank you Justin for pointing this out. We had the exact same issue when
we implemented encrypted JAR  - and ended up requiring the client_id. In
the absence of a client_id as top level parameter symmetric encryption
cannot be handled because there's no good way to find out the
client_client secret (unless we try all possible secrets, which is not
feasible).

We also have a policy to require_request_uri_registration=true and to
avoid creating indices also require the client_id for request_uri requests.

Vladimir

On 10/10/2019 20:01, Justin Richer wrote:
> In a related note, JAR currently allows “client_id” to be optional for
> exactly the reason of it being included in the request object.
> However, it falls into the same issue where you can’t decrypt the
> request object without knowing which client’s keys to use, and you
> can’t know which client you’re dealing with without decrypting the
> object. I think that probably needs to be addressed in JAR.
>
> — Justin
>
>> Thanks for the response. My concern is that interpretation of the
>> requirement to “authenticate the client” could be interpreted in the
>> FAPI draft’s sense, which is to say validating the signature on the
>> request object and not doing anything else. 
>>
>> The problem comes from the fact that we’re effectively smashing
>> together the conditions and assumptions of both the authorization
>> endpoint and token endpoint into a new endpoint. It’s going to be
>> messy, and we need to be very pedantic about what we mean if this
>> draft is going to be implementable. 
>>
>> — Justin
>>
>>> request, if several client authentication methods are provided
>>> (header + secret or secret + assertion, etc) you generally reject
>>> the request, don't you?
>>>
>>> Then there's the requirement for the client_id given by
>>> authentication method (none is still an "authentication" method -
>>> client_id in the body) to match the `iss` and `client_id` in the
>>> request object. That's already required by JAR processing rules and
>>> also PAR.
>>>
>>> > But because JAR allows you to send in a request that is only a
>>> request object, it also seems like you could pass in just the
>>> request object with no other parameters, if I’m reading this right,
>>> which would imply that you could be expected to glean the client ID
>>> from the request object itself without it being in either a
>>> parameter or in another part of the request that’s easily accessed. 
>>>
>>> It was only in the original FAPI revision of PAR that allowed the
>>> request object's signature to substitute client authentication, in
>>> the individual draft published to IETF that's not the case anymore -
>>> hence if "only" a request object is passed - with no client
>>> authentication (header, client_id in body, mtls) you fail the request.
>>>
>>> I wouldn't mind always requiring client_id, and i'm not worried
>>> about it not matching e.g. the authorization header because the
>>> client authentication middleware in place already takes care of that.
>>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>>     So in doing an implementation of this, I ran into this problem
>>>     as well. Specifically, we need to know which client we’re
>>>     dealing with to fully validate the encrypted request object as
>>>     well as perform the authentication. Currently, things are a
>>>     little underspecified, and part of that comes from the history
>>>     of this document: in the previous FAPI spec, the (required)
>>>     signature of the request object acted as de-facto authentication
>>>     for the client. In PAR, we not only can’t rely on the request
>>>     itself being signed, we also require handling of client
>>>     authentication in its many forms. That means the client ID could
>>>     show up in any combination of:
>>>
>>>      - Form parameter
>>>      - Authorization header
>>>     If several of these are sent, they need to be consistent. And
>>>     whatever value comes out needs to be consistent with the
>>>     client’s authentication method.
>>>
>>>     But because JAR allows you to send in a request that is only a
>>>     request object, it also seems like you could pass in just the
>>>     request object with no other parameters, if I’m reading this
>>>     right, which would imply that you could be expected to glean the
>>>     client ID from the request object itself without it being in
>>>     either a parameter or in another part of the request that’s
>>>     easily accessed. 
>>>
>>>     So herein lies the problem. In order to properly process the
>>>     request object, you need to know which client you’re dealing
>>>     with so you can validate the signing algs, keys, and all that.
>>>     For signed requests that’s simple enough — parse in one step,
>>>     then authenticate the client, then validate the signatures. But
>>>     for encrypted JWTs it’s less clear: some methods would use only
>>>     the server’s public key, but symmetric encryption
>>>     algorithm/encoding pairs would use the client secret as the
>>>     pairwise secret for the encryption. Which means that we need to
>>>     know which client sent the request before the decryption happens. 
>>>
>>>      - You have to require the client ID from some other part of the
>>>     request, such as a form parameter, auth header, or client
>>>     assertion; the client_id in the request object cannot be counted
>>>     on as being sufficient
>>>
>>>     In our current draft implementation of PAR, I’m turning off
>>>     support for symmetric encryption in this one code path. If we
>>>     can somehow count on being able to find a client_id every time,
>>>     then we can refactor our implementation to parse and handle all
>>>     the client stuff :before: handling the request object itself. In
>>>     other words, if I always have to send something that identifies
>>>     the client in addition to the request object, then I can count
>>>     on that.
>>>
>>>     Thoughts?
>>>
>>>     — Justin
>>>
>>>>     On Sep 30, 2019, at 11:21 AM, Brian Campbell
>>>>     <bcampbell=[email-masked]
>>>>     <mailto:bcampbell=[email-masked]>> wrote:
>>>>
>>>>
>>>>
>>>>     On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki
>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>     What this is trying to convey is that because client
>>>>     authentication at this Pushed Authorization Request Endpoint
>>>>     happens the same way as at the token endpoint (and other
>>>>     endpoints called directly by the client) the client_id
>>>>     parameter will sometimes be present but not necessarily as some
>>>>     types of client auth use the client_id parameter (none,
>>>>     client_secret_post, tls_client_auth,
>>>>     self_signed_tls_client_auth) and some don't
>>>>     Although the draft does later say "The AS MUST validate the
>>>>     request the same way as at the authorization endpoint" which I
>>>>     think could reasonably be interpreted as requiring client_id. 
>>>>     e.g., https://tools.ietf.org/html/rfc6749?#section-4..1.1
>>>>     So perhaps the sentence in question should be removed and have
>>>>     client_id be a required parameter at the PAR endpoint.
>>>>
>>>>
>>>>     /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
>>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
> https://www.ietf