@rifaat - SPIFFE isn\u2019t on the agenda listed here: https://datatracker.ietf.org/meeting/123/materials/agenda-123-oauth-02. Is anything else missing?
", "time": "2025-07-25T12:33:46Z"}, {"author": "Nick Doty", "text": "I did promise a review of status list (based on our W3C experience of similar documents) and admit that I haven't gotten to it yet
", "time": "2025-07-25T12:36:24Z"}, {"author": "Nick Doty", "text": "would a privacy review of the status list draft still be welcome?
", "time": "2025-07-25T12:41:17Z"}, {"author": "Jeff Lombardo", "text": "@heather the spiffe related topic were yesterday
", "time": "2025-07-25T12:41:30Z"}, {"author": "Jeff Lombardo", "text": "Pieter presented SPIFFE client registration on first use and SPIFFE client authentication
", "time": "2025-07-25T12:41:57Z"}, {"author": "Christian Bormann", "text": "@Nick sure! We added a significant amount of privacy considerations - would be especially interesting/helpful to get your opinion on those
", "time": "2025-07-25T12:44:09Z"}, {"author": "Pieter Kasselman", "text": "Arndt will present the SPIFE authentication spc today (seperate from registration, which is its own problem).
", "time": "2025-07-25T12:47:42Z"}, {"author": "Jeff Lombardo", "text": "you are on mute aaron
", "time": "2025-07-25T12:55:50Z"}, {"author": "Nick Doty", "text": "room echo
", "time": "2025-07-25T12:56:53Z"}, {"author": "Brian Campbell", "text": "aaron's audio is not great ...
", "time": "2025-07-25T12:56:54Z"}, {"author": "Tim Cappalli", "text": "I plan to provide a review
", "time": "2025-07-25T12:58:49Z"}, {"author": "Aaron Parecki", "text": "is it just echoey room? I confirmed it's using my headset mic now. I hear a ton of echo from the room mics tho.
", "time": "2025-07-25T13:00:16Z"}, {"author": "Justin Richer", "text": "sounded fine on remote
", "time": "2025-07-25T13:00:41Z"}, {"author": "Lorenzo Miniero", "text": "Mics are more sensitive in this room: we'll try to adapt the gain when there's remote speakers
", "time": "2025-07-25T13:00:46Z"}, {"author": "Justin Richer", "text": "there's reverb and echo but it's manageable, in my opinion
", "time": "2025-07-25T13:01:11Z"}, {"author": "Brian Campbell", "text": "i also did not follow
", "time": "2025-07-25T13:08:22Z"}, {"author": "Jeff Lombardo", "text": "the question is how much Txn Tokens is SPIFFE specific or not cause SPIFFE is mentionned at multiple places in the DRaft
", "time": "2025-07-25T13:09:02Z"}, {"author": "Pieter Kasselman", "text": "SPIFFE is mentioned as an example of how workloads might be provisioned and then use SPIFFE creds for authentication. It is non-normative
", "time": "2025-07-25T13:12:34Z"}, {"author": "Andrew McCormick", "text": "I have similar questions and concerns around iss, but I'm definitely interested in this and will review it.
", "time": "2025-07-25T13:21:26Z"}, {"author": "Andrew McCormick", "text": "(this being SPIFFE client authentication)
", "time": "2025-07-25T13:22:19Z"}, {"author": "Dima Postnikov", "text": "We can use \u2018grant\u2019 instead of \u2018consent\u2019 Brian :grinning:
", "time": "2025-07-25T13:28:32Z"}, {"author": "Aaron Parecki", "text": "there is no mention of \"consent\" in RFC6749, but it refers to \"authorization\" and \"approval\" and \"grant\"
", "time": "2025-07-25T13:28:54Z"}, {"author": "Nick Doty", "text": "grants of consent should often be time-limited, but servers also shouldn't rely on consent being persisted. users can withdraw consent at any time.
", "time": "2025-07-25T13:29:23Z"}, {"author": "Aaron Parecki", "text": "i think you mean clients shouldn't rely, but yes of course
", "time": "2025-07-25T13:30:02Z"}, {"author": "Maxwell Gerber", "text": "\n\nusers can withdraw consent at any time
\n
Token revocation can also interact with the access token expires_in param similarly today
", "time": "2025-07-25T13:30:19Z"}, {"author": "Nick Doty", "text": "yes, sorry, I think of these as servers, and clients as user-controlled devices ;)
", "time": "2025-07-25T13:30:26Z"}, {"author": "Leif Johansson", "text": "its really the user interaction that is the intent here right?
", "time": "2025-07-25T13:31:04Z"}, {"author": "Brian Campbell", "text": "by my count, the word \"consent\" appears exactly once in 6749
", "time": "2025-07-25T13:32:43Z"}, {"author": "Justin Richer", "text": "+1 to fraught
", "time": "2025-07-25T13:33:13Z"}, {"author": "Brian Campbell", "text": "\"The authorization server MUST implement CSRF protection for its
\n authorization endpoint and ensure that a malicious client cannot
\n obtain authorization without the awareness and explicit consent of
\n the resource owner\"
fraught is right
", "time": "2025-07-25T13:33:38Z"}, {"author": "Aaron Parecki", "text": "i disagree with david, this gives the client exactly enough information to do something different
", "time": "2025-07-25T13:34:37Z"}, {"author": "Brian Campbell", "text": "i think aaron is generally correct in his disagreement with david
", "time": "2025-07-25T13:35:55Z"}, {"author": "David Waite", "text": "I'll compromise and say it gives the client enough to try. I think assumptions could lead to a worse user experience
", "time": "2025-07-25T13:36:06Z"}, {"author": "Justin Richer", "text": "I agree with Aaron, but disagree that it's practically useful for clients who need to handle exceptional cases anyway. But maybe I just don't work in spaces that need that kind of preemptive optimization.
", "time": "2025-07-25T13:36:41Z"}, {"author": "Nick Doty", "text": "are many implementations letting the user provide time-limited grants?
", "time": "2025-07-25T13:37:19Z"}, {"author": "David Waite", "text": "thats not to say this couldn't attempt to define either additional parameters, to restrict the model used by ASs, or require the AS to independently document behavior
", "time": "2025-07-25T13:37:39Z"}, {"author": "Maxwell Gerber", "text": "Separate from the consent/grant expiry - many implementations are providing time-limited refresh tokens, and I see a lot of value in communicating the refresh token lifetime in-band even if the grant lifetime is harder to pin down
", "time": "2025-07-25T13:39:26Z"}, {"author": "Justin Richer", "text": "+1 to \"trust you, bruh\" ;)
", "time": "2025-07-25T13:39:37Z"}, {"author": "Jeff Lombardo", "text": "TYB
", "time": "2025-07-25T13:39:54Z"}, {"author": "Aaron Parecki", "text": "@Nick it's about the AS policy that limits the time of grants. Some/many AS's limit the grant time, both consumer and enterprise use cases.
", "time": "2025-07-25T13:39:56Z"}, {"author": "Jeff Lombardo", "text": "new draft
", "time": "2025-07-25T13:39:58Z"}, {"author": "Aaron Parecki", "text": "Slack has UI for this, you'll see a \"you need to reauthenticate in 30 minutes\" prompt because Slack knows when the enterprise policy requires the user to reauthenticate
", "time": "2025-07-25T13:40:47Z"}, {"author": "Jeff Lombardo", "text": "But does the limit is not Something that the AS and RS only should enforce ? Therefore the Consent usage should be a policy at the AS and a claim for the RS.
\nConsent expired? RS will refuse Token even if valid and return client to AS, When Client will try to refresh, AS will refuse and re-trigger a full grant flow
for app2app, how would the user know that they're in the correct app when they log-in and provide authorization?
", "time": "2025-07-25T13:42:01Z"}, {"author": "Justin Richer", "text": "@Aaron but that's not really token lifetime, is it? It's session management.
", "time": "2025-07-25T13:42:26Z"}, {"author": "Aaron Parecki", "text": "@Jeff yes this is about the AS and RS enforcing, not the client. This is about giving the client the opportunity to ahead of time get the user to re-authorize, rather than having it silently expire
", "time": "2025-07-25T13:42:45Z"}, {"author": "Justin Richer", "text": "at least, I'd put those in separate conceptual buckets
", "time": "2025-07-25T13:42:46Z"}, {"author": "Jeff Lombardo", "text": "Sorry, I am in a mental model that the client is dumb and should not overthink it, just follow signals from AS / RS, which bias my comments
", "time": "2025-07-25T13:43:57Z"}, {"author": "Aaron Parecki", "text": "yes exactly
", "time": "2025-07-25T13:44:06Z"}, {"author": "Aaron Parecki", "text": "think of this as an optimization to handle the error case where the refresh token becomes invalid. This gives the client the opportunity to proactively send the user through a reauthorization flow
", "time": "2025-07-25T13:44:27Z"}, {"author": "Jeff Lombardo", "text": "That was one of the point of Nick where it said, that this proactive action can be done when the client sees that the user is present/around
", "time": "2025-07-25T13:45:12Z"}, {"author": "Jeff Lombardo", "text": "and I see the value in that
", "time": "2025-07-25T13:45:20Z"}, {"author": "Aaron Parecki", "text": "that's the entire point of the draft
", "time": "2025-07-25T13:45:25Z"}, {"author": "Jeff Lombardo", "text": ":thumb_up:
", "time": "2025-07-25T13:45:46Z"}, {"author": "Aaron Parecki", "text": "and that's why i said this shouldn't try to go any deeper into this problem, because this is a specific UX improvement
", "time": "2025-07-25T13:46:03Z"}, {"author": "Justin Richer", "text": "Oui!
", "time": "2025-07-25T13:46:41Z"}, {"author": "Christian Bormann", "text": ":D
", "time": "2025-07-25T13:46:46Z"}, {"author": "David Waite", "text": "It could be as simple as saying if you return these values, you MUST have a policy where a new interactive grant will create a refresh token with a maximal lifetime allowed by policy (or something to that effect)
", "time": "2025-07-25T13:47:40Z"}, {"author": "Aaron Parecki", "text": "I don't even think we need to prescribe that kind of behavior for this to be useful
", "time": "2025-07-25T13:47:57Z"}, {"author": "David Waite", "text": "We may be making different assumptions about possible AS policy then. I just don't want users to get in an endless loop of modal prompts that they need to reauthorize the client to preserve offline access.
", "time": "2025-07-25T13:50:03Z"}, {"author": "Aaron Parecki", "text": "that sounds like an implementation detail of an AS. I just don't want to place requirements on the AS that aren't about interoperability
", "time": "2025-07-25T13:50:28Z"}, {"author": "David Waite", "text": "IMHO it is related to interoperability
", "time": "2025-07-25T13:51:02Z"}, {"author": "Leif Johansson", "text": "@justin - you wanna say VoT?
", "time": "2025-07-25T13:51:58Z"}, {"author": "Brian Campbell", "text": "i think i am still agreeing with Aaron but also don't want these new things to signal or require or set expectations to do things that doesn't exist
", "time": "2025-07-25T13:51:58Z"}, {"author": "Justin Richer", "text": "@Leif it would help
", "time": "2025-07-25T13:52:28Z"}, {"author": "Justin Richer", "text": "potentially
", "time": "2025-07-25T13:52:33Z"}, {"author": "Aaron Parecki", "text": "@Brian I agree with that conceptually
", "time": "2025-07-25T13:52:41Z"}, {"author": "Brian Campbell", "text": "i think we are conceptually aligned at a generally high level
", "time": "2025-07-25T13:53:59Z"}, {"author": "Aaron Parecki", "text": ":joy:
", "time": "2025-07-25T13:54:23Z"}, {"author": "David Waite", "text": "I do think the goal has value
", "time": "2025-07-25T13:55:06Z"}, {"author": "Nat Sakimura", "text": "https://datatracker.ietf.org/doc/html/rfc8485
", "time": "2025-07-25T13:55:49Z"}, {"author": "Justin Richer", "text": "it was developed in parallel to 800-63
", "time": "2025-07-25T13:56:08Z"}, {"author": "Justin Richer", "text": "not as part of each other
", "time": "2025-07-25T13:56:16Z"}, {"author": "Leif Johansson", "text": "Exactly
", "time": "2025-07-25T13:56:42Z"}, {"author": "Brian Campbell", "text": "and, to be fair and a little kinder to Nick, I think his work is aligned at the conceptual level
", "time": "2025-07-25T13:59:04Z"}, {"author": "Brian Campbell", "text": "\"this_refresh_token_might_not_work_in\":600
", "time": "2025-07-25T14:04:34Z"}, {"author": "David Waite", "text": "Maybe the easiest way to say what I think is missing is the prompt parameter from OIDC. The client is assuming that if it drives the user back through OAuth, that the AS is going to maximize refresh token/authorization timeouts on the new tokens issued.
yes and I think that is a safe assumption, and not something the client should try to influence
", "time": "2025-07-25T14:07:26Z"}, {"author": "David Waite", "text": "but if the AS minimizes the UX when it can, then the client may get back exactly the same policy constraints that caused it to direct the user to the AS in the first place
", "time": "2025-07-25T14:08:27Z"}, {"author": "Aaron Parecki", "text": "don't do that then :)
", "time": "2025-07-25T14:08:38Z"}, {"author": "David Waite", "text": "...then I think we need to note that choosing to use those parameters dictates certain policy choices on the AS
", "time": "2025-07-25T14:09:15Z"}, {"author": "Aaron Parecki", "text": "sounds like a good call-out in the security considerations section, but not normatively
", "time": "2025-07-25T14:09:38Z"}, {"author": "David Waite", "text": "I'll make a note to bring this up on list
", "time": "2025-07-25T14:10:06Z"}, {"author": "Brian Campbell", "text": "the AS is the one signaling this thing so it's not unreasonable to think that the same AS could make choices about UI
", "time": "2025-07-25T14:10:07Z"}, {"author": "Brian Campbell", "text": "or is that unreasonable?
", "time": "2025-07-25T14:10:16Z"}, {"author": "Aaron Parecki", "text": ":wait_one_second: brian is right
", "time": "2025-07-25T14:10:31Z"}, {"author": "Aaron Parecki", "text": "\"...the static value of dynamic\" :joy:
", "time": "2025-07-25T14:11:45Z"}, {"author": "Brian Campbell", "text": ":joy:
", "time": "2025-07-25T14:12:20Z"}, {"author": "Nat Sakimura", "text": "I agree that this is the subject/topic that we need to deal with
", "time": "2025-07-25T14:17:00Z"}, {"author": "Brian Campbell", "text": "I sat down but was nodding at Justin
", "time": "2025-07-25T14:17:09Z"}, {"author": "Andrew McCormick", "text": "I'm 100% on board with the problem space and this approach seems pretty elegant. Also curious how we rationalize all the different potential solutions. +1 to an interim or deep dive discussion
", "time": "2025-07-25T14:18:40Z"}, {"author": "Bumblefudge", "text": "is \"ban it in 2.2\" an implicit sub-bullet under option 0?
", "time": "2025-07-25T14:30:36Z"}, {"author": "Brian Campbell", "text": "I guess I'm slight pref for 0 but 2+3 together otherwise
", "time": "2025-07-25T14:32:16Z"}, {"author": "Dean Saxe", "text": "time to remove Brian as an author =)
", "time": "2025-07-25T14:32:30Z"}, {"author": "Dean Saxe", "text": "trust me bruh, it's the right choice =)
", "time": "2025-07-25T14:32:39Z"}, {"author": "Dean Saxe", "text": "thanks Justin and chairs
", "time": "2025-07-25T14:32:58Z"}, {"author": "Brian Campbell", "text": "hi Dean!
", "time": "2025-07-25T14:32:58Z"}, {"author": "Pieter Kasselman", "text": "We choose to do things not bcause they are easy, but because they are hard....
", "time": "2025-07-25T14:32:59Z"}, {"author": "Justin Richer", "text": "\"we choose to not do things because they're hard\"
", "time": "2025-07-25T14:33:14Z"}, {"author": "Pieter Kasselman", "text": "LOL
", "time": "2025-07-25T14:33:22Z"}, {"author": "Justin Richer", "text": "hi Nat!
", "time": "2025-07-25T14:33:26Z"}, {"author": "Brian Campbell", "text": "\"we choose to not do things because they're hard\" - it me!
", "time": "2025-07-25T14:33:38Z"}]