[Txauth] Reviewing draft-hardt-xauth-protocol-11

[Francis Pouatcha <[e-mail]>]

Some points raised here might match what I wrote before after reviewing the
last draft of XYZ.

1. Dictionary
I do like sections 1.x dealing with terms but this is kept too short. I
have noticed that most of the discussion conducted on the list results from
different understanding of terms used.

2. Abstract Protocol Flow

I am missing an abstract protocol flow like the one defined in
https://tools.ietf.org/html/rfc6749#section-1.2.

3. Parties
a) graphical illustration (#section-1.1)
I do like the graphical illustration in #section-1.1. The main difference
to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
clear separation between the "User" and the "Resource Owner" (RO). To help
transition the understanding of current oAuth2 implementers, it is
essential to illustrate and highlight the rationale behind this design.

b) Dynamic Client (#section-1.1)
I would like to mention that the dynamic client can present a certificate
issued by some authorities known to the GS. This is the case of QSeal
certificates designed by European eiDas.

c) Grant Server (GS)
If the GS is a SIOP running on the user device, how does it influence the
protocol design?

4. Interaction Modes (Protocol Flows)
And mentioned in my review of the XYZ protocol, I am missing a grouping of
interaction models. We need an abstraction layer in which we define groups
of flows based on key interaction between parties. I am expecting at least:

- "redirect" Interaction
here the GS instructs the Client to redirect the RO/User to the given
interaction
URL. This is well covered in #section-2.1. But for transparency this
picture must also display the "User". Shall the redirect interaction
presume that the "User" and the "Ro" are represented by the same party,
then it is worth mentioning this. In this case we can draw a single box to
represent both.

- "decoupled" Interaction
This interaction model is currently represented by the "user_code"
Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 and
#section-5.2). Both of these are forms of "decoupled" Interactions. Main
characteristic of a decoupled interaction shall be that the device used by
the RO to interact with the GS shall be separated from the. device used by
the "User" to interact with the "Client".

- "embedded" Interaction
With the evolving of smart end user devices that can keep private keys,
perform cryptographic operations, it is essential to include the "embedded"
Interaction in which RO/User device send authorization grant to "Client"
that in turns takes it to the GS in exchange of the authorization token. In
XYZ I found this hidden behind the didcom interaction.
The "embedded" interaction shall open room for different types of
synchronous transaction authorization requests in which the "RO/User" gives
a verifiable assertion (inkl. proof of possession) to the "Client" for use
at the GS in exchange for the seeked access token.

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/