Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

[Saxe, Dean]

Thanks Pieter!
-dhs

--
Dean H. Saxe, CIDPRO (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com | M: 
206-659-7293

From: Pieter Kasselman 
Date: Tuesday, April 23, 2024 at 7:02 AM
To: "Saxe, Dean" , "rifaat.s.ietf" 
, oauth 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


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.


Hi Dean, thanks for taking the time to review and provide feedback Dean, much 
appreciated.

I have opened issues to address each of the items highlighted.


  1.  Add verbiage to diagrams: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/124
  2.  Make examples consistent for Section 3.1.3: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/125
  3.  Clarify origin of QR Code: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/126
  4.  Editorial updates: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/127
  5.  FIDO Reference update: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/128
  6.  Update Guidance on using FIDO: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/129

Cheers

Pieter


From: OAuth  On Behalf Of Saxe, Dean
Sent: Monday, April 22, 2024 6:54 PM
To: rifaat.s.ietf ; oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP


You don't often get email from 
deansaxe=40amazon@dmarc.ietf.org.
 Learn why this is important

Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com | M: 
206-659-7293

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>
Date: Monday, April 22, 2024 at 7:57 AM
To: oauth mailto:oauth@ietf.org>>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


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.


We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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,
 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?
 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 

Re: [OAUTH-WG] Cross-Device Flows: Security Best Current Practice Review

[Roy Williams (E+P)]

Thank you Pieter.

From: Pieter Kasselman 
Sent: Tuesday, April 23, 2024 6:43 AM
To: Roy Williams (E+P) ; oauth@ietf.org
Subject: RE: Cross-Device Flows: Security Best Current Practice Review

Thanks Roy, thanks for the review and feedback, much apprecioated.

I have opened two issues to add clarification and provide additional guidance 
to implementers.


  1.  Highlight edge cases of geolocation based on IP Address * Issue #123 * 
oauth-wg/oauth-cross-device-security 
(github.com)
  2.  Same device flow prevention * Issue #122 * 
oauth-wg/oauth-cross-device-security 
(github.com)

Cheers

Pieter

From: Roy Williams (E+P) 
mailto:royw...@exchange.microsoft.com>>
Sent: Monday, April 22, 2024 5:42 PM
To: oauth@ietf.org
Cc: Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>>
Subject: Cross-Device Flows: Security Best Current Practice Review

I had promised at the 119 meeting that I would review this document and give 
feedback.  I have completed that document and other than two potential 
clarification points, I found it to be helpful.

The following two areas could be slightly improved:


  1.  At the end of section (5) there is a paragraph that talks about limiting 
Cross-device protocols on the same device.  It does not seem to be something 
that a client could\would know about when let's say YouTube TV requests auth 
and it ends up on Authenticator on the same device.  In theory this would then 
be the Authenticator Service's Job to determine this situation and respond with 
a well known pattern to drive the client to engage in a local oath call 
directly to authenticator.
  2.  In the case of 6.1.1 establishing proximity, there is a boundary (pun not 
intended) case where a device will shift between two different cellular 
providers.  The IETF's Drone effort were examining the same problem as the 
drone flies close to an international boundary and flips back and forth to 
roaming and not.  How to deal with this case or whether it is dependable is a 
question.  I know that Pieter is suggesting Fido2, but the way this section is 
written a Consumption device may be on a weak Wifi and the authentication 
device has shifted to Cellular.

Roy.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

[Pieter Kasselman]

Hi Dean, thanks for taking the time to review and provide feedback Dean, much 
appreciated.

I have opened issues to address each of the items highlighted.


  1.  Add verbiage to diagrams: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/124
  2.  Make examples consistent for Section 3.1.3: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/125
  3.  Clarify origin of QR Code: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/126
  4.  Editorial updates: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/127
  5.  FIDO Reference update: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/128
  6.  Update Guidance on using FIDO: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/129

Cheers

Pieter


From: OAuth  On Behalf Of Saxe, Dean
Sent: Monday, April 22, 2024 6:54 PM
To: rifaat.s.ietf ; oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

You don't often get email from 
deansaxe=40amazon@dmarc.ietf.org.
 Learn why this is important
Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com | M: 
206-659-7293

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>
Date: Monday, April 22, 2024 at 7:57 AM
To: oauth mailto:oauth@ietf.org>>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


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.

We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cross-Device Flows: Security Best Current Practice Review

[Pieter Kasselman]

Thanks Roy, thanks for the review and feedback, much apprecioated.

I have opened two issues to add clarification and provide additional guidance 
to implementers.


  1.  Highlight edge cases of geolocation based on IP Address * Issue #123 * 
oauth-wg/oauth-cross-device-security 
(github.com)
  2.  Same device flow prevention * Issue #122 * 
oauth-wg/oauth-cross-device-security 
(github.com)

Cheers

Pieter

From: Roy Williams (E+P) 
Sent: Monday, April 22, 2024 5:42 PM
To: oauth@ietf.org
Cc: Pieter Kasselman 
Subject: Cross-Device Flows: Security Best Current Practice Review

I had promised at the 119 meeting that I would review this document and give 
feedback.  I have completed that document and other than two potential 
clarification points, I found it to be helpful.

The following two areas could be slightly improved:


  1.  At the end of section (5) there is a paragraph that talks about limiting 
Cross-device protocols on the same device.  It does not seem to be something 
that a client could\would know about when let's say YouTube TV requests auth 
and it ends up on Authenticator on the same device.  In theory this would then 
be the Authenticator Service's Job to determine this situation and respond with 
a well known pattern to drive the client to engage in a local oath call 
directly to authenticator.
  2.  In the case of 6.1.1 establishing proximity, there is a boundary (pun not 
intended) case where a device will shift between two different cellular 
providers.  The IETF's Drone effort were examining the same problem as the 
drone flies close to an international boundary and flips back and forth to 
roaming and not.  How to deal with this case or whether it is dependable is a 
question.  I know that Pieter is suggesting Fido2, but the way this section is 
written a Consumption device may be on a weak Wifi and the authentication 
device has shifted to Cellular.

Roy.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth