Just to comment that with a lightweight PAR (stash-only) endpoint one of the nice benefits of PAR will be lost - to pre-validate the request (client_id, redirect_uri, etc) as much as possible before a front-end call is made and the user is sent to the authZ endpoint.
Vladimir On 06/01/2020 23:59, Richard Backman, Annabelle wrote: > > The issue isn’t that the PAR endpoint needs access to one specific > request object decryption key that could reasonably be shared across > AS endpoints, but that it actually needs access to the private keys > for all encryption public keys in the JWK set pointed to by the AS’s > jwks_uri metadata property. Since there is no way to designate one > particular key as the one to use for encrypting request objects, > clients may reasonably use any encryption public key in the JWK set to > encrypt a request object. As one example of how this could expose > sensitive data to the PAR endpoint, if the PAR endpoint has all the > decryption keys for the keys in the AS’s JWK set, it would be able to > decrypt ID Tokens sent in id_token_hint request parameters. As more > and more use cases develop for encrypting blobs for the AS, this issue > will only get worse. > > > > The PAR endpoint can’t simply stash the encrypted request object, as > it is required to verify the request, according to §2.1: > > > > The AS MUST process the request as follows: > > ... > > 3. The AS MUST validate the request in the same way as at the > authorization endpoint. ... > > > This language needs to be more flexible, IMHO, to allow for > lightweight PAR endpoints that may not have the information or > authority needed to perform all the validation that happens at the > authorization endpoint. I need to think about this more before I can > say if it would adequately address my concerns, but it’d be a good > start and makes sense in its own right. > > > > I think it’s pretty risky for us to base decision on an assumption > that no one is going to need or want to encrypt pushed request > objects, particularly when they’re JWTs, and JWTs have well > established support for encryption, and encrypted JWTs are supported > by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you > insist, here are a few examples for why someone might want to do this: > > 1. The request object is passed by reference, and accessible on the > public Internet. > 2. The request object contains sensitive transaction-related data in > RAR parameters that the client’s authN/authZ stack doesn’t need to > have access to. > 3. The AS requires request object encryption to minimize exposure to > the hosted PAR endpoint service it uses. > 4. #2, but the threat vector is gaps in end-to-end TLS. > 5. Any of the above, but the concern is message integrity, and the AS > requires requested objects to be encrypted for confidentiality and > integrity protection and does not support signed request objects. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Neil Madden <neil.mad...@forgerock.com> > *Date: *Monday, January 6, 2020 at 6:29 AM > *To: *Brian Campbell <bcampb...@pingidentity.com> > *Cc: *"Richard Backman, Annabelle" <richa...@amazon.com>, Nat Sakimura > <n...@sakimura.org>, Dave Tonge <dave.to...@moneyhub.com>, Torsten > Lodderstedt <tors...@lodderstedt.net>, oauth <oauth@ietf.org> > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata > > > > 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 > <mailto: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 > > > */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 > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
