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

[Saxe, Dean]

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  on behalf of Rifaat Shekh-Yusef 

Date: Monday, April 22, 2024 at 7:57 AM
To: 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.


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

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

[Roy Williams (E+P)]

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] [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
> 
>
>
>
> 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 

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

[Rifaat Shekh-Yusef]

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 
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] WGLC for OAuth 2.0 Protected Resource Metadata

[Rifaat Shekh-Yusef]

All,

Hannes and I discussed the status of this document.

We believe that this document received significant feedback and a new
updated document is needed.
Because of that, after a new version is issued, we will start a *second
WGCL* on this document.

Regards,
 Rifaat



On Fri, Apr 5, 2024 at 7:50 AM Pieter Kasselman <
pieter.kassel...@microsoft.com> wrote:

> I volunteered to review the OAuth 2.0 Protected Resource Metadata (
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html)
> at the IETF 119 meeting.
>
>
>
> First, I would like to thank the authors, Mike, Phil and Aaron, for
> creating this draft. It solves an important problem and I believe this will
> find wide adoption. We are already referencing it in the OAuth Identity and
> Authorization Chaining Across Domains (
> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/01/)
> draft for example.
>
>
>
> Below are my comments, feedback, questions and the occasional suggestion.
> I tried to scrub items that were already brought up elsewhere in this
> thread, but may have missed one or two. Once again thanks for doing this
> important work.
>
>
>
> Section 2
>
>1. jwks_uri - The text only requires the "public key use" parameter if
>both signing and encryption keys are included. It was not clear to me what
>the assumed usage is if only a single key type is present (are they assumed
>to all be signing keys or all encryption keys). To avoid any possible
>confusion, why not make the "public key use" parameter mandatory even when
>only encryption or signature keys are included.
>2. bearer_methods_supported - Reading the parameter name created a
>different expectation and only after reading the text was it clear that
>this was about the way in which the bearer token is presented, rather than
>different types or formats of tokens. Consider renaming this parameter to
>be a bit more descriptive. For example bearer_presentation_methods.
>3. resource_signing_alg_values_supported - I was unsure whether this
>parameter was meant to describe signatures types that the resource server
>could verify, or whether this was for signature types it could generate
>(and presumably held keys for signature generation).
>
>
>1. Does it cover algorithms for both verification and generation?
>   2. Given that this is an optional value, is it necessary to allow
>   the value of "none". If no signing algorithms are supported, is a better
>   approach to just not include this parameter (I reflect on security 
> issues
>   that may arise from alg:none type parameters)? If it has to be included,
>   are there security considerations that can be called out regarding this
>   parameter set to none?
>
>
>4. Parameter names suggest URIs (jwks_uri, resource_policy_uri,
>resource_tos_uri), but the description always scopes this down to URLs. I
>suspect there is some history behind these parameter name choices, but was
>curious if there are ever a case when the parameter value is expected to
>not be a URL? If this parameter value is always a URL, should the parameter
>name be changes to reflect this (again, I suspect there are reasons for the
>current choices, but curious about the inconsistency)?
>
>
>
> Section 3
>
>1. I found paragraphs 1-3 of this section hard to parse. I think the
>intent here is to say that an application may be composed of different
>protected resources, and each of those may have their own protected
>resource metadata and then specify how that might be done.
>
>
>1. Although paragraph 2 describes the way to do it, and illustrates it
>   with an example, it does not show the final result of such a 
> construction.
>   Would it be possible to include the final result of what the path would
>   look like when inserting the
>   "/.well-known/example-protected-resource" between the host and path
>   components of the protected resource's resource identifier just to 
> remove
>   opportunity for misinterpretation (is this the same as the second 
> example
>   given in Section 3.1, if so, perhaps refer to that example)?
>
>
>2. I was unsure how to interpret this sentence in paragraph 3: "An
>OAuth 2.0 application using this specification MUST specify what well-known
>URI string it will use for this purpose."
>
>
>1. Is this meant to refer to the IANA registration in paragraph 1, or
>   is there some other specification mechanism an OAuth application should 
> use
>   that consumers of the metadata can use to determine where to find the
>   resource metadata?
>   2. Is this related to the inclusion of the URL for the protected
>   resource metadata as described in Section 5?
>
>
>3. It looks like the validation rules in section 3.3 is intended as a
>mitigation for the attack described in section 7.3 (Impersonation Attacks).
>