Hi Joe,
Thanks so much for these comments and I apologize for the delay in addressing
them.
Comments inline below
George Fletcher
Identity Standards Architect
Practical Identity LLC
> On Jun 19, 2025, at 6:44 PM, Joe DeCock
> <joe=40duendesoftware....@dmarc.ietf.org> wrote:
>
> Hello OAuth working group,
>
> I've been reading the transaction tokens draft with great interest. I think
> it's solving an important problem and largely I like what I'm seeing in the
> draft. However, I think that the way that scope and purpose are
> differentiated can be improved to make the specification easier to
> understand, easier to implement, and improve interoperability.
>
> The way that the purpose is described and contrasted with OAuth scopes in
> section 5.2.1 makes good sense to me.
>
>> The purp claim captures the exact purpose of this particular transaction.
>> This is often much narrower than a scope value issued to an external client.
>> This is due to the fact that in most cases, the authorization model within
>> the Trust Domain is quite different than the authorization model used with
>> clients external to the Trust Domain. To that end, it is intentional to
>> separate the concept of scope (often fairly coarse-grained) used with
>> external clients from the purpose of the transaction used within the Trust
>> Domain. How a given deployment represents the authorization model within the
>> Trust Domain is out of scope for this specification.
>
> But in the txn-token request (Section 7.1), the purpose of the transaction
> token is sent as the scope parameter. I think that has the potential to be
> confusing, because the two concepts are meant to be distinct. In my
> experience, non-identity experts often struggle with the existing concepts of
> scopes, claims, and roles. Reusing the scope parameter with purpose semantics
> is likely going to be a cause for confusion.
The `scope` parameter is used in the request because the spec is profiling RFC
8693 (Token Exchange) which defines the parameter. To use a different parameter
would require the profile to explicitly prohibit the use of the `scope`
parameter in favor of a new parameter. I understand how this can be confusing.
Unfortunately, the other side is that if we keep adding new parameters and
prohibit existing ones, it begs the question of whether we should be profiling
RFC 8693 at all and rather defining yet another endpoint.
>
> Section 9.6 muddies the distinction between scope and purpose further:
>
>> The TTS MUST ensure that the requested purpose (scope) of the Txn-Token is
>> equal or less than the scope(s) identified in the subject_token. This is
>> also true of requesting a replacement Txn-Token. The TTS MUST ensure there
>> is no unintentional increase in authorization scope.
>
>
> It's not clear to me what the equal to or less than language exactly means,
> but it's certainly very suggestive, perhaps in a way that isn't good. To me,
> it makes it sound like a purpose is a part of a scope, or that there's a
> relationship where certain scopes authorize certain purposes. It seems to me
> that while the decision to issue a transaction token should take the scope of
> the subject token into account, it potentially would also care about other
> claims of the subject token, the calling client, the request context, the
> request details, or the txn token service's policy.
The “equal or less than” is an attempt to say that the purpose (specified via
the `scope` parameter) must NOT enable more privilege than was is defined by
the `subject_token`. The key point here is that the TTS MUST prevent any form
of privileged escalation attack.
>
> My suggestions are to
> 1. Invent a new "purpose" parameter used to request transaction tokens so
> that tx-token requests do not re-use scope or set it all,
> 2. Clarify the intentions of the "equal or less than" language in section
> 9.6, and
> 3. Consider language explicitly stating that transaction tokens MUST NOT
> contain a scope claim.
The text for the value of the profiled `scope` parameter explicitly states:
A space-delimited list of case-sensitive strings
where the value(s) MUST represent the specific purpose or intent
of the transaction.
I think that is pretty clear in regards to what the value of the parameter
should represent.
We can look to clarify the language around “equal or less than” if you have any
suggestions that would be greatly appreciated!
>
> The token exchange spec says that scope is optional, so I would simply
> mandate that in a transaction token exchange, scope is not used.
>
> Thinking about how I or others would likely implement this, it seems likely
> that validating the purpose parameter as well as the configuration and policy
> related to it would be a separate system from scope processing in the AS. So,
> from an implementation point of view, adding the new parameter would probably
> simplify the implementation at the AS. The new semantics and parameters that
> are associated with the transaction token call would mean that the
> client/initiating workload would already have to write some new code. While
> existing libraries exist that know how to do token exchange in general, the
> specifics of transaction tokens are still going to require some
> implementation work. A new purpose parameter wouldn't add significantly to
> that.
I’m not sure the parameter name prohibits this separation of logic in the TTS.
The TTS code processing the request can look at the `requested_token_type` and
if that matches `urn:ietf:params:oauth:token-type:txn_token` then send the
request to the code that processes transaction token requests which can then
treat the `scope` parameter differently.
>
> Language to ban scopes from transaction tokens would simply be there to
> re-inforce what the specification is already (not) doing. It helps with
> interoperability to make sure that the TTS never does include a scope, in
> case a tx-token was ever misused. Of course we have the typ header to
> differentiate the tokens, but leaving the scope out helps prevent their
> misuse by older JWT libraries that don't know to validate the typ. And in any
> case, it seems that not including the scope is the intention in this draft.
One of the tricky things with the OAuth concept of ’scope’ is that it was never
semantically defined in the original RFCs (6749,6750). That means that there
are many, many different implementations on how scope is used. Some more
fine-grained than others. It’s possible for a deployment which only has
“internal” use cases (no external clients) to have a fairly complicated scope
definition mechanism which would allow for scope values to actually be used
with transaction tokens. Because of this wide variety of implementations, we
didn’t want to make any assumptions and felt using the existing parameter made
more sense.
>
>
> Cheers,
> Joe DeCock
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
