Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Feb 2020 18:02:50 -0800

Added in user code interaction and aligned QR code to be a superset of user
code.
Fixed descriptions.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <[email-masked]>

A new version of I-D, draft-hardt-xauth-protocol-03.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:           draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth Protocol
Document date:  2020-02-18
Group:          Individual Submission
Pages:          53
URL:
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:
https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-03

Abstract:
   Client software often desires resources or identity claims that are
   independent of the client.  This protocol allows a user and/or
   resource owner to delegate resource authorization and/or release of
   identity claims to a server.  Client software can then request access
   to resources and/or identity claims by calling the server.  The
   server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to the client software
   the authorization and identity claims that were approved.  This
   protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication mechanisms.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

ᐧ

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 20 Feb 2020 20:21:16 +0000

Thanks for the update, Dick! I’m going to confine my comments here to interaction mode design, setting aside whether or not we need “popup”. :D

Once the GS hands that URI back to the Client, it has zero control over how the Client uses it. The Client could present any URI (of a reasonable size) into a QR code, or present it as a clickable link, or redirect to it, or open it in an external browser, or do any number of other as-yet-not-invented things with it. Moreover, the Client may not know yet what it wants to do with it. So what value is there in distinguishing between “I want a URI for a redirect” vs. “I want a URI for a QR code” vs. “I want a URI for <some other machine-driven interaction mode>”?

Even if we consider things like QR code data capacity, that’s really just a URI length limitation, which could apply to non-QR interaction modes, e.g., if the Client device wants to communicate the URI over an extremely bandwidth-constrained channel. And it’s not clear to me how including a URI length limitation in the request helps. If a GS is capable of generating a shorter URI, why wouldn’t it always return that? On the client side, it can look at the length of the URI provided and decide what to do with it (e.g., render a QR code or display it or do nothing with it).

So that really leaves us with two interaction modes that we need:

  *   “uri”, which returns a full URI that may not be human friendly; and
  *   “code”, which returns a code and URI for a code entry page, both of which are human-friendly.

Those could be combinable to get both, and even if we don’t go down the multiple interaction mode route we could add the full URI to the “code” interaction object. It wouldn’t hurt anything to do so.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Tuesday, February 18, 2020 at 6:04 PM
To: "[email-masked]" <[email-masked]>
Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt

Added in user code interaction and aligned QR code to be a superset of user code.
Fixed descriptions.

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>

Name:           draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth Protocol
Document date:  2020-02-18
Group:          Individual Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-03

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=533e5116-6e21-4a90-a1c9-ba7d870a87c9]ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Thu, 20 Feb 2020 15:11:53 -0800

On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> Thanks for the update, Dick! I’m going to confine my comments here to
> interaction mode design, setting aside whether or not we need “popup”. :D
>
>
>
> Once the GS hands that URI back to the Client, it has zero control over
> how the Client uses it. The Client could present any URI (of a reasonable
> size) into a QR code, or present it as a clickable link, or redirect to it,
> or open it in an external browser, or do any number of other
> as-yet-not-invented things with it. Moreover, the Client may not know yet
> what it wants to do with it.
>

Why would the Client not know what it wants to do with it? What would
change between when the Client called the GS, and the GS responded?

I think of the interaction being the Client saying "I want to do a
redirect", and the GS says, "ok, here is the URI". Or the Client says, "I
want to show only a code and a URI", and the GS says "ok, here is a good,
and an easy to read URI for the user to type in and navigate to.

I understand there are interactions that may not yet been invented yet.
More on that further down.

> So what value is there in distinguishing between “I want a URI for a
> redirect” vs. “I want a URI for a QR code” vs. “I want a URI for <some
> other machine-driven interaction mode>”?
>
>
>
> Even if we consider things like QR code data capacity, that’s really just
> a URI length limitation, which could apply to non-QR interaction modes,
> e.g., if the Client device wants to communicate the URI over an extremely
> bandwidth-constrained channel.
>

I don't understand when this would be the case. If the Client is going to
do a redirect, then the URI length is not significant.

> And it’s not clear to me how including a URI length limitation in the
> request helps. If a GS is capable of generating a shorter URI, why wouldn’t
> it always return that?
>

There may be a variety of reasons that a GS may want to provide a different
URI for a QR code than a redirect, or even a popup.

1) Perhaps the GS has only been supporting redirects, and has a very long
URL. They add support for a QR code, and use a 3P service that redirects
from the short URL used in the QR code, the the long URL. They don't want
to pay for the 3P service anymore than they have to.

2) The GS wants the QR code and user code flows to go through the same
machinery that looks up the code to find the Grant. The URI in a redirect
has the grant embedded in the URI. They don't want to have to use the code
to Grant machinery for all URIs.

3) A QR code flow will usually be done on a phone, and the GS wants to
attempt to launch a native app in some way,

While you are correct, we could make all URIs be short enough that they can
be easily scanned, why force that on implementors?

The URI length limitation concept was for the display_uri so that a
constrained device has an upper limit. A similar upper limit on QR code
would allow a constrained device to know the pixel resolution it needs to
show the QR code.

> On the client side, it can look at the length of the URI provided and
> decide what to do with it (e.g., render a QR code or display it or do
> nothing with it).
>

Per above, why would the Client not already know what experience it wants
to present to the User?

A URI to be displayed, and a URI to be redirected to are likely going to be
quite different.

The URI for a User to enter a code will likely be a static value that is
easy to type. The User will likely have to authenticate at that page, and
then be prompted to enter the code.

>    - “uri”, which returns a full URI that may not be human friendly; and
>    - “code”, which returns a code and URI for a code entry page, both of
>    which are human-friendly.
>
>
>
> Those could be combinable to get both, and even if we don’t go down the
> multiple interaction mode route we could add the full URI to the “code”
> interaction object. It wouldn’t hurt anything to do so.
>

In the latest version, I gave each URI its own name so that the GS can be
clear about how it will be used.

While we could squeeze all the functionality into a couple parameters, I
think it makes it harder for existing deployments to migrate to the
protocol. I think we should make it easy for developers to take what they
already have and use it with XAuth.

wrt. not-yet-invented interactions. These interactions are for
not-yet-described use cases. (if other use cases exist, then let's look at
them and add the interaction mechanisms if needed) We don't know what
parameters will be needed, and overloading the parameters and letting the
Client do whatever it wants does not seem like it will interoperate -- the
Client decides it wants to do some new interaction, and uses the parameters
in a way the GS does not understand.

> *From: *Txauth <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Tuesday, February 18, 2020 at 6:04 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Txauth] Fwd: New Version Notification for
> draft-hardt-xauth-protocol-03.txt
>
>
>
> Status:
> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Feb 2020 11:38:35 -0500

