Dear Blake, Thank you for the prompt feedback. I understand both points, considering how to handle them 😊
A resource server: 1. Knows whether it publishes authority metadata in its PRM or not. 2. Knows when it updates its authority policy. 3. Controls accepted token freshness and max_age. 4. (Currently) Cannot assume publishing of authority metadata ensures the authorization server will retrieve and consider it. Please help me understand, why would a resource server require the indication its PRM authority metadata was used? Regarding freshness only, the RS could when updating PRM authority metadata, reject relevant tokens issued before the update. To consider your requirement, I would propose a metadata binding claim in JWT tokens and token introspection response, along the lines of: "amb": "local" || "s256:<base64url-encoded SHA-256 digest of PRM authority>" "amb" stands for authority metadata binding. > When absent, no authority-metadata processing assertion is made. > When "local" means The AS used its own local authority definitions. > When digest it provides indication of specific PRM used Yaron Classification: GENERAL -----Original Message----- From: Blake Morrison <[email protected]> Sent: Monday, October 12, 2026 5:21 AM To: Yaron ZEHAVI <[email protected]>; [email protected] Cc: Omri Gazitt <[email protected]> Subject: [OAUTH-WG] Re: 回复：Re: Call for interest: fine-grained authorization in OAuth (IETF 126 follow-up) [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This message is from an external sender - be cautious, particularly with links and attachments. Hi Yaron, Thanks. 8.2 lets the AS fall back to local policy when the resource's metadata isn't available. 9.3 doesn't tie a token to a metadata version either. Once a token's issued there's no way to tell which description it was checked against, or whether it was checked against one at all. If a resource tightens payments.manage later it can't tell its old tokens from its new ones. Could the issuance record carry a digest of the description the AS used and when it was fetched, or a flag when it fell back to local policy? Blake This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien). _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
