I agree with Brian here, I think “typ”:”JWT” should be permitted as well as no typ and “typ”: "oauth.authz.req+jwt".
There are other tests we could write for JAR that an OIDC server will fail (for example, one that tested the behaviour of passing a value only outside the request object - which an OIDC server would process, but one compliant with JAR [or FAPI-RW] would ignore the value outside). I don’t see having one more case of this as an issue - some servers will not be JAR compliant, and hence would fail tests that test JAR-specific behaviour. I also agree with Brian about requiring AS to reject request objects that have a sub that’s a client_id, this doesn’t seem to cause significant interoperability concerns as it is hopefully unlikely that any client is doing so. I could possibly see an argument for weakening the requirement for an AS to reject a request object with sub=client_id to a ’should’ (rather than a must) given there is a small chance it could end up breaking an ecosystem, but I’m not entirely convinced. Joseph > On 17 Aug 2020, at 23:55, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > I might suggest that thinking about it in the context of interoperability > would be more meaningful than certification tests. > > Saying that an AS MUST reject the Request object if it has a typ header and > the value of the header is not ‘oauth.authz.req+jwt’ [1] should allow for > interoperability with respect to JWT typing between all combinations of > existing and updated clients with existing and updated authorization servers. > > Saying that an AS MUST NOT include a sub with client id as the value would > break for an updated authorization server when receiving such a request > object JWT. But that's erroneous and potentially dangerous behaviour from the > client so I don't know that we need to try and maintain interoperability > there. > > [1] Unfortunately "typ":"JWT" would probably also need to be allowed. As best > I understand it "typ":"JWT" basically says "this JWT is a JWT", which isn't > useful for explicit typing and I think makes it effectively equivalent to an > untyped JWT. I've honestly never understood why one would use "typ":"JWT" but > it shows up in a lot of places including examples and explanations on sites > like jwt.io <http://jwt.io/> so it seems very likely that it'd just get > copied over and show up in some amount of real world request object JWTs. > > > On Sat, Aug 15, 2020 at 10:41 AM Mike Jones > <Michael..Jones=40microsoft....@dmarc.ietf.org > <mailto:40microsoft....@dmarc.ietf.org>> wrote: > Answering Filip and Vladirmir’s question about adding normative language > around “typ” and “sub”: Anytime you add a new required feature, you are > breaking existing deployments. Suppose we added the normative requirement > “If a ‘typ’ header parameter is present, ASs MUST reject the Request object > if its value is not ‘oauth.authz.req+jwt’”. One could then write a > certification test sending the AS a different “typ” value – which to pass, > ASs would have to reject the JWT. Every existing deployment would fail this > test! That’s exactly what we don’t want to have happen. > > > > Brian asked for security considerations. The IESG asked for security > considerations. I added them in the PR – working with Nat and John. They > point the way to the future without breaking existing deployments. That’s as > it should be. > > > > -- Mike > > > > From: OAuth <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> On > Behalf Of Warren Parad > Sent: Saturday, August 15, 2020 9:27 AM > To: Vladimir Dzhuvinov <vladi...@connect2id.com > <mailto:vladi...@connect2id.com>> > Cc: oauth <oauth@ietf.org <mailto:oauth@ietf.org>> > Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > > > In the case of > > if the Request Object includes a sub claim with the value of the client_id > the AS MUST reject the request > > > > What would the expectation be in terms of a client_credentials grant? > > > > From experience, the sub is frequently populated with the client_id value and > the client_id is not used. Which would mean breaking for that type of grant > wouldn't it? > > > > > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. Implement > Authress <https://bit.ly/37SSO1p>. > > > > > > On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov <vladi...@connect2id.com > <mailto:vladi...@connect2id.com>> wrote: > > +1 to make the "typ" check, as Filip suggested, normative, as existing client > and RP deployments with undefined "typ" will not be affected. New deployments > should be encouraged to type the JWT, and thus be made safer. > > > > Regarding the "sub != client_id" check -- could a simple rejection of all > JWTs with "sub" present suffice? > > I find it difficult to imagine what else a client could end up setting the > "sub" claim to, if it does end up populating it for some reason. > > Rejecting JWTs with "sub=client_id" or "sub" present will break deployments > where a client for some reason sets the "typical" JWT claims, and "sub" is a > typical one, but if those deployments happen to accept client_secret_jwt or > private_key_jwt client authentication, they could well be vulnerable to > cross-JWT confusion attacks. > > > > Vladimir > > On 14/08/2020 13:58, Filip Skokan wrote: > > Hi Mike, Nat, > > > > I thought we would go as far as making these normative requirements > > if the Request Object includes a sub claim with the value of the client_id > the AS MUST reject the request > if the Request Object is explicitly typed (typ) its value MUST be ... > First rejects client assertions to be passed as Request Objects. Second > rejects all future typed JWT profiles from being used as Request Objects > without worrying about the claims they may or may not contain. > > > > Or is that breaking? > > > > S pozdravem, > Filip Skokan > > > > > > On Fri, 14 Aug 2020 at 00:59, Mike Jones > <Michael..Jones=40microsoft....@dmarc.ietf.org > <mailto:40microsoft....@dmarc.ietf.org>> wrote: > > At Nat's request, I've created a pull request addressing Cross-JWT Confusion > security considerations. It addresses both Brian's comment and the IESG > comments about explicit typing. See the full PR > athttps://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10 > <https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10>. See the source > diffs at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml > > <https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml>. > Please review! > > This is only the first commit, albeit, one that addresses some of the must > substantive issues. More commits will follow addressing additional IESG > comments. > > -- Mike > > -----Original Message----- > From: OAuth <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> On > Behalf Of Benjamin Kaduk > Sent: Thursday, August 13, 2020 2:59 PM > To: Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> > Cc: draft-ietf-oauth-jws...@ietf.org > <mailto:draft-ietf-oauth-jws...@ietf.org>; oauth-cha...@ietf.org > <mailto:oauth-cha...@ietf.org>; The IESG <i...@ietf.org > <mailto:i...@ietf.org>>; oauth <oauth@ietf.org <mailto:oauth@ietf.org>> > Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on > draft-ietf-oauth-jwsreq-26: (with COMMENT) > > Oops, that's my bad. Thanks for the correction -- I've linked to your > message in the datatracker (but didn't bother to have the datatracker send a > third copy of my updated-again ballot position). > > -Ben > > On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: > > While some discussion of why explicit typing was not used might be > > useful to have, that thread started with a request for security > > considerations prohibiting use of the "sub" with a client ID value. > > Because such a request JWT could be repurposed for JWT client > > authentication. And explicit typing wouldn't help in that situation. > > > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > > nore...@ietf.org <mailto:nore...@ietf.org>> wrote: > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > [updated to note that, per > > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 > > > <https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0> > > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit > > > typing is not used would be in order] > > > > > > > > > > -- > > _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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > -- > Vladimir Dzhuvinov > _______________________________________________ > 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> > > 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
