+1 This feels like it has similar requirements and concerns as for SET and may be should leverage it to avoid confusion and inconsistencies down the road.
Phil > On Sep 4, 2019, at 12:49 PM, Justin Richer <[email protected]> wrote: > > As I’ve said in the past, I think there is and should be a clear difference > between a JWT access token and a JWT-formatted response from any endpoint. It > gets extra fuzzy here because the response from the endpoint represents the > token being introspected. > > However, I think they are still two very different things because the > introspection response by definition represents what the token was at the > time of introspection. That’s why the “active” claim is important here, along > with the timestamp information in the JWT container — you can say that the > token *was* active at the time of introspection, but you can’t say it’s still > active without introspecting the token again to check. This leads to exactly > the kind of collision that’s being discussed here. It’s confusing for > developers of both the AS and the RS, and I fear it’s going to lead to an AS > choosing one interpretation and an RS choosing another, and therefore leaving > open a door to security issues down the road. > > Also, remember one of the main reasons that we require some form of RS > authentication to the token endpoint is that different RS’s can get different > answers for the same token. The AS can tailor its response based on what > scopes the RS is supposed to know about, or which RS’s can know a user’s > identifier (or even use pairwise identifiers), or even which RS is supposed > to know about a given token at all. In each of these cases, using this draft, > you’ll get a different JWT out for the same token on the way in. You’re not > simply translating an access token to another access token here — if you want > to do that, use token exchange and do it properly with an OAuth grant. > Instead, you’re getting information about the token itself at the time of the > request and from the perspective of the requestor, and you happen to be > wrapping the response in a container that is also widely used to format > access tokens. > > The separation that Torsten points out below brings up one of the biggest > problems with JWTs as a data container format — all the information about the > JWT itself is mixed in with the thing it’s carrying information about. We see > this issue with JAR, where the “aud” parameter can mean the audience of the > authorization request and the audience of the JWT used to carry the > authorization request. We also see this a little bit in dynamic client > registration’s software statement. Root-level JWT claims are a poor mechanism > for this. > > In retrospect, what I wish we’d done with all of them using a named payload > like with SET’s “event” claim. Even there, we had a lot of argument about a > “sub” claim inside the “event” object vs. one at the root of the JWT > container, but at least in these cases we now had an opportunity to write > clear language about what each meant in each circumstance. I realize this > draft is already well along in its process, and I haven’t put in the review > time or comments to date myself, but I think it’s unfortunate that the draft > doesn’t define a sub-claim like “access_token” or “token_information” to > carry inside the JWT payload. This would solve the problem of differentiating > the “iat” for the token itself vs. the JWT container of the response. > > The group may also recall that I originally said that this draft should not > be done in light of only introspection, and instead should be a generic > mechanism across OAuth’s various endpoints. Weird combinations like the “iat” > claim here are a driver for having a solid generic mechanism instead of a > handful of slightly different definitions. > > So what should we do here? If we are to keep the current practice of putting > everything in the root of the JWT, we should have different claim names to > differentiate the envelope and the token. The problem here is that “iat” is > already defined in RFC7662 as referring to the token and in RFC7519 as > referring to the JWT (which is not a token, but the container for the token > information). I’m not sure which is worse, defining an “iat” for the > introspection response or one for the JWT but only in this instance. Both > feel really messy, and in cases like Torsten’s they collapse to the same > value. > > If however we put the introspection response in its own sub-section of the > JWT payload, then we could avoid the namespace collision entirely. We would > need normative rules like in SET to define how these fields relate to each > other, but I see that as a tractable problem with a reasonable (if imperfect) > precedent. > > Either path means redoing WGLC and the associated reviews, I’m afraid. > Leaving it as-is works for the driving use case where the information is all > the same, but I don’t find it to be a particularly clean representation of > the information in question. > > — Justin > >> On Sep 4, 2019, at 5:21 AM, Torsten Lodderstedt <[email protected]> >> wrote: >> >> Hi Remco, >> >>> On 31. Aug 2019, at 21:27, Schaar, R.M. (Remco) - Logius >>> <[email protected]> wrote: >>> >>> Hello Torsten, >>> >>> (my apologies for making a typo previously) >> >> Thanks :-) >> >>> >>> Time of introspection is critical if you want to use the signed >>> introspection >>> response for later accountability or audit purposes. For example, a Client >>> obtains an access token A at time t. Now a resource server receives A at >>> time >>> t+1, calls introspection and receives a response containing active=true. At >>> t+2 the acccess token is revoked. At time t+3 the resource server makes a >>> new >>> introspection request, now receives a response containing active=false.. The >>> only difference would be the value of the active parameter. Without the time >>> of introspection nor a unique id covered by the signature, one cannot make a >>> conclusive distinction between subsequent responses if revocation may be in >>> play. >> >> That’s a good point. >> >>> >>> The draft specifies >>> [...] to return responses as JWTs. >>> This could either mean "the response is returned in JWT format" or "the >>> response contains a JWT representation of the inspected token”. >> >> I'm meanwhile leaning towards "the response is returned in JWT format”. >> >>> Not having >>> clear, separate parameters to distinguish between the time and id of the >>> token and the time and id of the response results in double meaning. As a >>> consequence, it is either having the risk of replay of an access token or >>> replay of an introspection response instead of neither. >> >> I’m not sure how an attacker could replay an introspection response given it >> is tighted to a certain endpoint via the iss claim. >> >> I agree the RS lacks a way to proof when it was provided with the access >> token data by the AS. >> >> The problem in my opinion is the overlay between the original access token >> data (e.g. when was it issued by the AS) and the data belonging to the >> representation in the introspection response (when was the response >> created). Conceptually, this means we require two separat “iat" (alike) >> claims to distinguish both aspects. >> >> I could image two ways to handle this: >> - add another iat claim, e.g. “tir_iat", to the JWT >> - add another “iat" claim to the JWS header containing the instant when the >> token introspection response was created >> >> What do you think? >> >> best regards, >> Torsten. >> >>> >>> Kind regards, >>> Remco schaar >>> >>> -----Oorspronkelijk bericht----- >>> Van: Torsten Lodderstedt <[email protected]> >>> Verzonden: woensdag 28 augustus 2019 11:14 >>> Aan: Schaar, R.M. (Remco) - Logius <[email protected]> >>> CC: [email protected] >>> Onderwerp: Re: [OAUTH-WG] Question regarding >>> draft-ietf-oauth-jwt-introspection-response-05 >>> >>> Hi Rhemco, >>> >>>> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius >>>> <[email protected]> wrote: >>>> >>>> Hello Thorsten, >>>> >>>> Thank you for your response. I have a few more questions/comments as >>>> follow-up... >>>> >>>> You state that RFC7519 and RFC7662 "just" define different representations >>>> for token data. If the draft RFC would refer to RFC 7515 (JWS), I would >>>> agree. However, RFC7519 (JWT) explicitly adds semantics to some specific >>>> parameters (e.g. aud, jti and iat). RFC7662 has different semantics for >>>> the several of the same parameters. >>>> For instance the 'iat', is the moment of issuance of the JWT in RFC7519.. >>>> In >>>> RFC7662 that is the "when this token was originally issued". This time will >>>> vary in use cases without immediate introspection of an access token. >>> >>> I read the text differently. In my interpretation “when the token was >>> originally issued” stated from the perspective of the introspection >>> endpoint refers exactly to the same instant as “the time at which the JWT >>> was >>> issued”. >>> >>>> >>>> For the use case of the resource server relying on verifiable data, as >>>> described in the introduction of the draft RFC, the time of the >>>> introspection >>>> is critical. >>> >>> Why is this time critical? >>> >>>> In particular when combined with revocation, the time of >>>> introspection and the 'active' status can differ between two subsequent >>>> calls >>>> for introspection. >>> >>> The status at token introspection request time is indeed critical. RFC 7662 >>> gives a good indication how this value should be calculated. >>> >>> “… a "true" >>> value return for the "active" property will generally indicate >>> that a given token has been issued by this authorization server, >>> has not been revoked by the resource owner, and is within its >>> given time window of validity (e.g., after its issuance time and >>> before its expiration time)." >>> >>> So it represents the results of the issuer check, the revocation check and >>> the validity check in one boolean value. >>> >>>> >>>> If the draft RFC just produces a JWT representation of the access token, >>>> including 'active' would not make sense as the JWT will expire without >>>> updating it to false. Leaving 'active' out would make it incompatible with >>>> RFC7662 introspection responses. >>> >>> “active” is not part of the JWT representation I referred to. The AS needs >>> to determine the active value for every token introspection request. >>> >>> If the RS would consume JWTs, it would determine the “active” value itself >>> by inspecting the iss claim and check against its AS whitelist, check the >>> signature and the iat & exp values. Determining the revocation status would >>> require an information exchange with the AS of some sort. >>> >>>> Similar, not including a unique 'jti' per introspection response would make >>>> the resource server vulnerable to replay attacks. >>> >>> To the contrary, including a different “jit" with every token introspection >>> response would make the RS vulnerable to replay of one time access token >>> since it remove the possibility for the RS to identity a certain access >>> token. >>> >>>> Or the resource server >>>> would mistakenly refer to non-unique tokens, making the responses >>>> unsuitable >>>> for accountability and audit purposes. >>>> >>>> >>>> As to why someone would want to distinguish a JWT access token from an >>>> introspection response: several use cases come to mind. >>>> >>>> First of all, even if one is using standalone interpretable JWT access >>>> tokens, >>>> one may want to combine that with revocation checking using introspection. >>>> The >>>> interpretation and meaning of the JWT and the introspection response than >>>> do >>>> differ and matter. >>> >>> As I described above, I don’t see any difference. >>> >>>> >>>> Another use case would be a mixed ecosystem with resource servers relying >>>> on >>>> introspection while others do parse JWT access tokens. A single, uniform >>>> implementation for the AS would than mix both as well. >>> >>> See above - I don’t see any issue. >>> >>>> >>>> A last use case could be exchanging access tokens with a subset of the full >>>> set of applicable parameters, to reduce the size of access tokens. >>>> Additional >>>> information can be exchanged via introspection, resulting in mixed JWT >>>> access >>>> tokens and introspection as well. >>> >>> That’s all possible within the current text. >>> >>> kind regards, >>> Torsten >>> >>>> >>>> Kind regards, >>>> Remco Schaar >>>> >>>> -----Oorspronkelijk bericht----- >>>> Van: Torsten Lodderstedt <[email protected]> >>>> Verzonden: zaterdag 17 augustus 2019 14:00 >>>> Aan: Schaar, R.M. (Remco) - Logius <[email protected]> >>>> CC: [email protected] >>>> Onderwerp: Re: [OAUTH-WG] Question regarding >>>> draft-ietf-oauth-jwt-introspection-response-05 >>>> >>>> Hi Remco, >>>> >>>>> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius >>>>> <[email protected]> wrote: >>>>> >>>>> Hello, >>>> >>>> [...] >>>> RFC 7519 and RFC 7662 “just” define different representations for token >>>> data. In RFC 7519 the data is carried in the token itself (which also >>>> means the format of the token is well-defined and know to the RS) whereas >>>> RFC 7662 defines a way to inspect tokens via an API provided by the AS. >>>> The latter is typically used in conjunction with opaque tokens, i.e. the >>>> RS does not have a clue how to parse and interpret the token. The token >>>> might just be a handle to a database entry at the AS in this case. >>>> >>>> This also means a JWT (RFC 7662) and the Introspection Response are >>>> conceptually the same from a RSs perspective. >>>> >>>> [...] >>>> >>>>> The ‘jti’ parameter however will always be ambiguous. As it is an >>>>> identifier, it should differ for the introspected token and the >>>>> introspection response by definition. Hence the semantics of ‘jti’ in a >>>>> JWT introspection response is unclear. The same can apply to the ‘iat’, >>>>> ‘nbf’ and ‘exp’ claims in a JWT introspection response. >>>> >>>> I don’t understand the difference you are making. All before mentioned >>>> claims are related to the (abstract) access token. You may think of the >>>> Introspection Response as _the_ JWT representation of the access token >>>> produced by the AS for the RS. >>>> >>>>> >>>>> Can someone clarify the semantics of claims in an introspection response >>>>> JWT that are defined in both RFC7662 and RFC7519? >>>>> >>>>> Furthermore, the introspection response should use the ‘iss’ and ‘aud’ >>>>> claims to avoid cross-JWT confusion (section 6.1). The ‘iss’ and ‘aud’ of >>>>> an introspected token will typically be the same as those of the >>>>> introspection response. Hence a JWT access token cannot be distinguished >>>>> from an introspection response using ‘iss’ and ‘aud’ as suggested in the >>>>> draft.. >>>>> >>>>> Introspection refers to JWT best-current-practice. The draft BCP >>>>> recommends using explicit typing of JWTs, however the draft JWT response >>>>> for introspection does not apply this recommendation and uses the generic >>>>> ‘application/jwt’ instead... The BCP has other recommendations in section >>>>> 3.12, but these may be insufficient to distinguish a JWT access token >>>>> from a JWT introspection response. >>>> >>>> Good point. The reason why the BCP recommends explicit typing is to >>>> prevent replay in other contexts. In the end typing is a compelling >>>> concept unfortunately not broadly used in the wild. >>>> >>>> So the JWT Introspection Response draft copes with that attack angle by >>>> making iss and aud mandatory. >>>> >>>> >>>>> >>>>> How would people suggest to best distinguish a JWT (access) token from a >>>>> JWT introspection response? >>>> >>>> Why should you? One reason why we extended the Introspection Response was >>>> to eliminate the difference between JWTs directly used as access tokens >>>> and Introspection Responses. >>>> >>>> best regards, >>>> Torsten. >>>> >>>> >>>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u >>>> niet de geadresseerde bent of dit bericht abusievelijk aan u is >>>> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht >>>> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van >>>> welke aard ook, die verband houdt met risico's verbonden aan het >>>> elektronisch verzenden van berichten. >>>> This message may contain information that is not intended for you. If you >>>> are not the addressee or if this message was sent to you by mistake, you >>>> are requested to inform the sender and delete the message. The State >>>> accepts no liability for damage of any kind resulting from the risks >>>> inherent in the electronic transmission of messages. >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=0_FcucFstqzt0Hyr3ivbMX8i4a2La24tYRek5n-Xgvs&s=LTwDtpeHVz9jDIok9JOtN6dd1TS4i-3VoZLPdt6L2Ns&e= >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
