Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[Kai Lehmann]

Hi George,

That’s indeed an interesting aspect whether to allow the workload to present a 
subject_token which it did not sign itself. This makes it even more challenging 
for the TTS to obtain the public key of the signing party in order to validate 
the signature if the presented subject_token. My suggestion to make signing of 
the subject_token optional still stands :-)

Kai

From: George Fletcher 
Date: Friday, 3. May 2024 at 18:15
To: Kai Lehmann 
Cc: Kai Lehmann , oauth 
Subject: Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in 
the absence of incoming token

Hi Kai,

I see your point. I agree that the subject_token may not need to be signed 
depending on the deployment. This was true when we made the proposal that the 
subject_token could be a simple string (e.g. email address). If the 
subject_token is signed, the TTS could verify that the subject_token was issued 
by the same client making the request. However, that might not always be valid 
either:)

Thanks,
George

On Tue, Apr 23, 2024 at 11:25 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:
Hi George,

The Token Exchange request ist requiring client authentication. A TTS needs to 
trust this authenticated client to provide a correct subject to some extend. 
This is also the case if the client would provide a self-signed JWT containing 
the subject instead. Using a JWT as a subject token has definitely some 
benefits as the format/content can be specified, but I don’t see how signing 
the JWT would make the trust by the TTS towards the client unnecessary.

Best regards,
Kai

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of George Fletcher 
mailto:40capitalone@dmarc.ietf.org>>
Date: Monday, 22. April 2024 at 17:50
To: Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in 
the absence of incoming token

Kai,

How would the TTS trust the incoming "subject" value if not signed? Do you have 
something in mind?

Thanks,
George

On Tue, Apr 16, 2024 at 3:46 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:
Hi,

Sorry for replying to this so late to this thread. Although self-signed JWTs 
may help to fill the subject_token for Token Exchange, I think it can be a 
burden for the Workload presenting the Self signed JWT as well as for the Txn 
Token Service to validate that token. It would require the Workload to do 
generate and maintain proper signing key material – including rotating those 
keys on a regular basis as well as making them available to the Txn Token 
Service. Workloads may not have the capability to serve a JKWS file as they are 
purely operating in a backend environment (batch processes).

As this discussion is more or less already concluded, I hope that the spec can 
at least allow alternatives.

BR,
Kai


From: George Fletcher 
mailto:40capitalone@dmarc.ietf.org>>
Date: Friday, 12. April 2024 at 19:53
To: Atul Tulshibagwale mailto:a...@sgnl.ai>>
Cc: Brian Campbell 
mailto:bcampb...@pingidentity.com>>, Kai Lehmann 
mailto:kai.lehm...@1und1.de>>, Dmitry Telegin 
mailto:dmit...@backbase.com>>, oauth 
mailto:oauth@ietf.org>>
Subject: Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens issuance in 
the absence of incoming token

Atul has submitted this PR to address this issue.
https://github.com/oauth-wg/oauth-transaction-tokens/pull/90<https://urldefense.com/v3/__https:/github.com/oauth-wg/oauth-transaction-tokens/pull/90__;!!FrPt2g6CO4Wadw!MJMc1NL3i2PsNlotzn7SBEzXnweUxiyc1sBVhxviBFDM_zf5l4muEFfQglVXdrP1XyOx-6BD_ilSfJBKaSgbcUATv14buN0ZfpAxA9o$>

On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:
Thanks all, for your input. We discussed alternatives on a call last 
week<https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
 and arrived at using self-signed tokens with token exchange as a way forward.

On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
One potential benefit of keeping the use of Token Exchange is that some AS 
products/implementations have built a fair amount of configurability and 
extensibility into their Token Exchange support, which might allow for existing 
systems to be set up to do Transaction Tokens. Whereas a new endpoint or new 
grant type are more likely to require code changes to the core AS. Obviously 
this isn't universally true but something to consider nonetheless.

On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:
Hi,

