Agreed. In addition, I'm not sure why the PAR endpoint would need access to the decryption keys at all. If you're using encrypted request objects then the PAR endpoint receives an encrypted JWT and then later makes the same (still encrypted) JWT available to the authorization endpoint. If the PAR endpoint is doing any kind of decryption or validation on behalf of the authorization endpoint then they are clearly not in separate trust boundaries.
-- Neil > On 6 Jan 2020, at 13:57, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > I really struggle to see the assumption that an entity be able to use the > same key to decrypt the same type of message ultimately intended for the same > purpose as an artificial limit. The same general assumption underlies > everything else in OAuth/OIDC (Vladimir's post points to some but not all > examples of such). There's no reason for PAR to make a one-off exception. And > should there be some deployment specific reason that truly requires that kind > of isolation, there are certainly implementation options that aren't > compatibility-breaking. And having said all that, I'm honestly a little > surprised anyone is thinking much about encrypted request objects with PAR > as, at least with my limited imagination, there's not really a need for it. > > > > > > > > > On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org <mailto:40amazon....@dmarc.ietf.org>> > wrote: > PAR introduces an added wrinkle for encrypted request objects: the PAR > endpoint and authorization endpoint may not have access to the same > cryptographic keys, even though they're both part of the "authorization > server." Since they're different endpoints with different roles, it's > reasonable to put them in separate trust boundaries. There is no way to > support this isolation with just a single "jwks_uri" metadata property. > > The two options that I see are: > > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. > > I strongly perfer #1 as it has a very minor impact on deployments that don't > care (i.e., they just set par_jwks_uri and jwks_uri to the same value) and > failing to support this trust boundary creates an artificial limit on > implementation architecture and could lead to compatibility-breaking > workarounds. > > – > Annabelle Richard Backman > AWS Identity > > > On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" > <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org> on behalf of > torsten=40lodderstedt....@dmarc.ietf.org > <mailto:40lodderstedt....@dmarc.ietf.org>> wrote: > > Hi Filip, > > > On 31. Dec 2019, at 16:22, Filip Skokan <panva...@gmail.com > <mailto:panva...@gmail.com>> wrote: > > > > I don't think we need a *_auth_method_* metadata for every endpoint the > client calls directly, none of the new specs defined these (e.g. device > authorization endpoint or CIBA), meaning they also didn't follow the scheme > from RFC 8414 where introspection and revocation got its own metadata. In > most cases the unfortunately named `token_endpoint_auth_method` and its > related metadata is what's used by clients for all direct calls anyway. > > > > The same principle could be applied to signing (and encryption) > algorithms as well. > > > > This I do not follow, auth methods and their signing is dealt with by > using `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - there's no encryption > for the `_jwt` client auth methods. > > Unless it was meant to address the Request Object signing and > encryption metadata, which is defined and IANA registered by OIDC. PAR only > references JAR section 6.1 and 6.2 for decryption/signature validation and > these do not mention the metadata (e.g. request_object_signing_alg) anymore > since draft 07. > > Dammed! You are so right. Sorry, I got confused somehow. > > > > > PS: I also found this comment related to the same question about auth > metadata but for CIBA. > > Thanks for sharing. > > > > > Best, > > Filip > > thanks, > Torsten. > > > > > > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt > <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote: > > Hi all, > > > > Ronald just sent me an email asking whether we will define metadata for > > > > pushed_authorization_endpoint_auth_methods_supported and > > pushed_authorization_endpoint_auth_signing_alg_values_supported. > > > > The draft right now utilises the existing token endpoint authentication > methods so there is basically no need to define another parameter. The same > principle could be applied to signing (and encryption) algorithms as well. > > > > What’s your opinion? > > > > best regards, > > Torsten. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
