I suspect a variety of not-entirely-improbable rational could be provided to explain why it might make sense. But the reality is that it's just a mistake in the document where somewhere along the way updates were made to the examples that didn't fully align with content already in those examples. I try to be careful with details like that but apparently wasn't careful enough in this case.
On Thu, May 23, 2024 at 5:45 AM Tomasz Kuczyński < [email protected]> wrote: > The introspection response should rather reflect facts related to the > access token sent for the introspection. So even in case, a new > authentication event took place after the token issuance, it should not be > included in the response as the authentication event is not related to the > introspected access token. > The inclusion of that information in the introspection response should be > treated as a vulnerability. > > Regardless of the above, the "exp" in response is also earlier than the > "auth_time", which means that the introspected token is beyond the time > window of its validity and in fact, the introspection response should > contain nothing more than {"active": false}. > > Best regards > Tomasz Kuczyński > W dniu 23.05.2024 o 01:06, Justin Richer pisze: > > This seems to be logical - the authentication event would always be before > the token was issued in the usual case. However, assuming that the AS > "upgrades" an existing token in-place during a step up, isn't it possible > for the latest relevant authentication event to come after the token was > initially issued? > > - Justin > ------------------------------ > *From:* RFC Errata System <[email protected]> > <[email protected]> > *Sent:* Wednesday, May 22, 2024 2:30 PM > *To:* [email protected] <[email protected]> <[email protected]>; > [email protected] <[email protected]> > <[email protected]>; [email protected] <[email protected]> > <[email protected]>; [email protected] <[email protected]> > <[email protected]>; [email protected] > <[email protected]> <[email protected]>; > [email protected] <[email protected]> > <[email protected]> > *Cc:* [email protected] <[email protected]> > <[email protected]>; [email protected] <[email protected]> > <[email protected]>; [email protected] <[email protected]> > <[email protected]> > *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC9470 (7951) > > The following errata report has been submitted for RFC9470, > "OAuth 2.0 Step Up Authentication Challenge Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7951 > > -------------------------------------- > Type: Technical > Reported by: Tomasz Kuczyński <[email protected]> > <[email protected]> > > Section: 6.2 > > Original Text > ------------- > "exp": 1639528912, > "iat": 1618354090, > "auth_time": 1646340198, > > Corrected Text > -------------- > "exp": 1639528912, > "iat": 1618354090, > "auth_time": 1618354090, > > Notes > ----- > I noticed a small inconsistency in the example "Figure 7: Introspection > Response". It seems that the time for the user-authentication event should > be less than or equal to the time of token issuance to ensure logical > coherence. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9470 (draft-ietf-oauth-step-up-authn-challenge-17) > -------------------------------------- > Title : OAuth 2.0 Step Up Authentication Challenge Protocol > Publication Date : September 2023 > Author(s) : V. Bertocci, B. Campbell > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > -- > Tomasz Kuczynski > > Applications Division > Large Scale Applications and Services Department Manager > Poznan Supercomputing and Networking Center > Polish Academy of Sciences > Jana Pawla II 10, Room 1.28 > 61-139 Poznan, Poland > Tel.: +48 693 918 148 > > -- _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 -- [email protected] To unsubscribe send an email to [email protected]
