You're welcome, of course. And thanks for the prompt response. I've endeavored to continue the parts of the conversation that needed continuing below.
On Wed, Jul 24, 2019 at 3:46 PM Vittorio Bertocci <Vittorio= 40auth0....@dmarc.ietf.org> wrote: > Thank you Brian for the thorough and insightful review! > Comments: > > > On authenticated encryption. > I did chat with Neil about his draft, but as you mention I didn't > reference it given that it hasn't bee picked up (yet?). > On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My > rationale is that this profile attempts to capture current practices or > practices that are close enough to the capabilities of existing systems to > have a reasonable chance of being adopted. None of the products/services > surveyed used authenticated encryption, and the requirement to acquire a > symmetric key out of band throws a big wrench in the otherwise clear-cut > process of preparing your RS to handle JWT ATs. I will bring the matter up > as open issue on Friday, and if the consensus will be to include symmetric > authenticated encryption I'll do that; but my personal preference would be > to preserve the simplicity of a concrete, > nothing-of-substance-left-as-exercise-to-the-reader solution that can be > achieved when the key material can be advertised via metadata. > Looking to get consensus is quite reasonable, of course, and I can sympathize with the aim of simplicity. As I've said before though, I think the utility it brings is sufficient trade-off with respect to any additional complexity it brings (which is arguably not that much). And I imagine I'll continue to recommend it in situations where it makes sense regardless of where this document ends up. But, well, you know, that's just, like, my opinion, man. To set the historical record straight, however, I was among the products/services surveyed and I explicitly included several examples showing "AEAD symmetric encrypted AT". > > About the nonce mitigation you mention. Do you think this means that I > should explicitly forbid the presence of a "nonce" claim in JWT ATs? > I dunno to be honest. The actual validation of the nonce requires enough other contortions that it probably doesn't really need to be forbidden here. And proper use of aud (and maybe other stuff?) stuff also makes using a AT as an ID token infeasible. So it's okay as is as far as I can tell. But maybe forbidding nonce isn't a bad suggestion just for the sake of saying something about it and maybe avoiding some potential mix-ups. > > >I think you want to say here that the scope claim in the token has to > correlate to the scope which was approved. Not necessarily what what > requested. The authorization request might ask for scope of a+b+c, for > example, while the user only approves b. Or any other variation on things > where what was asked for isn't what was gotten.. > > Here I am trying not to get into the details of what's inside the scope > claim, more requesting that if "scope" was in the request, the issued token > should express a delegation and a symptom of that should be the presence of > the scope claim. Paradoxically that scope claim might be empty if the user > only consented to scopes that have effect on the presence of other claims > in the token (say a functional equivalent of profile). Yes, it does sound > odd, but that's a side effect of the prohibition of sending id_tokens to > API that creates the requirement to create functional equivalents. > I must admit to not 100% following all of that I want to bring it back up to the text in the draft, which to me, reads as saying that if the authz request contains a scope, then the AT SHOULD contain a scope (noting that SHOULD is still actually pretty strong language per RFC2119). I think that's too strong a correlation between something maybe in the authz request and a claim in the AT. I *think* it'd be preferable to say something similar to the effect of (and it sounds almost silly but it's not meant to), "the scope claim has the scope". Maybe something along these lines in place of the first sentence/paragraph of 2.2.2. "The issued JWT access token SHOULD/MAY/can/could/will/might include a scope claim as defined in section 4.2 of [TE], which expresses the scope of access authorized by the token." >I personally think the SHOULD is too strong here because it puts the onus > on the resource server to know about (via some config option or something) > and enforce on every transaction a setup/policy thing that the AS is > responsible for which isn't about the integrity of the authorization data > in the token. A MAY or even removing the list item would be preferred. > > I borrowed this language straight from the OpenID Connect validation steps > for idtokens. Given that JWT ATs can carry identity info, the requirement > seemed appropriate... also, I think it is reasonable to expect the resource > server to know about its own registration- just like it must know about the > expected aud value and what key should be used to decrypt messages, it > should know whether encryption was requested or not. In fact, the fact that > such option was selected at registration time is likely the reflection of a > policy of the RS itself, something the RS itself would want to ensure has > been respected. WDYT? > I was involved in a similar discussion last yearish around some product requirements and functionality. And, while I can see the merits on both sides of it, my opinion still falls squarely on the side I previously expressed. So what I think is unchanged and I believe that it's an overreach for a spec like this. Some of the details of the argument are a bit subtle though and I have a hard time putting them into writing (more than usual even). Perhaps we could try and use some of the time in Montreal to have a f2f discussion about it? Which doesn't even have to be during the official WG time. > >multi value audiences > > I see the issue. I definitely don't want to redefine the semantic of aud, > but I also would like to be as crisp as possible on the audience-scope > correlation and prevent scopes from being misinterpreted as applying to the > wrong resource. The aud validation will likely happen in some middleware in > front of the API, but authorization checks might happen in the body of the > API itself when the actual access is being attempted, and having an OR list > in the aud claim might lead to false positives. RSes correctly written > should not suffer from this issue (the authorization logic should receive > only the value from the aud collection that is an actual match) but I have > seen enough sloppy implementations to be skeptical about this. > As a result, I would be inclined to take out the sentence "or if it > contains additional audiences that are not known aliases of the resource > indicator of the current resource server", effectively restricting to > single value aud and eliminating this issue. > While I guess I am still somewhat skeptical about the need to further constrain the use of audience, it seems that ship has sailed. I do find it much more palatable to constrain aud to a single value than to redefine the semantics of a multi-valued aud. -- _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
