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 > >> On Oct 10, 2019, at 12:59 PM, Justin Richer <jric...@mit.edu >> <mailto:jric...@mit.edu>> wrote: >> >> 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 >> >>> On Oct 10, 2019, at 3:07 AM, Filip Skokan <panva...@gmail.com >>> <mailto:panva...@gmail.com>> wrote: >>> >>> > 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 <jric...@mit.edu >>> <mailto:jric...@mit.edu>> 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 >>> - 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=40pingidentity....@dmarc.ietf.org >>>> <mailto:bcampbell=40pingidentity....@dmarc.ietf.org>> wrote: >>>> >>>> >>>> >>>> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki >>>> <aa...@parecki.com <mailto:aa...@parecki.com>> wrote: >>>> >>>> > 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. >>>> >>>> >>>> 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 >>>> 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 >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
