Subject: [Txauth] XYZ vs XAuth: Interaction

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Mar 2020 16:05:23 -0700

*Interaction*
XYZ
- Client expresses all possible interaction capabilities such as redirect,
user_code, didcomm as separate fields
- AS responds to any interaction capabilities it supports and requires per
policy

XYZ Rationale: Client knows what user experiences it can support (which
might be several options), AS knows what experiences it supports and what
kind of interaction (if any) will be needed for a given request. Inline
negotiation gets rid of the need for discovery and error recovery steps.
Separating how the client gets the user involved and how the client gets
updated for the next step allows for innovative and powerful combinations
not easily possible with a type-based system

XAuth
- Client states if it can do a redirect interaction (GS can redirect back
to client), or must do an indirect interaction (GS won't be able to
redirect back to client)
- GS responds with parameters to use, or an error if not supported

XAuth Rationale: User interaction can be transferred back to the Client, or
it can't. A redirect enables protection from session fixation.[1] Separate
URIs for redirect and indirect allow GS to know the security
characteristics of request. The Client can present what it can for
indirect, and let the User choose which method they prefer.

[1] Session fixation. An attacker interacts with a Client and gets a
redirect link, and then tricks the victim into clicking the redirect link
in the context of the Client. The victim authenticates at the AS and
authorizes the access for the Client. The attacker then has access to the
victim's resources at the Client. Prevented by ensuring it is the same User
at the Client and the AS.
ᐧ