I just want to add that the requirement to validate the request at PAR the same way as you would at the auth endpoint is something that I want to see relaxed, and I hope it doesn’t make it through to the final standard.
Also keep in mind that this is barely started as a WG document so any requirement is soft at best. When discussing things like this, we should keep this in mind by discussing the consequences of having a phrase in there, not behaving as if things are unchangeable. — Justin > On Jan 6, 2020, at 4:59 PM, Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org> 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: > The request object is passed by reference, and accessible on the public > Internet. > 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. > The AS requires request object encryption to minimize exposure to the hosted > PAR endpoint service it uses. > #2, but the threat vector is gaps in end-to-end TLS. > 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 > <mailto:neil.mad...@forgerock.com>> > Date: Monday, January 6, 2020 at 6:29 AM > To: Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> > Cc: "Richard Backman, Annabelle" <richa...@amazon.com > <mailto:richa...@amazon.com>>, Nat Sakimura <n...@sakimura.org > <mailto:n...@sakimura.org>>, Dave Tonge <dave.to...@moneyhub.com > <mailto:dave.to...@moneyhub.com>>, Torsten Lodderstedt > <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>, oauth > <oauth@ietf.org <mailto: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 >>> <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 >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