that is my thought as well. It does not necessarily be a Token Exchange 
profile, but the Token endpoint makes sense as Tokens are issued. Defining a 
specific Token grant with the necess

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[George Fletcher]

Hi Kai,

I see your point. I agree that the subject_token may not need to be signed
depending on the deployment. This was true when we made the proposal that
the subject_token could be a simple string (e.g. email address). If the
subject_token is signed, the TTS could verify that the subject_token was
issued by the same client making the request. However, that might not
always be valid either:)

Thanks,
George

On Tue, Apr 23, 2024 at 11:25 AM Kai Lehmann  wrote:

> Hi George,
>
>
>
> The Token Exchange request ist requiring client authentication. A TTS
> needs to trust this authenticated client to provide a correct subject to
> some extend. This is also the case if the client would provide a
> self-signed JWT containing the subject instead. Using a JWT as a subject
> token has definitely some benefits as the format/content can be specified,
> but I don’t see how signing the JWT would make the trust by the TTS towards
> the client unnecessary.
>
>
>
> Best regards,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of George Fletcher
> 
> *Date: *Monday, 22. April 2024 at 17:50
> *To: *Kai Lehmann 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens
> issuance in the absence of incoming token
>
>
>
> Kai,
>
>
>
> How would the TTS trust the incoming "subject" value if not signed? Do you
> have something in mind?
>
>
>
> Thanks,
>
> George
>
>
>
> On Tue, Apr 16, 2024 at 3:46 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> Sorry for replying to this so late to this thread. Although self-signed
> JWTs may help to fill the subject_token for Token Exchange, I think it can
> be a burden for the Workload presenting the Self signed JWT as well as for
> the Txn Token Service to validate that token. It would require the Workload
> to do generate and maintain proper signing key material – including
> rotating those keys on a regular basis as well as making them available to
> the Txn Token Service. Workloads may not have the capability to serve a
> JKWS file as they are purely operating in a backend environment (batch
> processes).
>
>
>
> As this discussion is more or less already concluded, I hope that the spec
> can at least allow alternatives.
>
>
>
> BR,
>
> Kai
>
>
>
>
>
> *From: *George Fletcher 
> *Date: *Friday, 12. April 2024 at 19:53
> *To: *Atul Tulshibagwale 
> *Cc: *Brian Campbell , Kai Lehmann <
> kai.lehm...@1und1.de>, Dmitry Telegin , oauth <
> oauth@ietf.org>
> *Subject: *Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens
> issuance in the absence of incoming token
>
>
>
> Atul has submitted this PR to address this issue.
>
> https://github.com/oauth-wg/oauth-transaction-tokens/pull/90
> <https://urldefense.com/v3/__https:/github.com/oauth-wg/oauth-transaction-tokens/pull/90__;!!FrPt2g6CO4Wadw!MJMc1NL3i2PsNlotzn7SBEzXnweUxiyc1sBVhxviBFDM_zf5l4muEFfQglVXdrP1XyOx-6BD_ilSfJBKaSgbcUATv14buN0ZfpAxA9o$>
>
>
>
> On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale  wrote:
>
> Thanks all, for your input. We discussed alternatives on a call last week
> <https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
> and arrived at using self-signed tokens with token exchange as a way
> forward.
>
>
>
> On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
> wrote:
>
> One potential benefit of keeping the use of Token Exchange is that some AS
> products/implementations have built a fair amount of configurability and
> extensibility into their Token Exchange support, which might allow for
> existing systems to be set up to do Transaction Tokens. Whereas a new
> endpoint or new grant type are more likely to require code changes to the
> core AS. Obviously this isn't universally true but something to consider
> nonetheless.
>
>
>
> On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> that is my thought as well. It does not necessarily be a Token Exchange
> profile, but the Token endpoint makes sense as Tokens are issued. Defining
> a specific Token grant with the necessary input parameters would fit nicely.
>
>
>
> Best regards,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of Dmitry Telegin
> 
> *Date: *Friday, 5. April 2024 at 00:41
> *To: *Atul Tulshibagwale 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Transaction Tokens issuance in the absence of
> incoming token
>
>
>
> Hello Atul,
>
>
>
> As an alternative to Token Exchange and separate (

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[Kai Lehmann]

Hi George,

The Token Exchange request ist requiring client authentication. A TTS needs to 
trust this authenticated client to provide a correct subject to some extend. 
This is also the case if the client would provide a self-signed JWT containing 
the subject instead. Using a JWT as a subject token has definitely some 
benefits as the format/content can be specified, but I don’t see how signing 
the JWT would make the trust by the TTS towards the client unnecessary.

Best regards,
Kai

From: OAuth  on behalf of George Fletcher 

Date: Monday, 22. April 2024 at 17:50
To: Kai Lehmann 
Cc: oauth 
Subject: Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in 
the absence of incoming token

Kai,

How would the TTS trust the incoming "subject" value if not signed? Do you have 
something in mind?

Thanks,
George

On Tue, Apr 16, 2024 at 3:46 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:
Hi,

Sorry for replying to this so late to this thread. Although self-signed JWTs 
may help to fill the subject_token for Token Exchange, I think it can be a 
burden for the Workload presenting the Self signed JWT as well as for the Txn 
Token Service to validate that token. It would require the Workload to do 
generate and maintain proper signing key material – including rotating those 
keys on a regular basis as well as making them available to the Txn Token 
Service. Workloads may not have the capability to serve a JKWS file as they are 
purely operating in a backend environment (batch processes).

As this discussion is more or less already concluded, I hope that the spec can 
at least allow alternatives.

BR,
Kai


From: George Fletcher 
mailto:40capitalone@dmarc.ietf.org>>
Date: Friday, 12. April 2024 at 19:53
To: Atul Tulshibagwale mailto:a...@sgnl.ai>>
Cc: Brian Campbell 
mailto:bcampb...@pingidentity.com>>, Kai Lehmann 
mailto:kai.lehm...@1und1.de>>, Dmitry Telegin 
mailto:dmit...@backbase.com>>, oauth 
mailto:oauth@ietf.org>>
Subject: Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens issuance in 
the absence of incoming token

Atul has submitted this PR to address this issue.
https://github.com/oauth-wg/oauth-transaction-tokens/pull/90<https://urldefense.com/v3/__https:/github.com/oauth-wg/oauth-transaction-tokens/pull/90__;!!FrPt2g6CO4Wadw!MJMc1NL3i2PsNlotzn7SBEzXnweUxiyc1sBVhxviBFDM_zf5l4muEFfQglVXdrP1XyOx-6BD_ilSfJBKaSgbcUATv14buN0ZfpAxA9o$>

On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:
Thanks all, for your input. We discussed alternatives on a call last 
week<https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
 and arrived at using self-signed tokens with token exchange as a way forward.

On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
One potential benefit of keeping the use of Token Exchange is that some AS 
products/implementations have built a fair amount of configurability and 
extensibility into their Token Exchange support, which might allow for existing 
systems to be set up to do Transaction Tokens. Whereas a new endpoint or new 
grant type are more likely to require code changes to the core AS. Obviously 
this isn't universally true but something to consider nonetheless.

On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:
Hi,

that is my thought as well. It does not necessarily be a Token Exchange 
profile, but the Token endpoint makes sense as Tokens are issued. Defining a 
specific Token grant with the necessary input parameters would fit nicely.

Best regards,
Kai

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Dmitry Telegin 
mailto:40backbase@dmarc.ietf.org>>
Date: Friday, 5. April 2024 at 00:41
To: Atul Tulshibagwale mailto:a...@sgnl.ai>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Transaction Tokens issuance in the absence of incoming 
token

Hello Atul,

As an alternative to Token Exchange and separate (new) endpoint, have you ever 
considered OAuth 2.0 Extension 
Grants<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6749*section-4.5__;Iw!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthaF41vnj$>?
 This could give us more flexibility as will let us define our own set of input 
parameters and validation rules (opposite to Token Exchange that restricts us 
to subject_token and friends).

Regards,
Dmitry

On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:
Thanks very much for your feedback, Joe!

On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Hi Atul,

I'm just starting to review the transaction tokens draft and have only a 
minimal understanding of 

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[George Fletcher]

Kai,

How would the TTS trust the incoming "subject" value if not signed? Do you
have something in mind?

Thanks,
George

On Tue, Apr 16, 2024 at 3:46 AM Kai Lehmann  wrote:

> Hi,
>
>
>
> Sorry for replying to this so late to this thread. Although self-signed
> JWTs may help to fill the subject_token for Token Exchange, I think it can
> be a burden for the Workload presenting the Self signed JWT as well as for
> the Txn Token Service to validate that token. It would require the Workload
> to do generate and maintain proper signing key material – including
> rotating those keys on a regular basis as well as making them available to
> the Txn Token Service. Workloads may not have the capability to serve a
> JKWS file as they are purely operating in a backend environment (batch
> processes).
>
>
>
> As this discussion is more or less already concluded, I hope that the spec
> can at least allow alternatives.
>
>
>
> BR,
>
> Kai
>
>
>
>
>
> *From: *George Fletcher 
> *Date: *Friday, 12. April 2024 at 19:53
> *To: *Atul Tulshibagwale 
> *Cc: *Brian Campbell , Kai Lehmann <
> kai.lehm...@1und1.de>, Dmitry Telegin , oauth <
> oauth@ietf.org>
> *Subject: *Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens
> issuance in the absence of incoming token
>
>
>
> Atul has submitted this PR to address this issue.
>
> https://github.com/oauth-wg/oauth-transaction-tokens/pull/90
> <https://urldefense.com/v3/__https://github.com/oauth-wg/oauth-transaction-tokens/pull/90__;!!FrPt2g6CO4Wadw!MJMc1NL3i2PsNlotzn7SBEzXnweUxiyc1sBVhxviBFDM_zf5l4muEFfQglVXdrP1XyOx-6BD_ilSfJBKaSgbcUATv14buN0ZfpAxA9o$>
>
>
>
> On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale  wrote:
>
> Thanks all, for your input. We discussed alternatives on a call last week
> <https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
> and arrived at using self-signed tokens with token exchange as a way
> forward.
>
>
>
> On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
> wrote:
>
> One potential benefit of keeping the use of Token Exchange is that some AS
> products/implementations have built a fair amount of configurability and
> extensibility into their Token Exchange support, which might allow for
> existing systems to be set up to do Transaction Tokens. Whereas a new
> endpoint or new grant type are more likely to require code changes to the
> core AS. Obviously this isn't universally true but something to consider
> nonetheless.
>
>
>
> On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> that is my thought as well. It does not necessarily be a Token Exchange
> profile, but the Token endpoint makes sense as Tokens are issued. Defining
> a specific Token grant with the necessary input parameters would fit nicely.
>
>
>
> Best regards,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of Dmitry Telegin
> 
> *Date: *Friday, 5. April 2024 at 00:41
> *To: *Atul Tulshibagwale 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Transaction Tokens issuance in the absence of
> incoming token
>
>
>
> Hello Atul,
>
>
>
> As an alternative to Token Exchange and separate (new) endpoint, have you
> ever considered OAuth 2.0 Extension Grants
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6749*section-4.5__;Iw!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthaF41vnj$>?
> This could give us more flexibility as will let us define our own set of
> input parameters and validation rules (opposite to Token Exchange that
> restricts us to subject_token and friends).
>
>
>
> Regards,
>
> Dmitry
>
>
>
> On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale  wrote:
>
> Thanks very much for your feedback, Joe!
>
>
>
> On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey  wrote:
>
> Hi Atul,
>
>
>
> I'm just starting to review the transaction tokens draft and have only a
> minimal understanding of the token exchange document at this point so I'm
> lacking a little background, but I have a few comments and questions below.
>
>
>
> On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale  wrote:
>
> Hi all,
>
> We had a meeting today (notes here
> <https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/HJNXYKkk0__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSyWxSbV$>)
> in which we discussed the question of what we should do if there is no
> incoming (external) token in t

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[Kai Lehmann]

Hi,

Sorry for replying to this so late to this thread. Although self-signed JWTs 
may help to fill the subject_token for Token Exchange, I think it can be a 
burden for the Workload presenting the Self signed JWT as well as for the Txn 
Token Service to validate that token. It would require the Workload to do 
generate and maintain proper signing key material – including rotating those 
keys on a regular basis as well as making them available to the Txn Token 
Service. Workloads may not have the capability to serve a JKWS file as they are 
purely operating in a backend environment (batch processes).

As this discussion is more or less already concluded, I hope that the spec can 
at least allow alternatives.

BR,
Kai


From: George Fletcher 
Date: Friday, 12. April 2024 at 19:53
To: Atul Tulshibagwale 
Cc: Brian Campbell , Kai Lehmann 
, Dmitry Telegin , oauth 

Subject: Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens issuance in 
the absence of incoming token

Atul has submitted this PR to address this issue.
https://github.com/oauth-wg/oauth-transaction-tokens/pull/90

On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:
Thanks all, for your input. We discussed alternatives on a call last 
week<https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
 and arrived at using self-signed tokens with token exchange as a way forward.

On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
One potential benefit of keeping the use of Token Exchange is that some AS 
products/implementations have built a fair amount of configurability and 
extensibility into their Token Exchange support, which might allow for existing 
systems to be set up to do Transaction Tokens. Whereas a new endpoint or new 
grant type are more likely to require code changes to the core AS. Obviously 
this isn't universally true but something to consider nonetheless.

On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:
Hi,

that is my thought as well. It does not necessarily be a Token Exchange 
profile, but the Token endpoint makes sense as Tokens are issued. Defining a 
specific Token grant with the necessary input parameters would fit nicely.

Best regards,
Kai

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Dmitry Telegin 
mailto:40backbase@dmarc.ietf.org>>
Date: Friday, 5. April 2024 at 00:41
To: Atul Tulshibagwale mailto:a...@sgnl.ai>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Transaction Tokens issuance in the absence of incoming 
token

Hello Atul,

As an alternative to Token Exchange and separate (new) endpoint, have you ever 
considered OAuth 2.0 Extension 
Grants<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6749*section-4.5__;Iw!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthaF41vnj$>?
 This could give us more flexibility as will let us define our own set of input 
parameters and validation rules (opposite to Token Exchange that restricts us 
to subject_token and friends).

Regards,
Dmitry

On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:
Thanks very much for your feedback, Joe!

On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Hi Atul,

I'm just starting to review the transaction tokens draft and have only a 
minimal understanding of the token exchange document at this point so I'm 
lacking a little background, but I have a few comments and questions below.

On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:
Hi all,
We had a meeting today (notes 
here<https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/HJNXYKkk0__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSyWxSbV$>)
 in which we discussed the question of what we should do if there is no 
incoming (external) token in the request to issue a Transaction 
Token<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthe6t5FmT$>
 (TraT). We identified a few circumstances under which this can happen:

  *   The requesting service is triggered by a non-OAuth based flow such as 
email or an internal trigger
  *   The client of the requesting service uses means other than an access 
token to authorize the call (e.g. MTLS)
[Joe] I think there will be a fair number of systems that support means of 
authorizing non-oauth flows.


We identified a few possibilities listed below. Please note that the 
Transaction Tokens draft assumes that the TraT Service trusts the requesting 
service, so all the possibilities be

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[George Fletcher]

Atul has submitted this PR to address this issue.
https://github.com/oauth-wg/oauth-transaction-tokens/pull/90

On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale  wrote:

> Thanks all, for your input. We discussed alternatives on a call last week
> ,
> and arrived at using self-signed tokens with token exchange as a way
> forward.
>
> On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
> wrote:
>
>> One potential benefit of keeping the use of Token Exchange is that some
>> AS products/implementations have built a fair amount of configurability and
>> extensibility into their Token Exchange support, which might allow for
>> existing systems to be set up to do Transaction Tokens. Whereas a new
>> endpoint or new grant type are more likely to require code changes to the
>> core AS. Obviously this isn't universally true but something to consider
>> nonetheless.
>>
>> On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann > 401und1...@dmarc.ietf.org> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> that is my thought as well. It does not necessarily be a Token Exchange
>>> profile, but the Token endpoint makes sense as Tokens are issued. Defining
>>> a specific Token grant with the necessary input parameters would fit nicely.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Kai
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of Dmitry Telegin
>>> 
>>> *Date: *Friday, 5. April 2024 at 00:41
>>> *To: *Atul Tulshibagwale 
>>> *Cc: *oauth 
>>> *Subject: *Re: [OAUTH-WG] Transaction Tokens issuance in the absence of
>>> incoming token
>>>
>>>
>>>
>>> Hello Atul,
>>>
>>>
>>>
>>> As an alternative to Token Exchange and separate (new) endpoint, have
>>> you ever considered OAuth 2.0 Extension Grants
>>> ?
>>> This could give us more flexibility as will let us define our own set of
>>> input parameters and validation rules (opposite to Token Exchange that
>>> restricts us to subject_token and friends).
>>>
>>>
>>>
>>> Regards,
>>>
>>> Dmitry
>>>
>>>
>>>
>>> On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale  wrote:
>>>
>>> Thanks very much for your feedback, Joe!
>>>
>>>
>>>
>>> On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey  wrote:
>>>
>>> Hi Atul,
>>>
>>>
>>>
>>> I'm just starting to review the transaction tokens draft and have only a
>>> minimal understanding of the token exchange document at this point so I'm
>>> lacking a little background, but I have a few comments and questions below.
>>>
>>>
>>>
>>> On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> We had a meeting today (notes here
>>> )
>>> in which we discussed the question of what we should do if there is no
>>> incoming (external) token in the request to issue a Transaction Token
>>> 
>>> (TraT). We identified a few circumstances under which this can happen:
>>>
>>>- The requesting service is triggered by a non-OAuth based flow such
>>>as email or an internal trigger
>>>- The client of the requesting service uses means other than an
>>>access token to authorize the call (e.g. MTLS)
>>>
>>> [Joe] I think there will be a fair number of systems that support means
>>> of authorizing non-oauth flows.
>>>
>>>
>>>
>>>
>>>
>>> We identified a few possibilities listed below. Please note that the
>>> Transaction Tokens draft assumes that the TraT Service trusts the
>>> requesting service, so all the possibilities below assume this.
>>>
>>>
>>>
>>>
>>>
>>> [Joe] yes, you are trusting another part of the system to perform some
>>> authorization and inform the token service of the result.
>>>
>>>
>>>
>>> Here are some possibilities we discussed:
>>>
>>>1. *Request Details*: Put the subject information in the
>>>request_details parameter of the TraT request, and the subject_token 
>>> value
>>>is set to "N_A"
>>>2. *Self-Signed Token*: The requester generates a self-signed JWT
>>>that has the subject information and puts that in the subject_token value
>>>
>>> [Joe] I like having signed tokens, but if this is really information
>>> just exchanged between two endpoints it may be more work than necessary.
>>>
>>>
>>>1. *Separate Separate Endpoint*: The TraT service exposes a separate
>>>endpoint to issue TraTs when there is no incoming token, and that 
>>> endpoint
>>>can be defined such that the