I’m in complete agreement with Annabelle. In XYZ we realized that both the QR Code and Authorization Code, and that the only difference is how the user gets back to the client. So instead of inventing a new type of interaction, we split them. In XYZ, we have:

 - redirect: tells the AS that the client can send the user to an arbitrary URL (and the AS doesn’t care how the client gets that info to the user; could be a redirect or an image or send a push notification to a secondary device, we don’t care as long as the user shows up in a browser at the AS — so maybe this field can be renamed to be more universally accurate)
 - code: tells the AS that the client can present a short code the user can type (along with a static URL the user can get to, maybe by typing the URL manually, but it’s not dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the client can receive the completion message from a front channel interaction through a redirect. Note that the client might have gotten to the AS through a redirect on-device, through a QR-code off device, or through some other magic, and this field isn’t concerned with that — it’s only concerned with how to get the user :back:.

These three can be combined in different ways depending on what you want to do at the client. Let’s say you’re doing and OAuth2 style authorization code, you’d use “redirect” and “callback” together. If you’re doing a plain user code, you’d use “code”. If you’re doing just a QR code with polling, you use just “redirect” to get the long URL. If you’re doing a user code and a QR code together, you use “redirect” and “code” to get the long URL and the short code not he screen at the same time. 

On top of that, they can be combined with other methods. Maybe I can send the user to an arbitrary URL but also display a human-readable verification code (like CIBA), or send something in a push notification but also give them a message to type, or I’m getting claims from an agent but I want them redirected back through the browser. The client gets to decide what kinds of interaction it can do and how to use these pieces in ways that make the most sense.

An interesting difference between XYZ and XAuth’s approaches is that XYZ keeps the concept of the “authorization code” in the callback response (which in turn is based on the OAuth 1 “oauth_verifier” field). In XYZ, you get an “interaction_ref” which is hashed along with a pair of nonces generated by the client and the AS in the back channel. This binds the front channel response to both the back channel request and the back channel response for a given transaction — and note that I’m really open to having a better way to generate and calculate such a binding, but I think this works. In any event, this protects the client from session fixation and injection on the return from the front channel that it’s susceptible to in a pure polling model, and the hashing approach basically combines the security parameters of the OAuth 2 authorization code and (to an extent) state, PKCE’s code_challenge, and OIDC’s nonce in one element. This is only applicable if you’re coming back to the client and you can validate the hash and present the reference parameter. If you’re doing just plain polling, you don’t have that protection — but the client and the AS are aware of that risk, and there’s an option to prevent it.

XAuth has removed the authorization code concept in its redirect return, and clients only do polling against the GS API in order to get tokens. While I obviously think it’s very valuable to remove things from the front channel, I don’t think this is something we can remove without opening up attack surfaces that have already been identified in previous protocols. I would like to understand why XAuth is not susceptible to the same kinds of attacks, or if it is, what mitigations there are for them. 

 — Justin

> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> “uri”, which returns a full URI that may not be human friendly; and
> “code”, which returns a code and URI for a code entry page, both of which are human-friendly.
>  
> https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/>
>  
>  
> From: <[email-masked] <mailto:[email-masked]>>
> To: Dick Hardt <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt <https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt>
> Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ <https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/>
> Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-03>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol <https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-03 <https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-03>
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> ᐧ
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 10:54:39 -0800

On Fri, Feb 21, 2020 at 8:38 AM Justin Richer <[email-masked]> wrote:

> I’m in complete agreement with Annabelle. In XYZ we realized that both
> the QR Code and Authorization Code, and that the only difference is how the
> user gets back to the client. So instead of inventing a new type of
> interaction, we split them. In XYZ, we have:
>

This sentence looks to be missing something.

>
>  - redirect: tells the AS that the client can send the user to an
> arbitrary URL (and the AS doesn’t care how the client gets that info to the
> user; could be a redirect or an image or send a push notification to a
> secondary device, we don’t care as long as the user shows up in a browser
> at the AS — so maybe this field can be renamed to be more universally
> accurate)
>

As stated in this thread, it may be useful for the AS to know if the URL
will be in a QR code, or in a full redirect.

In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has
to do, so it needs to know the difference between a popup, and a full
browser redirect. This is targetted at SPAs, where an additional URL to
redirect to is extra work.

>  - code: tells the AS that the client can present a short code the user
> can type (along with a static URL the user can get to, maybe by typing the
> URL manually, but it’s not dynamic/arbitrary like the redirect method)
>  - callback: tells the AS that the client can receive the completion
> message from a front channel interaction through a redirect. Note that the
> client might have gotten to the AS through a redirect on-device, through a
> QR-code off device, or through some other magic, and this field isn’t
> concerned with that — it’s only concerned with how to get the user :back:.
>

In a full redirect, the Client wants the AS to send the user back so that
it can continue.

The only parameter in the completion message is the nonce, which seems
superfluous. See below.

>
> These three can be combined in different ways depending on what you want
> to do at the client. Let’s say you’re doing and OAuth2 style authorization
> code, you’d use “redirect” and “callback” together. If you’re doing a plain
> user code, you’d use “code”. If you’re doing just a QR code with polling,
> you use just “redirect” to get the long URL. If you’re doing a user code
> and a QR code together, you use “redirect” and “code” to get the long URL
> and the short code not he screen at the same time.
>
> On top of that, they can be combined with other methods. Maybe I can send
> the user to an arbitrary URL but also display a human-readable verification
> code (like CIBA), or send something in a push notification but also give
> them a message to type, or I’m getting claims from an agent but I want them
> redirected back through the browser. The client gets to decide what kinds
> of interaction it can do and how to use these pieces in ways that make the
> most sense.
>

Per my question later in this thread, why would the Client not know what
interaction it wants prior to the request?

If the AS is doing CIBA, that is not a decision just for the Client. Both
the AS and the Client need to know they are doing CIBA. (FWIW: I think this
work supersedes CIBA)

Additionally, different interactions have different risk profiles.
Sophisticated ASes will use that signal in the risk assessment, and may do
ask for additional authentication or verification.

>
> An interesting difference between XYZ and XAuth’s approaches is that XYZ
> keeps the concept of the “authorization code” in the callback response
> (which in turn is based on the OAuth 1 “oauth_verifier” field). In XYZ, you
> get an “interaction_ref” which is hashed along with a pair of nonces
> generated by the client and the AS in the back channel. This binds the
> front channel response to both the back channel request and the back
> channel response for a given transaction — and note that I’m really open to
> having a better way to generate and calculate such a binding, but I think
> this works. In any event, this protects the client from session fixation
> and injection on the return from the front channel that it’s susceptible to
> in a pure polling model, and the hashing approach basically combines the
> security parameters of the OAuth 2 authorization code and (to an extent)
> state, PKCE’s code_challenge, and OIDC’s nonce in one element. This is only
> applicable if you’re coming back to the client and you can validate the
> hash and present the reference parameter. If you’re doing just plain
> polling, you don’t have that protection — but the client and the AS are
> aware of that risk, and there’s an option to prevent it.
>
> XAuth has removed the authorization code concept in its redirect return,
> and clients only do polling against the GS API in order to get tokens.
> While I obviously think it’s very valuable to remove things from the front
> channel, I don’t think this is something we can remove without opening up
> attack surfaces that have already been identified in previous protocols. I
> would like to understand why XAuth is not susceptible to the same kinds of
> attacks, or if it is, what mitigations there are for them.
>

Unlike OAuth 2.0, there are no parameters in the front channel response to
the Client. The redirect back to the Client is only needed to return the
interaction back to the Client.

XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0)

