Thanks Atul, I am relaying here the feedback we exchanged on IDPro Slack /
Authorization channel for the benefit of the public list:
I am little confused on the advantages and purposes here vs all the other
options we have or currently develop.
* What is more "authorization friendly" in this format?
* From a first read, this forces new grants, new token endpoint
parameters, new logic...
* Why a new token and not a Transaction Profile for RAR?
* How would Txn-Token request context parameters: OPTIONAL. Clients MAY
include the request context and request details parameters defined in
[TXN-TOKENS]. These are inputs to policy only. The AS MUST NOT copy them into
tctx or rctx without evaluation would differ from authorizatio_details ? why
supporting both?
* by the way the parameter need to refer to tctx here
* RAR can express whatever we want through it openess and most of the
example have to tie scopes and permissions to transactions.
* Also [w]hat are the advantages of this over allowing txn to JWT Assertion
Grant support as an Identity chaining capability?
* Is that cause the TTS and the AS are two separate things?
* As Transaction Tokens Draft is not finalized, is there really no way to
support the pointed problems/use cases through it instead of having another
Draft?
* The The token exchange grant is used when the client holds a source
token, for example a token representing the user as the subject and the client
(such as an AI agent) as the actor. In this case the request resembles a
Txn-Token request as defined in [TXN-TOKENS] highlight the strong similarities
in between this proposal and the txn one
I acknowledge you provided the following details:
It's a new token format that any AS can choose to support. No new endpoints,
but the AS may take additional parameters to get the request context.
* In RAR, the AS simply copies the az_details into the token. The tctx is
determined by the AS based on the input parameters.
* An AS may support RAR, and the spec needed to have information on how to
handle RARs when issuing Txn-ATs.
* This can be used with Sean, Pieter and George's Txn-Tokens for ID-JAG
spec (and vice versa).
* In this spec, the TTS is the AS.
* Txn-Tokens serve a different purpose (propagating context in a trust
domain). This enables ASes to convey context to the Resource Server (which may
have its own trust domain, with multiple microservices, where Txn-tokens can be
used). A resource server may exchange a Txn-AT for a Txn-token to propagate the
context internally.
GitHub is here: https://github.com/tulshi/txn-at
To which I answered that there might be a misconception on how RAR requires to
behave IMO. RAR is explicit about:
7. <https://www.rfc-editor.org/rfc/rfc9396.html#section-7> Token
Response<https://www.rfc-editor.org/rfc/rfc9396.html#name-token-response>
In addition to the token response parameters as defined in
[RFC6749<https://www.rfc-editor.org/rfc/rfc9396.html#RFC6749>], the AS MUST
also return the authorization_details as granted by the resource owner and
assigned to the respective access token.
The authorization details assigned to the access token issued in a token
response are determined by the authorization_details parameter of the
corresponding token request. If the client does not specify the
authorization_details token request parameters, the AS determines the resulting
authorization_details at its discretion.
The AS MAY omit values in the authorization_details to the client.
7.1. <https://datatracker.ietf.org/doc/html/rfc9396#section-7.1> Enriched
Authorization Details in Token
Response<https://datatracker.ietf.org/doc/html/rfc9396#name-enriched-authorization-deta>
The authorization details attached to the access token MAY differ from what the
client requests. In addition to the user authorizing less than what the client
requested, there are some use cases where the AS enriches the data in an
authorization details object. Whether enrichment is allowed and specifics of
how it works are necessarily part of the definition of the respective
authorization details type.
in a nutshell, my reading is that if JAG allows txn to JAG transformation at
domain A [Sean, Pieter and George Draft] which will allow JAG to Access Token
at Domain B [Identity chaining draft] and RAR authorization_details can be
support as a way to express transactional information, we might already have a
txn-at without needed a new token format, grant, and endpoint parameters.
Jeff
Jean-François “Jeff” Lombardo | Amazon Web Services
Principal Standards Specialist, Identity Services
Montréal, Canada
From: Atul Tulshibagwale <[email protected]>
Sent: September 29, 2026 8:31 PM
To: oauth <[email protected]>
Cc: Pieter Kasselman <[email protected]>
Subject: [EXT] [OAUTH-WG] Transactional Access Tokens
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
contenu ne présente aucun risque.
Hi all,
We need to define a short-lived access token format that is similar to
Txn-Tokens. I've drafted a proposal that incorporates elements of Txn-Tokens
into JWT-formatted OAuth Access Tokens.
Please take a look at this individual draft:
https://datatracker.ietf.org/doc/draft-tulshi-oauth-transactional-access-tokens/
Thanks,
Atul
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
