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.org/mailman/listinfo/oauth