In OAuth, the AS gives a code to the User to give to the Client that the
Client then gives to the GS.

In XAuth, the AS gives a "code" to the Client that givers it to the User to
give to the GS.

In XAuth, the "code" is either a user code, or something embedded in the
URI the User is redirected to.

Therefore, there is nothing to protect in the redirect back to the Client.

If I'm missing an attack, please elaborate how it would happen.

>
>  — Justin
>
> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <
> richanna=[email-masked]> wrote:
>
> what it wants to do with it. So what value is there in distinguishing
> between “I want a URI for a redirect” vs. “I want a URI for a QR code” vs.
> “I want a URI for <some other machine-driven interaction mode>”?
>
> bandwidth-constrained channel. And it’s not clear to me how including a URI
> length limitation in the request helps. If a GS is capable of generating a
> shorter URI, why wouldn’t it always return that? On the client side, it can
> look at the length of the URI provided and decide what to do with it (e.g.,
> render a QR code or display it or do nothing with it).
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Feb 2020 14:31:34 -0500

On Feb 21, 2020, at 1:54 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:

Apologies: We realized they both used AS-composed URLs to get the user to the AS in a web browser for interaction purposes.

> As stated in this thread, it may be useful for the AS to know if the URL will be in a QR code, or in a full redirect.
> 
> In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has to do, so it needs to know the difference between a popup, and a full browser redirect. This is targetted at SPAs, where an additional URL to redirect to is extra work.
>  
> In a full redirect, the Client wants the AS to send the user back so that it can continue.
> 
> The only parameter in the completion message is the nonce, which seems superfluous. See below.
>  
> 
> Per my question later in this thread, why would the Client not know what interaction it wants prior to the request?

What do you mean? The client does know what it wants and that’s why it’s asking for what it wants. We’re debating different methods for the client to ask for what it wants. This question does not make sense to me.

> 
> If the AS is doing CIBA, that is not a decision just for the Client. Both the AS and the Client need to know they are doing CIBA. (FWIW: I think this work supersedes CIBA)

As I’ve stated previously, I believe the interaction methods here can supersede CIBA.

> 
> Additionally, different interactions have different risk profiles. Sophisticated ASes will use that signal in the risk assessment, and may do ask for additional authentication or verification.
>  

Yes, exactly my point. Because different interactions have different risks, the AS will need to be able to decide which interactions it’s OK with for a given request. This could vary based on what’s being requested, or who’s doing the requesting.

> Unlike OAuth 2.0, there are no parameters in the front channel response to the Client. The redirect back to the Client is only needed to return the interaction back to the Client.

This argument rings tautologically hollow — there are no parameters because you’ve defined that there aren’t any in XAuth. XYZ does have parameters, to tie the front and back channel requests together when doing redirect back and forth.

If you’re not doing a redirect back (ie, not sending a “callback” interaction block), then it’s a polling mechanism like XAuth, the device flow, etc. There are very real risks to this.

> In OAuth, the AS gives a code to the User to give to the Client that the Client then gives to the GS.
> 
> In XAuth, the AS gives a "code" to the Client that givers it to the User to give to the GS.
> 
> In XAuth, the "code" is either a user code, or something embedded in the URI the User is redirected to.
> 

One form of impersonation is well documented: https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759250a0e7

OAuth 1.0’s “Request Token” is a similar request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it’s susceptible to the same kind of issue.

>  
> 
>  — Justin
> 
>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>> wrote:
>> 
>> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 12:40:12 -0800

The lightbulb finally clicked on for me. Thanks for your patience.

The threat you are describing is where the attacker starts a transaction at
the client, and gets the victim to complete it. Correct?

I still think the Client should be able to signal if it will be doing a
redirect vs showing a QR code (or wants to do both).

Being able to provide a completion URI even if the user is starting on a
device is a great insight on how to address the threat above.

I'm going to ponder how to align XAuth more with these features of XYZ.
ᐧ

On Fri, Feb 21, 2020 at 11:31 AM Justin Richer <[email-masked]> wrote:

> Apologies: We realized they both used AS-composed URLs to get the user to
> the AS in a web browser for interaction purposes.
>
>
>
>>
> In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client
> has to do, so it needs to know the difference between a popup, and a full
> What do you mean? The client does know what it wants and that’s why it’s
> asking for what it wants. We’re debating different methods for the client
> to ask for what it wants. This question does not make sense to me.
>
>
> Yes, exactly my point. Because different interactions have different
> risks, the AS will need to be able to decide which interactions it’s OK
> with for a given request. This could vary based on what’s being requested,
> or who’s doing the requesting.
>
>
> This argument rings tautologically hollow — there are no parameters
> because you’ve defined that there aren’t any in XAuth. XYZ does have
> parameters, to tie the front and back channel requests together when doing
> redirect back and forth.
>
> If you’re not doing a redirect back (ie, not sending a “callback”
> interaction block), then it’s a polling mechanism like XAuth, the device
> flow, etc. There are very real risks to this.
>
>
> One form of impersonation is well documented:
> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759250a0e7
>
> OAuth 1.0’s “Request Token” is a similar request initiation step to what
> we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it’s susceptible to the same
> kind of issue.
>
>
>
>>
>>  — Justin
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 12:52:15 -0800

I got ahead of myself. A completion URI protects the User only if the User
is sent back to the same channel the transaction started so the Client can
confirm it is the same User that started the transaction.

so this does not help the security:

"Being able to provide a completion URI even if the user is starting on a
device is a great insight on how to address the threat above."

ᐧ

On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt <[email-masked]> wrote:

> The threat you are describing is where the attacker starts a transaction
> at the client, and gets the victim to complete it. Correct?
>
>>> On top of that, they can be combined with other methods. Maybe I can
>>> send the user to an arbitrary URL but also display a human-readable
>>> verification code (like CIBA), or send something in a push notification but
>>> also give them a message to type, or I’m getting claims from an agent but I
>>> want them redirected back through the browser. The client gets to decide
>>> what kinds of interaction it can do and how to use these pieces in ways
>>> that make the most sense.
>>>
>>
>> Unlike OAuth 2.0, there are no parameters in the front channel response
>> to the Client. The redirect back to the Client is only needed to return the
>>> Even if we consider things like QR code data capacity, that’s really
>>> just a URI length limitation, which could apply to non-QR interaction
>>> modes, e.g., if the Client device wants to communicate the URI over an
>>> extremely bandwidth-constrained channel. And it’s not clear to me how
>>> including a URI length limitation in the request helps. If a GS is capable
>>> of generating a shorter URI, why wouldn’t it always return that? On the
>>> client side, it can look at the length of the URI provided and decide what
>>> to do with it (e.g., render a QR code or display it or do nothing with it).
>>>
>>>    - “code”, which returns a code and URI for a code entry page, both
>>>    of which are human-friendly.
>>>
>>>
>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03
>>> Htmlized:

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Feb 2020 16:01:57 -0500

But that’s exactly the point — it helps in that case, which is a very common case. For cases where the client doesn’t expect the user to come back on the same channel, then they don’t use the callback mechanism. They might use the “finish message” URL that Annabelle mentioned in the other thread, or they might just print out “you’re done now!” at the AS, which is common today.

