Skip to content

Clarify Transaction Token Context #137

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Clarify Transaction Token Context #137

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion draft-ietf-oauth-transaction-tokens.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,7 +156,7 @@ Txn-Tokens are short-lived, signed JWTs {{RFC7519}} that assert the identity of
### Initial Creation
Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token or an OpenID Connect {{OpenIdConnect}} ID token. This workload then performs an OAuth 2.0 Token Exchange {{RFC8693}} to obtain a Txn-Token. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. This context MAY include:

* The external authorization token (e.g., the OAuth access token)
* A reference to the external authorization token (e.g., the OAuth access token). This may inlcude a hash of the authorization token and may including scopes or claims included in the authorization token. To minimise the risk of token theft, It MUST NOT include the unmodified authorization token (see Security Considerations, Section 9.3).
Copy link
Collaborator

@gffletch gffletch Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this context of the spec... what needs to be sent to the Txn-Token Service, I believe we want to send the full access token. If not, we should have a longer discussion about what should be sent. My expectation has been that the TTS would validate the access_token for it's authenticity before evaluating the TTS authorization policy to determine whether a TraT should be issued.

* Parameters that are required to be bound for the duration of this call
* Additional context, such as the incoming IP address, User Agent information, or other context that can help the Txn-Token Service to issue the Txn-Token

Expand Down
Loading