Greetings!
", "time": "2025-03-21T02:30:30Z"}, {"author": "Pieter Kasselman", "text": "Hi Kathleen!
", "time": "2025-03-21T02:31:20Z"}, {"author": "Justin Richer", "text": "@meetecho the main screen in the oauth room isn't showing the slides/content -- the secondary (side) screen looks like it's working fine
", "time": "2025-03-21T02:31:38Z"}, {"author": "Justin Richer", "text": "main screen is just the desktop background
", "time": "2025-03-21T02:31:49Z"}, {"author": "Lorenzo Miniero", "text": "@Justin Richer looking into it
", "time": "2025-03-21T02:31:57Z"}, {"author": "Justin Richer", "text": "it's up now, thank you!
", "time": "2025-03-21T02:32:43Z"}, {"author": "Lorenzo Miniero", "text": "Thanks for the heads up!
", "time": "2025-03-21T02:32:49Z"}, {"author": "Kathleen Moriarty", "text": "Hello Pieter!
", "time": "2025-03-21T02:34:49Z"}, {"author": "Arndt Schwenkschuster", "text": "Very well-fitting t-shirt Brian!
", "time": "2025-03-21T03:16:46Z"}, {"author": "Dima Postnikov", "text": "\"has to happen on a client side\" applies well to 2 dimensional setups (client <-> AS), not so well to large ecosystems (e g Open Banking). It's easier to say \"client MUST\" but harder to enforce in reality
", "time": "2025-03-21T03:17:46Z"}, {"author": "Andy Barlow", "text": "rfc 7522 <-- is this the spec describing SAML based client auth?
", "time": "2025-03-21T03:19:54Z"}, {"author": "Joseph Heenan", "text": "JAR can be sent in the backchannel too when using PAR, not only in the front channel as I think Brian said. (Don't think that really changes the conclusion though.)
", "time": "2025-03-21T03:22:01Z"}, {"author": "Atul Tulshibagwale", "text": "Is that a Thaifighter? :D
", "time": "2025-03-21T03:22:07Z"}, {"author": "Arndt Schwenkschuster", "text": "+1 to relax. The life times are different by nature.
", "time": "2025-03-21T03:37:09Z"}, {"author": "Brian Campbell", "text": "So much agree with Aaron
", "time": "2025-03-21T03:38:32Z"}, {"author": "Dean Saxe", "text": "also agree with Aaron
", "time": "2025-03-21T03:38:56Z"}, {"author": "Arndt Schwenkschuster", "text": "Isn't the presence of a transaction token proof enough that it was valid at entry?
", "time": "2025-03-21T03:39:09Z"}, {"author": "Arndt Schwenkschuster", "text": "AT was valid at entry*
", "time": "2025-03-21T03:39:22Z"}, {"author": "Atul Tulshibagwale", "text": "The TraT has a 'iat' value, which can be used to determine when the transaction was initiated
", "time": "2025-03-21T03:40:04Z"}, {"author": "Dean Saxe", "text": "what happens when a TraT is issued in response to a TraT?
", "time": "2025-03-21T03:40:23Z"}, {"author": "Dean Saxe", "text": "does the iat claim get updated?
", "time": "2025-03-21T03:40:31Z"}, {"author": "Aaron Parecki", "text": "I would need to confirm in the draft but that was my assumption, that the iat represents the individual TraT, so there would need to be a new claim to preserve the timestamp of the very initial access token call
", "time": "2025-03-21T03:41:15Z"}, {"author": "Dean Saxe", "text": "I think carrying forward the expiration of the AT in the TraTs makes sense, but that also implies that you carry forward the chain of iats too
", "time": "2025-03-21T03:41:18Z"}, {"author": "Dean Saxe", "text": "^^^ what Aaron said
", "time": "2025-03-21T03:41:34Z"}, {"author": "Atul Tulshibagwale", "text": "Good point, Dean. Section 7.5.2 says the replacement token cannot be greater in scope than the original TraT, but we can refine the language to specify that it cannot exceed the lifetime of the original token
", "time": "2025-03-21T03:41:46Z"}, {"author": "Atul Tulshibagwale", "text": "Actually, I take that back. It is covered in 7.5.1
", "time": "2025-03-21T03:42:44Z"}, {"author": "Aaron Parecki", "text": "that sounds like something different Atul
", "time": "2025-03-21T03:44:41Z"}, {"author": "Dean Saxe", "text": "yeah, this is not about scope, this is about timing
", "time": "2025-03-21T03:45:23Z"}, {"author": "Atul Tulshibagwale", "text": "I was wrong about the scope (I was reading the wrong section). Please see section 7.5.1
", "time": "2025-03-21T03:45:46Z"}, {"author": "Dean Saxe", "text": "and if we agree that a TraT can live beyond the expiration of the AT, then a new TraT can be issued post expiration
", "time": "2025-03-21T03:45:51Z"}, {"author": "Atul Tulshibagwale", "text": "That has a line about the timing
", "time": "2025-03-21T03:45:53Z"}, {"author": "Dean Saxe", "text": "ok - I need to re-read the current draft
", "time": "2025-03-21T03:46:10Z"}, {"author": "Atul Tulshibagwale", "text": "https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-05.html
", "time": "2025-03-21T03:46:22Z"}, {"author": "Aaron Parecki", "text": "7.5.1 talks about overall token lifetime. The thing in question is about preserving the timestamp of the first request that was made with the access token that issued the first TraT
", "time": "2025-03-21T03:47:02Z"}, {"author": "Atul Tulshibagwale", "text": "true. I was responding to Dean's question about getting a replacement TraT
", "time": "2025-03-21T03:47:27Z"}, {"author": "Alex Chalmers", "text": "Dean, just to clarify your statement at the mic, are you suggesting that the TraT maintains the following times: originating AT iat, originating AT exp, time of original AT presentation, and any iat from TraTs chained? Just wanting to get my head wrapped around it.
", "time": "2025-03-21T03:48:24Z"}, {"author": "George Fletcher", "text": "In this context I think the bigger question is if the Transaction Token Service authorizes the issuance of a Transaction Token, then is there a need for the downstream system to care about when the Access Token expired or can it trust the TTS .
", "time": "2025-03-21T03:48:37Z"}, {"author": "Aaron Parecki", "text": "I\u2019m not actually convinced the entire chain needs to be preserved, but definitely the timestamp that the first TraT was issued needs to be preserved throughout the chain
", "time": "2025-03-21T03:48:56Z"}, {"author": "Atul Tulshibagwale", "text": "The TraT has the 'iat' claim, so that should work, right?
", "time": "2025-03-21T03:49:18Z"}, {"author": "George Fletcher", "text": "Sure, having an iat in the TraT makes sense.
", "time": "2025-03-21T03:49:20Z"}, {"author": "Aaron Parecki", "text": "no, because the iat gets replaced with every new TraT issued from another TraT
", "time": "2025-03-21T03:49:34Z"}, {"author": "Arndt Schwenkschuster", "text": "TTS validated the signature of AT and the ecosystem trusts that, so I believe trust is already given
", "time": "2025-03-21T03:49:35Z"}, {"author": "Atul Tulshibagwale", "text": "got it, @aaron
", "time": "2025-03-21T03:49:48Z"}, {"author": "George Fletcher", "text": "I agree that if a workload requests a replacement TraT then more restrictions from a timing come into play.
", "time": "2025-03-21T03:50:24Z"}, {"author": "Justin Richer", "text": "\"transaction started at\" claim is what I was meaning to base things on
", "time": "2025-03-21T03:51:29Z"}, {"author": "George Fletcher", "text": "One possibility is to have the TTS ensure that any replacement TraT can not extend beyond the lifetime of the original TraT. I would like to have more input from people who have workflows that leverage replacement TraTs.
", "time": "2025-03-21T03:52:47Z"}, {"author": "Justin Richer", "text": "I still think \"lifetime of the TraT\" should not be the basis for lifetime of the transaction itself
", "time": "2025-03-21T03:53:08Z"}, {"author": "Aaron Parecki", "text": "my comment was that the lifetime is less important than the timestamp that the original transaction started
", "time": "2025-03-21T03:53:21Z"}, {"author": "Justin Richer", "text": "just like the access token is only needing to be valid at the start
", "time": "2025-03-21T03:53:25Z"}, {"author": "Atul Tulshibagwale", "text": "I agree with Justin and Aaron that we need to have a field in the TraT that captures the original issuance time of the TraT regardless of how many times it gets replaced.
", "time": "2025-03-21T03:54:03Z"}, {"author": "George Fletcher", "text": ":+1:
", "time": "2025-03-21T03:54:28Z"}, {"author": "Dean Saxe", "text": "Trust me, bruh, this is confusing.
", "time": "2025-03-21T03:55:11Z"}, {"author": "Atul Tulshibagwale", "text": "Let's talk about it at IIW, Dean
", "time": "2025-03-21T03:55:38Z"}, {"author": "Dean Saxe", "text": "good plan, Atul. I might try to write a PR before then to give us something to chew on
", "time": "2025-03-21T03:56:02Z"}, {"author": "Atul Tulshibagwale", "text": "sg!
", "time": "2025-03-21T03:56:11Z"}, {"author": "Dean Saxe", "text": "we should dogfood the kerberos approach ;-)
", "time": "2025-03-21T03:57:09Z"}, {"author": "Dean Saxe", "text": "</dad_jokes>
", "time": "2025-03-21T03:57:25Z"}, {"author": "Justin Richer", "text": "well it's not a field about the trat but it's a field about the transaction
", "time": "2025-03-21T03:59:11Z"}, {"author": "Justin Richer", "text": "conflating those are the root of the problem
", "time": "2025-03-21T03:59:20Z"}, {"author": "Aaron Parecki", "text": ":wait_one_second:
", "time": "2025-03-21T03:59:42Z"}, {"author": "George Fletcher", "text": "We have the tctx claim where we can put a \"transaction start time\" claim.
", "time": "2025-03-21T04:00:11Z"}, {"author": "Aaron Parecki", "text": "tiat - transaction initiated at?
", "time": "2025-03-21T04:03:32Z"}, {"author": "Orie Steele", "text": "I don't understand how this is related to multiple confirmation methods... how can the guy that says trust me, not end up with a token they can use?
", "time": "2025-03-21T04:07:56Z"}, {"author": "Aaron Parecki", "text": "they\u2019re saying \u201ctrust me, issue a token that this other guy can use\u201d
", "time": "2025-03-21T04:08:23Z"}, {"author": "Orie Steele", "text": "Like one cnf is a ckt and the other is a uri?
", "time": "2025-03-21T04:08:24Z"}, {"author": "Orie Steele", "text": "how you know im not the other guy?
", "time": "2025-03-21T04:08:43Z"}, {"author": "Aaron Parecki", "text": "the client requesting doesn\u2019t have the ability to sign a proof using the key that it\u2019s being requested to be bound to
", "time": "2025-03-21T04:09:13Z"}, {"author": "Felix Linker", "text": "Orie Steele said:
\n\n\nhow you know im not the other guy?
\n
That's implicit. At the very least you can't prove that you're the other guy because you don't control the respective private key.
", "time": "2025-03-21T04:09:23Z"}, {"author": "George Fletcher", "text": "Makes me think back to the azp claim of the id_token :)
Felix Linker said:
\n\n\nThat's implicit. At the very least you can't prove that you're the other guy because you don't control the respective private key.
\n
*...you can't prove you're the other guy...
", "time": "2025-03-21T04:10:08Z"}, {"author": "Jonathan Hoyland", "text": "This gives me strong bigraph vibes
", "time": "2025-03-21T04:10:08Z"}, {"author": "Jonathan Hoyland", "text": "It might be worth trying to describe a mathematical object that formalises the possible shapes we might want
", "time": "2025-03-21T04:10:56Z"}, {"author": "Kathleen Moriarty", "text": "I think a survey across the WGs is a first step and I'm willing to help
", "time": "2025-03-21T04:11:50Z"}, {"author": "Pieter Kasselman", "text": "This is a common pattern in practical deployment
", "time": "2025-03-21T04:12:08Z"}, {"author": "Pieter Kasselman", "text": "Or problem at least
", "time": "2025-03-21T04:12:17Z"}, {"author": "David Waite", "text": "what would having a signature using the key that is being vouched for if that entity doesn't have a verifiable identity?
", "time": "2025-03-21T04:12:47Z"}, {"author": "David Waite", "text": "I consider a lot of this to be introductory
", "time": "2025-03-21T04:13:06Z"}, {"author": "David Waite", "text": "as in \"here's something you won't recognize but I vouch for them and delegate certain authorizations to them\"
", "time": "2025-03-21T04:13:39Z"}, {"author": "Jonathan Hoyland", "text": "Does the set of identities x authorisations in a trust zone form a tree?
", "time": "2025-03-21T04:13:40Z"}, {"author": "Dean Saxe", "text": "Doesn't RFC 9470 already handle this issue of \"please reauth now?\"
", "time": "2025-03-21T04:16:46Z"}, {"author": "Joseph Heenan", "text": "I had the same thought but I think RFC9470 only handles resource endpoints, not the token endpoint refresh token grant?
", "time": "2025-03-21T04:17:26Z"}, {"author": "Aaron Parecki", "text": "it only defines resource server errors, not for refresh token requests
", "time": "2025-03-21T04:17:35Z"}, {"author": "George Fletcher", "text": "+1 to security issues with following URIs
", "time": "2025-03-21T04:18:38Z"}, {"author": "Dean Saxe", "text": "Is this a potential extension to 9470 to include RT requests? Can we effectively expand the scope of 9470?
", "time": "2025-03-21T04:19:27Z"}, {"author": "Ben Bucksch", "text": "@NickWatson: Yay for better error handling in cases of user blocked, etc.. As a mail client, I have the same problem. The type of error determines how I recover form the error. As client, I will do other things based ont he error type.
\nI suggested: 1) to add additional, more specific error code
\n2) a long, translated, user-readable error string.
IIRC there's not an oath way to carry over a reauthentication into a chain of refresh/access tokens - it is generally a new request, which means it may require client consent depending on the security model.
", "time": "2025-03-21T04:20:14Z"}, {"author": "Ben Bucksch", "text": "I'd be happy to work with Nick on this.
\n(I am on device without mic. if anybody wants to voice that on behalf me, I'd be grateful)
Solution 2 sounds like a CSRF / SSRF nightmare
", "time": "2025-03-21T04:21:56Z"}, {"author": "George Fletcher", "text": ":middle_finger:
", "time": "2025-03-21T04:22:20Z"}, {"author": "David Waite", "text": "I think solution 2 would need to be state against a fixed error endpoint
", "time": "2025-03-21T04:22:35Z"}, {"author": "Aaron Parecki", "text": "did george just give CSRF the middle finger
", "time": "2025-03-21T04:22:40Z"}, {"author": "Orie Steele", "text": "rofl
", "time": "2025-03-21T04:22:48Z"}, {"author": "George Fletcher", "text": "That was supposed to be the finger point up... but it is after midnight :)
", "time": "2025-03-21T04:23:06Z"}, {"author": "Andy Barlow", "text": "hahah
", "time": "2025-03-21T04:23:14Z"}, {"author": "Dean Saxe", "text": "rotfl. You're forgiven, George
", "time": "2025-03-21T04:23:28Z"}, {"author": "Ben Bucksch", "text": "lol#
", "time": "2025-03-21T04:23:35Z"}, {"author": "David Waite", "text": "I 90% believe you George
", "time": "2025-03-21T04:23:43Z"}, {"author": "George Fletcher", "text": ":joy:
", "time": "2025-03-21T04:23:58Z"}, {"author": "George Fletcher", "text": "Just to be clear... I agree with Jonathan that Solution 2 \"sounds like a CSRF / SSRF nightmare\" :)
", "time": "2025-03-21T04:25:02Z"}, {"author": "Ben Bucksch", "text": "@NickWatson I don't have your email address. Can you reach out to me? ben.bucksch@beonex.com . I'd be happy to work with you on that.
", "time": "2025-03-21T04:25:08Z"}, {"author": "Brian Campbell", "text": "Agree with Aaron (again)
", "time": "2025-03-21T04:29:48Z"}, {"author": "Aaron Parecki", "text": "thanks brian <3
", "time": "2025-03-21T04:29:57Z"}]