XYZ’s interaction structure allows the composition of these things, under the control of the client. This is exactly why it’s important to be able to specify how to get to the AS and how to get back as separate items, so that the client can compose the combination that makes the most sense for that client.

 — Justin

> On Feb 21, 2020, at 3:52 PM, Dick Hardt <[email-masked]> wrote:
> 
> I got ahead of myself. A completion URI protects the User only if the User is sent back to the same channel the transaction started so the Client can confirm it is the same User that started the transaction.
> 
> "Being able to provide a completion URI even if the user is starting on a device is a great insight on how to address the threat above."
> 
> ᐧ
> 
> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> The threat you are describing is where the attacker starts a transaction at the client, and gets the victim to complete it. Correct?
> 
> I still think the Client should be able to signal if it will be doing a redirect vs showing a QR code (or wants to do both).
> 
> Being able to provide a completion URI even if the user is starting on a device is a great insight on how to address the threat above. 
> 
> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Feb 21, 2020, at 1:54 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> One form of impersonation is well documented: https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759250a0e7 <https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759250a0e7>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 13:14:57 -0800

While I can see the value of the interact_ref (aka interaction_ref) in the
return URI that allows the Client to ensure the user that started the
transaction is the same one that interacted at the AS, I don't understand
why a hash is required. Would you elaborate?
ᐧ

On Fri, Feb 21, 2020 at 1:02 PM Justin Richer <[email-masked]> wrote:

> But that’s exactly the point — it helps in that case, which is a very
> common case. For cases where the client doesn’t expect the user to come
> back on the same channel, then they don’t use the callback mechanism. They
> might use the “finish message” URL that Annabelle mentioned in the other
> thread, or they might just print out “you’re done now!” at the AS, which is
> common today.
>
> XYZ’s interaction structure allows the composition of these things, under
> the control of the client. This is exactly why it’s important to be able to
> specify how to get to the AS and how to get back as separate items, so that
> the client can compose the combination that makes the most sense for that
> client.
>
>  — Justin
>
>
>>> Apologies: We realized they both used AS-composed URLs to get the user
>>> to the AS in a web browser for interaction purposes.
>>>
>>>
>>>
>>>>
>>>> These three can be combined in different ways depending on what you
>>>> want to do at the client. Let’s say you’re doing and OAuth2 style
>>>> authorization code, you’d use “redirect” and “callback” together. If you’re
>>>> doing a plain user code, you’d use “code”. If you’re doing just a QR code
>>>> with polling, you use just “redirect” to get the long URL. If you’re doing
>>>> a user code and a QR code together, you use “redirect” and “code” to get
>>>> the long URL and the short code not he screen at the same time.
>>>>
>>> If the AS is doing CIBA, that is not a decision just for the Client.
>>> Both the AS and the Client need to know they are doing CIBA. (FWIW: I think
>>> this work supersedes CIBA)
>>>
>>>
>>>> An interesting difference between XYZ and XAuth’s approaches is that
>>>> XYZ keeps the concept of the “authorization code” in the callback response
>>>> XAuth has removed the authorization code concept in its redirect
>>>> return, and clients only do polling against the GS API in order to get
>>>> tokens. While I obviously think it’s very valuable to remove things from
>>>> the front channel, I don’t think this is something we can remove without
>>>> opening up attack surfaces that have already been identified in previous
>>>> protocols. I would like to understand why XAuth is not susceptible to the
>>>> same kinds of attacks, or if it is, what mitigations there are for them.
>>>>
>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Feb 2020 16:51:47 -0500

The hash offers the same kinds of protections to the client that the OIDC nonce does — it binds the front channel return to something you get from the back channel. 

In other words, the client can be sure that the return value that it’s getting is related to the request it made in the first place, and not another one. Clients using per-request redirect URIs can also help with this, but this is something that the server can provide directly.

 — Justin

> On Feb 21, 2020, at 4:14 PM, Dick Hardt <[email-masked]> wrote:
> 
> While I can see the value of the interact_ref (aka interaction_ref) in the return URI that allows the Client to ensure the user that started the transaction is the same one that interacted at the AS, I don't understand why a hash is required. Would you elaborate?
> ᐧ
> 
> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 21, 2020, at 3:52 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 22 Feb 2020 00:46:07 +0000

Okay, you’ve convinced me that there are use cases for a GS to sometimes provide a shorter URI and sometimes a longer URI. Let’s see if I can convince you that interaction mode selection is less deterministic than you think. :D

I *think* the Client can be expected to know if it will transfer interaction to the GS within the same user agent the end user is accessing Client through. In other words, I think there are two reliably differentiable modes: same UA (30X redirect, open in same window, open in new), and different UA (code, QR code, opening URI in external browser, etc.). However, within each mode, the Client may not know which mechanism will be used. (e.g., for “same UA”: will the Client open the URI in the same window or a new one; for “different UA”: will the end user scan a QR code or enter a code or tap on a URI in an SMS)

The non-determinism comes from two sources:

  1.  Environmental conditions
     *   A console app might be able to directly open a URI in the system’s browser (e.g., when running in a terminal window on a desktop), or it might not (e.g., on a headless system). The app may not know the answer until it tries it.
     *   That same console app might be running in a remote terminal, such that the end user would be able to click or copy and paste a URI printed by the app.
     *   An SPA might be able to open a popup, or it might fail for various reasons. It might decide to fall back to a redirect if it detects that the popup failed to open. It might want the “popup” to gracefully fall back to a redirect-like experience in case the user agent only supports a single window at a time (e.g., embedded user agents in apps like Facebook and Twitter).
     *   Environmental conditions may make it difficult to scan a QR code (e.g., the screen is dirty, foggy, cracked, or under direct sunlight), but still allow for a person to read a short code. The Client likely has no way of detecting such things.
  2.  End user capabilities and preferences
     *   They may have a physical disability or other condition that makes it difficult to impossible for them to scan a QR code.

                                                               i.      They may be capable of reading and copying a short code.

                                                             ii.      They may be capable of listening to and entering a short code spoken by the device.

                                                           iii.      They may be capable of following a link sent to them via text or email, which they can access on a device with greater accessibility options.

     *   They may not have a device capable of scanning a QR code, or the device may not be functioning, or the device may be the one that the code is being displayed on.
     *   They may not know what a QR code is, or understand how to use one.
     *   They may want to complete the flow on a device that is incapable of scanning the QR code (e.g., their desktop).
     *   They may prefer to have the URI texted or emailed to them, rather than having to scan or copy a code.
     *   They may not have access to the companion app that the Client transmitted the URI to (e.g., because it’s on the shared family tablet, and it’s their sibling’s turn to use it).

If we allow that the GS might want to issue long URIs when possible, then there’s basically three things a Client might want, in any combination:

  *   URI, no length restriction
  *   URI, with some max length (e.g., because of QR code data capacity, SMS message size limits, display constraints, etc.)
  *   Short code and code entry URI, both human-friendly

The GS can’t enforce how these are used; they can only control what they issue, and how they respond when interaction is transferred to them. Defining interaction object properties in terms of usage implies constraints and guarantees that don’t exist, and Clients are going to disregard our prescribed uses anyway (e.g., by sending a “qrcode” URI in an SMS).

–

From: Dick Hardt <[email-masked]>
Date: Thursday, February 20, 2020 at 3:13 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt

On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the update, Dick! I’m going to confine my comments here to interaction mode design, setting aside whether or not we need “popup”. :D

Once the GS hands that URI back to the Client, it has zero control over how the Client uses it. The Client could present any URI (of a reasonable size) into a QR code, or present it as a clickable link, or redirect to it, or open it in an external browser, or do any number of other as-yet-not-invented things with it. Moreover, the Client may not know yet what it wants to do with it.

Why would the Client not know what it wants to do with it? What would change between when the Client called the GS, and the GS responded?

I think of the interaction being the Client saying "I want to do a redirect", and the GS says, "ok, here is the URI". Or the Client says, "I want to show only a code and a URI", and the GS says "ok, here is a good, and an easy to read URI for the user to type in and navigate to.

I understand there are interactions that may not yet been invented yet. More on that further down.

So what value is there in distinguishing between “I want a URI for a redirect” vs. “I want a URI for a QR code” vs. “I want a URI for <some other machine-driven interaction mode>”?

Even if we consider things like QR code data capacity, that’s really just a URI length limitation, which could apply to non-QR interaction modes, e.g., if the Client device wants to communicate the URI over an extremely bandwidth-constrained channel.

I don't understand when this would be the case. If the Client is going to do a redirect, then the URI length is not significant.

And it’s not clear to me how including a URI length limitation in the request helps. If a GS is capable of generating a shorter URI, why wouldn’t it always return that?

There may be a variety of reasons that a GS may want to provide a different URI for a QR code than a redirect, or even a popup.

1) Perhaps the GS has only been supporting redirects, and has a very long URL. They add support for a QR code, and use a 3P service that redirects from the short URL used in the QR code, the the long URL. They don't want to pay for the 3P service anymore than they have to.

2) The GS wants the QR code and user code flows to go through the same machinery that looks up the code to find the Grant. The URI in a redirect has the grant embedded in the URI. They don't want to have to use the code to Grant machinery for all URIs.

3) A QR code flow will usually be done on a phone, and the GS wants to attempt to launch a native app in some way,

While you are correct, we could make all URIs be short enough that they can be easily scanned, why force that on implementors?

The URI length limitation concept was for the display_uri so that a constrained device has an upper limit. A similar upper limit on QR code would allow a constrained device to know the pixel resolution it needs to show the QR code.

On the client side, it can look at the length of the URI provided and decide what to do with it (e.g., render a QR code or display it or do nothing with it).

Per above, why would the Client not already know what experience it wants to present to the User?

A URI to be displayed, and a URI to be redirected to are likely going to be quite different.

The URI for a User to enter a code will likely be a static value that is easy to type. The User will likely have to authenticate at that page, and then be prompted to enter the code.

·      “uri”, which returns a full URI that may not be human friendly; and

·      “code”, which returns a code and URI for a code entry page, both of which are human-friendly.

In the latest version, I gave each URI its own name so that the GS can be clear about how it will be used.

While we could squeeze all the functionality into a couple parameters, I think it makes it harder for existing deployments to migrate to the protocol. I think we should make it easy for developers to take what they already have and use it with XAuth.

wrt. not-yet-invented interactions. These interactions are for not-yet-described use cases. (if other use cases exist, then let's look at them and add the interaction mechanisms if needed) We don't know what parameters will be needed, and overloading the parameters and letting the Client do whatever it wants does not seem like it will interoperate -- the Client decides it wants to do some new interaction, and uses the parameters in a way the GS does not understand.

–

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 18, 2020 at 6:04 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 17:12:26 -0800

The Client presents the interact_ref to the AS with the transaction handle.
The AS will be able to tell the Client if the interact_ref belongs to the
transaction.

Why is that enough?
ᐧ

On Fri, Feb 21, 2020 at 1:51 PM Justin Richer <[email-masked]> wrote:

> The hash offers the same kinds of protections to the client that the OIDC
> nonce does — it binds the front channel return to something you get from
> the back channel.
>
> In other words, the client can be sure that the return value that it’s
> getting is related to the request it made in the first place, and not
> another one. Clients using per-request redirect URIs can also help with
> this, but this is something that the server can provide directly.
>
>  — Justin
>
>> I got ahead of myself. A completion URI protects the User only if the
>> User is sent back to the same channel the transaction started so the Client
>> can confirm it is the same User that started the transaction.
>>
>>>>> I’m in complete agreement with Annabelle. In XYZ we realized that
>>>>> both the QR Code and Authorization Code, and that the only difference is
>>>>> how the user gets back to the client. So instead of inventing a new
>>>>> type of interaction, we split them. In XYZ, we have:
>>>>>
>>>>
>>>> As stated in this thread, it may be useful for the AS to know if the
>>>> URL will be in a QR code, or in a full redirect.
>>>>
>>>>>  - code: tells the AS that the client can present a short code the
>>>>> user can type (along with a static URL the user can get to, maybe by typing
>>>>> the URL manually, but it’s not dynamic/arbitrary like the redirect method)
>>>> Per my question later in this thread, why would the Client not know
>>>> what interaction it wants prior to the request?
>>>>
>>>>
>>>> What do you mean? The client does know what it wants and that’s why
>>>> it’s asking for what it wants. We’re debating different methods for the
>>>> client to ask for what it wants. This question does not make sense to me.
>>>>
>>>>
>>>> OAuth 1.0’s “Request Token” is a similar request initiation step to
>>>> what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it’s susceptible to the
>>>> same kind of issue.
>>>>
>>>>
>>>>
>>>>>
>>>>>  — Justin
>>>>>
>>>>> Once the GS hands that URI back to the Client, it has zero control
>>>>> over how the Client uses it. The Client could present any URI (of a
>>>>> reasonable size) into a QR code, or present it as a clickable link, or
>>>>> redirect to it, or open it in an external browser, or do any number of
>>>>> other as-yet-not-invented things with it. Moreover, the Client may not know
>>>>> yet what it wants to do with it. So what value is there in distinguishing
>>>>> Those could be combinable to get both, and even if we don’t go down
>>>>> the multiple interaction mode route we could add the full URI to the “code”

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 17:36:12 -0800

Thanks Annabelle.

FYI: With the requirement to have a interact_ref value come back from the
GS to the Client, the popup and redirect are now the same -- so we can move
past the popup discussion.

To summarize your examples,
1) the Client may need to fallback to a different method than it initially
had planned on
2) the Client may want to offer the User a broader choice of methods

(1) could be solved by the Client making a new request of the GS

(2) requires the Client to receive multiple methods so it can offer the
User a choice.

Am I following along correctly

A short URI and a long URI are functionally equivalent -- so there does not
seem to be a requirement to have both.
For example, the Client may request a URI, with an optional max length?

So that let's the Client ask for one or both of:

- a URI with an optional max length ( indicate it has a static max length)
- a short code and code entry URI

If and when new mechanism for the Client to transfer interactions to the
GS, new parameters are defined.

Q: what is MTI?

Q: Is there a minimum length of the short URI? ( think that specifying a
short URI max length will make it easier for Clients and GS as it is not
negotiated)

/Dick

ᐧ

On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> Okay, you’ve convinced me that there are use cases for a GS to sometimes
> provide a shorter URI and sometimes a longer URI. Let’s see if I can
> convince you that interaction mode selection is less deterministic than you
> think. :D
>
>
>
> I **think** the Client can be expected to know if it will transfer
> interaction to the GS within the same user agent the end user is accessing
> Client through. In other words, I think there are two reliably
> differentiable modes: same UA (30X redirect, open in same window, open in
> new), and different UA (code, QR code, opening URI in external browser,
> etc.). However, within each mode, the Client may not know which mechanism
> will be used. (e.g., for “same UA”: will the Client open the URI in the
> same window or a new one; for “different UA”: will the end user scan a QR
> code or enter a code or tap on a URI in an SMS)
>
>
>
>       1. A console app might be able to directly open a URI in the
>       system’s browser (e.g., when running in a terminal window on a desktop), or
>       it might not (e.g., on a headless system). The app may not know the answer
>       until it tries it.
>       2. That same console app might be running in a remote terminal,
>       such that the end user would be able to click or copy and paste a URI
>       printed by the app.
>       3. An SPA might be able to open a popup, or it might fail for
>       various reasons. It might decide to fall back to a redirect if it detects
>       that the popup failed to open. It might want the “popup” to gracefully fall
>       back to a redirect-like experience in case the user agent only supports a
>       single window at a time (e.g., embedded user agents in apps like Facebook
>       and Twitter).
>       4. Environmental conditions may make it difficult to scan a QR code
>       (e.g., the screen is dirty, foggy, cracked, or under direct sunlight), but
>       still allow for a person to read a short code. The Client likely has no way
>       of detecting such things.
>       1. They may have a physical disability or other condition that
>       makes it difficult to impossible for them to scan a QR code.
>
>                                                                i.      They
> may be capable of reading and copying a short code.
>
>                                                              ii.      They
> may be capable of listening to and entering a short code spoken by the
> device.
>
>                                                            iii.      They
> may be capable of following a link sent to them via text or email, which
> they can access on a device with greater accessibility options.
>
>    1. They may not have a device capable of scanning a QR code, or the
>       device may not be functioning, or the device may be the one that the code
>       is being displayed on.
>       2. They may not know what a QR code is, or understand how to use
>       one.
>       3. They may want to complete the flow on a device that is incapable
>       of scanning the QR code (e.g., their desktop).
>       4. They may prefer to have the URI texted or emailed to them,
>       rather than having to scan or copy a code.
>       5. They may not have access to the companion app that the Client
>       transmitted the URI to (e.g., because it’s on the shared family tablet, and
>       it’s their sibling’s turn to use it).
>
>
>
> If we allow that the GS might want to issue long URIs when possible, then
> there’s basically three things a Client might want, in any combination:
>
>    - URI, no length restriction
>    - URI, with some max length (e.g., because of QR code data capacity,
>    SMS message size limits, display constraints, etc.)
>    - Short code and code entry URI, both human-friendly
>
>
>
> The GS can’t enforce how these are used; they can only control what they
> issue, and how they respond when interaction is transferred to them.
> Defining interaction object properties in terms of usage implies
> constraints and guarantees that don’t exist, and Clients are going to
> disregard our prescribed uses anyway (e.g., by sending a “qrcode” URI in an
> SMS).
>
>
>
> –
>
> *From: *Dick Hardt <[email-masked]>
> *Date: *Thursday, February 20, 2020 at 3:13 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Txauth] Fwd: New Version Notification for
> There may be a variety of reasons that a GS may want to provide a
> different URI for a QR code than a redirect, or even a popup.
>
>
>
> While you are correct, we could make all URIs be short enough that they
> can be easily scanned, why force that on implementors?
>
>
>

---

From: David Waite <[email-masked]>
Date: Sat, 22 Feb 2020 00:04:15 -0700

> On Feb 21, 2020, at 9:38 AM, Justin Richer <[email-masked]> wrote:
> 
<snip>
>  - code: tells the AS that the client can present a short code the user can type (along with a static URL the user can get to, maybe by typing the URL manually, but it’s not dynamic/arbitrary like…

This is going to need a different name :-)

> These three can be combined in different ways depending on what you want to do at the client. Let’s say you’re doing and OAuth2 style authorization code, you’d use “redirect” and “callback” togethe…

Some implementations may have the redirect and device code + static URL be the same URLs, but some may actually be de-optimizing for the device cases where the user may need to type the values in by hand or to reduce QR code complexity for scanning from across a room on a television. Having redirect and QR code interaction URLs be the same seems limiting in this regard.

The semantics of trying to leverage the QR code and browser redirect/callback also make me nervous w.r.t implementations, as in one case the callback may go back to a local context (e.g. single-page web application or native app) while the short code/QR code entry case would have the authentication/consent and subsequent callback happen “unsolicited” on another device.

Thats not to say that these initiation and resumption aspects couldn’t be split, I’m just concerned about these particular lines being ambitious.

> On top of that, they can be combined with other methods. Maybe I can send the user to an arbitrary URL but also display a human-readable verification code (like CIBA), or send something in a push n…

There needs to be fixed semantics for combining interaction facets, however. Would your client send a prioritized list where the AS chooses one that they support, or would the expectation be that you would then need to present the user the option to continue with either a redirect or via a QR code on another device?

-DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 24 Feb 2020 21:18:32 +0000

I think your summary is accurate, but the line between your two reasons gets pretty blurry. The Client may not be able to detect on its own whether its preferred method is working, so your proposal that the Client could switch methods by making a new request would require the end user to provide some input. For example:

  *   If a web browser is available but the firewall blocks outbound HTTP (not unreasonable for a server host), the Client would think that it successfully opened the URI.
  *   If the local browser lacks the accessibility features needed by the end user, the Client would successfully open the URI, but it would not be usable by the end user.
  *   In the “shared family tablet” example in my previous email, the Client would not be aware that the end user is unable to interact with the companion app.

So it’s easier for both Client and end user, and more generally applicable if the Client can request multiple interaction modes and present them at the same time.

If we only have a single “uri” parameter, the max length in the request should be advisory. I.e., the GS SHALL return a URI, and it SHOULD return one that meets the max length restriction if it can. Client behavior is effectively the same as if it were treated as a hard requirement; the only difference is that the Client code branches based on the actual length of the URI returned (which it already needs to check) rather than based on the presence or absence of a URI, or an error response from the GS. Clients that can still make use of a longer URI are saved the extra round trip to request one.

I think both “uri” and “code” should be MTI, but that does not mean they are mandatory to deploy. There’s lots of cases where a GS will only ever deal with specific types of Clients such that they’ll always use one or the other, but in those cases the GS is explicitly not concerned overmuch with interoperability.

We need to be careful about defining a maximum length for the code entry URI. Domain names cost money to register and maintain, so a maximum length that is too low would effectively impose a monetary barrier to deployers who have long domain names. We would also have to make this a maximum Unicode character length with the domain name expressed in IDN form, not ASCII form. Users of non-Western scripts should not be penalized by the need to use Punycode.

–

Date: Friday, February 21, 2020 at 5:37 PM

Thanks Annabelle.

FYI: With the requirement to have a interact_ref value come back from the GS to the Client, the popup and redirect are now the same -- so we can move past the popup discussion.

To summarize your examples,
1) the Client may need to fallback to a different method than it initially had planned on
2) the Client may want to offer the User a broader choice of methods

(2) requires the Client to receive multiple methods so it can offer the User a choice.

A short URI and a long URI are functionally equivalent -- so there does not seem to be a requirement to have both.
For example, the Client may request a URI, with an optional max length?

If and when new mechanism for the Client to transfer interactions to the GS, new parameters are defined.

Q: what is MTI?

Q: Is there a minimum length of the short URI? ( think that specifying a short URI max length will make it easier for Clients and GS as it is not negotiated)

/Dick

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=410679a4-824c-4fc3-82a1-69842a47a051]ᐧ

On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Okay, you’ve convinced me that there are use cases for a GS to sometimes provide a shorter URI and sometimes a longer URI. Let’s see if I can convince you that interaction mode selection is less deterministic than you think. :D

a.    A console app might be able to directly open a URI in the system’s browser (e.g., when running in a terminal window on a desktop), or it might not (e.g., on a headless system). The app may not know the answer until it tries it.

b.   That same console app might be running in a remote terminal, such that the end user would be able to click or copy and paste a URI printed by the app.

c.    An SPA might be able to open a popup, or it might fail for various reasons. It might decide to fall back to a redirect if it detects that the popup failed to open. It might want the “popup” to gracefully fall back to a redirect-like experience in case the user agent only supports a single window at a time (e.g., embedded user agents in apps like Facebook and Twitter).

d.   Environmental conditions may make it difficult to scan a QR code (e..g., the screen is dirty, foggy, cracked, or under direct sunlight), but still allow for a person to read a short code. The Client likely has no way of detecting such things.

a.    They may have a physical disability or other condition that makes it difficult to impossible for them to scan a QR code.

b.   They may not have a device capable of scanning a QR code, or the device may not be functioning, or the device may be the one that the code is being displayed on.

c.    They may not know what a QR code is, or understand how to use one.

d.   They may want to complete the flow on a device that is incapable of scanning the QR code (e.g., their desktop).

e.    They may prefer to have the URI texted or emailed to them, rather than having to scan or copy a code.

f.     They may not have access to the companion app that the Client transmitted the URI to (e.g., because it’s on the shared family tablet, and it’s their sibling’s turn to use it).

·      URI, no length restriction

·      URI, with some max length (e.g., because of QR code data capacity, SMS message size limits, display constraints, etc.)

·      Short code and code entry URI, both human-friendly

–

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 20, 2020 at 3:13 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt

•      “uri”, which returns a full URI that may not be human friendly; and

•      “code”, which returns a code and URI for a code entry page, both of which are human-friendly.

–

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>

Htmlized:       https://datatracker..ietf.org/doc/html/draft-hardt-xauth-protocol<https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol>

Abstract:

The IETF Secretariat

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 Feb 2020 10:38:36 -0500

That’s good enough for the AS, but is it good enough for the client? The hash allows the client to make sure that the reference they’re getting back in the front channel is related to something they sent out in the first place. We originally had a “state” parameter like OAuth 2 for this purpose, but realized that since the client can push its callback URI we didn’t need that. But to get the kind of functionality that “nonce” and “c_hash” have in OIDC, we added this simple hash parameter that the client can check before it calls the TX endpoint again.

 — Justin

> On Feb 21, 2020, at 8:12 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> The Client presents the interact_ref to the AS with the transaction handle. The AS will be able to tell the Client if the interact_ref belongs to the transaction.
> 
> Why is that enough?
> ᐧ
> 
> On Fri, Feb 21, 2020 at 1:51 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 21, 2020, at 4:14 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 Feb 2020 10:51:26 -0500

> This is going to need a different name :-)

That’s fair.

> Some implementations may have the redirect and device code + static URL be the same URLs, but some may actually be de-optimizing for the device cases where the user may need to type the values in b…

I’m not sure how this is limiting. I think that maybe you’re misunderstanding what I’m referring to as a QR Code URL here. There are two URLs in the XYZ implementation:

  - a static URL used with the short user-code; it can be displayed by the client or it can be read in documentation, since it’s not supposed to change
  - a dynamic (arbitrary) URL used for redirect and rendering QR codes for second-device interaction

The QR Code case that I’ve been referring to is analogous to the OAuth 2 Device Flow’s “combined” URL — except that it doesn’t have to have anything to do with the user code anymore, if the AS doesn’t want it to. All that’s really important is that the AS tells the client “get the user to this URL so I can interact with them”. How the client manages to do that isn’t the AS’s job to figure out.

If a client decides to also render the static URL as a QR code, then that’s fine — but that’s not the kind of QR code that’s been under discussion here. If there are size limitations, as per the other thread, then that can be communicated, or potentially requested alongside the long URL.

> Thats not to say that these initiation and resumption aspects couldn’t be split, I’m just concerned about these particular lines being ambitious.

This is exactly why the “callback” parameter was separated out. If the client doesn’t expect the user to come back locally, and it expects to poll, it doesn’t send the “callback” field. If it expects the user to come back, it sends one, and doesn’t poll. This is independent of (or at least orthogonal to) how the user gets TO the AS in the first place.

> There needs to be fixed semantics for combining interaction facets, however. Would your client send a prioritized list where the AS chooses one that they support, or would the expectation be that y…

I don’t think that’s really true. The client knows how it can interact with the user, and it’ll give the user the options that it can handle. This is the value of having an inline negotiation protocol.

Client knows that it can do A, B, or X.  So the client sends:

C->AS: A, B, X

The AS can do A, X, or Z. So the AS responds with:

AS->C: A, X

The AS doesn’t get to add “Z” to the list because the client didn’t say it could handle that. The client doesn’t get to present anything using “B” because it didn’t get a response from the AS that allows it to do so. And if there’s an overlap of zero between the two? Then these are two incompatible systems and the client can’t interact with the user — but also keep in mind that there are MANY use cases that don’t require user interaction.

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 Feb 2020 18:26:59 -0500

Another note about calling out QRCodes as separate from other URL representations: there are a ton of different scannable formats out there. QRCodes are among the most common, but they’re hardly the only ones in use. If a client wants to use JAB or Han Xin or Data Matrix or whatever to display the URL, it’s not this spec’s place to say anything about it. 

The important thing is that there’s a variable URL that needs to be communicated to the user. If there are length limitations, I think Annabelle’s idea of allowing the client to specifically ask for a short URL are a good one. Calling it “qrcode” presumes way too much of the solution stack on the client’s part and doesn’t help interoperability or flexibility.

 — Justin

> On Feb 24, 2020, at 4:18 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> If a web browser is available but the firewall blocks outbound HTTP (not unreasonable for a server host), the Client would think that it successfully opened the URI.
> If the local browser lacks the accessibility features needed by the end user, the Client would successfully open the URI, but it would not be usable by the end user.
> In the “shared family tablet” example in my previous email, the Client would not be aware that the end user is unable to interact with the companion app.
>  
> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>> Htmlized:       https://datatracker..ietf.org/doc/html/draft-hardt-xauth-protocol <https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 28 Feb 2020 14:54:12 -0800

Good point on their being different scannable formats, and likely more in
the future.
ᐧ

On Tue, Feb 25, 2020 at 3:27 PM Justin Richer <[email-masked]> wrote:

> Another note about calling out QRCodes as separate from other URL
> representations: there are a ton of different scannable formats out there.
> QRCodes are among the most common, but they’re hardly the only ones in use.
> If a client wants to use JAB or Han Xin or Data Matrix or whatever to
> display the URL, it’s not this spec’s place to say anything about it.
>
> The important thing is that there’s a variable URL that needs to be
> communicated to the user. If there are length limitations, I think
> Annabelle’s idea of allowing the client to specifically ask for a short URL
> are a good one. Calling it “qrcode” presumes way too much of the solution
> stack on the client’s part and doesn’t help interoperability or flexibility.
>
>  — Justin
>
> On Feb 24, 2020, at 4:18 PM, Richard Backman, Annabelle <
> I think your summary is accurate, but the line between your two reasons
> gets pretty blurry. The Client may not be able to detect on its own whether
> its preferred method is working, so your proposal that the Client could
> switch methods by making a new request would require the end user to
> provide some input. For example:
>
>    - If a web browser is available but the firewall blocks outbound HTTP
>    (not unreasonable for a server host), the Client would think that it
>    successfully opened the URI.
>    - If the local browser lacks the accessibility features needed by the
>    end user, the Client would successfully open the URI, but it would not be
>    usable by the end user.
>    - In the “shared family tablet” example in my previous email, the
>    Client would not be aware that the end user is unable to interact with the
>    companion app.
>
>
> So it’s easier for both Client and end user, and more generally applicable
> if the Client can request multiple interaction modes and present them at
> the same time.
>
> If we only have a single “uri” parameter, the max length in the request
> should be advisory. I.e., the GS SHALL return a URI, and it SHOULD return
> one that meets the max length restriction if it can. Client behavior is
> effectively the same as if it were treated as a hard requirement; the only
> difference is that the Client code branches based on the actual length of
> the URI returned (which it already needs to check) rather than based on the
> presence or absence of a URI, or an error response from the GS. Clients
> that can still make use of a longer URI are saved the extra round trip to
> request one.
>
> I think both “uri” and “code” should be MTI, but that does not mean they
> are mandatory to deploy. There’s lots of cases where a GS will only ever
> deal with specific types of Clients such that they’ll always use one or the
> other, but in those cases the GS is explicitly not concerned overmuch with
> interoperability.
>
> We need to be careful about defining a maximum length for the code entry
> URI. Domain names cost money to register and maintain, so a maximum length
> that is too low would effectively impose a monetary barrier to deployers
> who have long domain names. We would also have to make this a maximum
> Unicode character length with the domain name expressed in IDN form, not
> ASCII form. Users of non-Western scripts should not be penalized by the
> need to use Punycode.
>
> –
> *Date: *Friday, February 21, 2020 at 5:37 PM
> A short URI and a long URI are functionally equivalent -- so there does
> not seem to be a requirement to have both.
> a.    A console app might be able to directly open a URI in the system’s
> browser (e.g., when running in a terminal window on a desktop), or it might
> not (e.g., on a headless system). The app may not know the answer until it
> tries it.
>
> b.   That same console app might be running in a remote terminal, such
> that the end user would be able to click or copy and paste a URI printed by
> the app.
>
> c.    An SPA might be able to open a popup, or it might fail for various
> reasons. It might decide to fall back to a redirect if it detects that the
> popup failed to open. It might want the “popup” to gracefully fall back to
> a redirect-like experience in case the user agent only supports a single
> window at a time (e.g., embedded user agents in apps like Facebook and
> Twitter).
>
> d.   Environmental conditions may make it difficult to scan a QR code
> (e..g., the screen is dirty, foggy, cracked, or under direct sunlight), but
> a.    They may have a physical disability or other condition that makes
> it difficult to impossible for them to scan a QR code.
>
>                                                                i.      They
> b.   They may not have a device capable of scanning a QR code, or the
> d.   They may want to complete the flow on a device that is incapable of
> scanning the QR code (e.g., their desktop).
>
> f.     They may not have access to the companion app that the Client
> ·      URI, with some max length (e.g., because of QR code data capacity,
> https://datatracker..ietf.org/doc/html/draft-hardt-xauth-protocol
> <https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol>
> Diff:

---

From: Dick Hardt <[email-masked]>
Date: Fri, 28 Feb 2020 14:56:23 -0800

Thinking about this, the fixation attack is against the Client where the
attacker is at the Client, and the victim is at the AS.

Does the AS need to know the attacker and victim are different? IE, if the
client knows that the User at the Client is the same as the User that came
from the AS, have we prevented the attack?
ᐧ

On Tue, Feb 25, 2020 at 7:38 AM Justin Richer <[email-masked]> wrote:

> That’s good enough for the AS, but is it good enough for the client? The
> hash allows the client to make sure that the reference they’re getting back
> in the front channel is related to something they sent out in the first
> place. We originally had a “state” parameter like OAuth 2 for this purpose,
> but realized that since the client can push its callback URI we didn’t need
> that. But to get the kind of functionality that “nonce” and “c_hash” have
> in OIDC, we added this simple hash parameter that the client can check
> before it calls the TX endpoint again.
>
>  — Justin
>
> The Client presents the interact_ref to the AS with the transaction
> handle. The AS will be able to tell the Client if the interact_ref belongs
> to the transaction.
>
> Why is that enough?
> ᐧ
>
>> While I can see the value of the interact_ref (aka interaction_ref) in
>> the return URI that allows the Client to ensure the user that started the
>>> XYZ’s interaction structure allows the composition of these things,
>>> under the control of the client. This is exactly why it’s important to be
>>> able to specify how to get to the AS and how to get back as separate items,
>>> so that the client can compose the combination that makes the most sense
>>> for that client.
>>>
>>>  — Justin
>>>
>>>
>>> "Being able to provide a completion URI even if the user is starting on
>>> a device is a great insight on how to address the threat above."
>>>
>>> ᐧ
>>>
>>>> The threat you are describing is where the attacker starts a
>>>> transaction at the client, and gets the victim to complete it. Correct?
>>>>
>>>> Being able to provide a completion URI even if the user is starting on
>>>> a device is a great insight on how to address the threat above.
>>>>
>>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a
>>>>> Client has to do, so it needs to know the difference between a popup, and a
>>>>> full browser redirect. This is targetted at SPAs, where an additional URL
>>>>> to redirect to is extra work.
>>>>>
>>>>>
>>>>> Unlike OAuth 2.0, there are no parameters in the front channel
>>>>> response to the Client. The redirect back to the Client is only needed to
>>>>> return the interaction back to the Client.
>>>>>
>>>>>
>>>>>>    - “code”, which returns a code and URI for a code entry page,
>>>>>>    both of which are human-friendly.
>>>>>>
>>>>>>