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

[Francis Pouatcha <[e-mail]>]

Dick, my response inline

On Sun, Jul 12, 2020 at 3:01 PM Dick Hardt <[e-mail]> wrote:

> Francis, thanks for the review ... questions and comments inserted ...
>
> On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha <fpo=
> [e-mail]> wrote:
>
>> Some points raised here might match what I wrote before after reviewing
>> the last draft of XYZ.
>>
>
> I'm assuming you are referring to this post:
>
> https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/
>
> Correct?
>
Yes.

>
>
>> 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.
>>
>
> Are terms missing, are the definitions too short, or both?
> If you provide specific examples I can work on addressing them!
>
Definitions are too short. I will provide a proper mail with my proposal of
what we might need to clarify and als limit each term.

>
>
>>
>> 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.
>>
>
> That's an interesting point. GNAP also has identity claims, so the
> abstract flow is somewhat different (there is no Authorization Grant from
> the RO), and not all steps always happen. (there may not be steps (E) and
> (F) with a Resource Server)
>
> Would you elaborate on what you think would be useful here, that is not in
> the specific flows?
>
A diagram that generalizes the steps, independently of interaction mode is
essential for the reader's navigation of the rest of the document. This is
what #section-1.2 of RFC6749 does. I hope we can produce a similar diagram.

A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 could
be defined for this.

>
>
>>
>> 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.
>>
>
> Would a reference to #section-2.3
> <https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-2.3>
> in the RO definition, and more explanation in #section-2-3 on the rationale
> address your concern?
>
A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 with
the RO vs. User clarification and some example interactions where they
diverge.

>
>
>
>>
>> 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.
>>
>
> I agree.
>
> If we do mention that, we should specify how the certificate would be
> presented and work. We can do that in the core GNAP document, in an GNAP
> extension, or reference another specification. I'm not that familiar with
> QSeal. Is it specified somewhere?
>
This is the ETSI standard used by the European PSD2:
https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.04.01_60/ts_119495v010401p.pdf
.
There is a well managed infrastructure in the European Economic Area that
allows for "Certificate Based Dynamic Client".

>
>
>>
>> c) Grant Server (GS)
>> If the GS is a SIOP running on the user device, how does it influence the
>> protocol design?
>>
>
> With mobile apps having URIs bound to specific apps, I think the protocol
> would work the same, but I've not worked with SIOPs. Do you have any
> concerns?
>
Yes. As the protocol flow designs inbound connectivity from Client to GS.
How does a client initiate a connection to the user device? Or we might
have alternative interactions without inbound connectivity to the GS?

>
>
>>
>>
>> 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.
>>
>
> Did you mean to say '... the picture must also display the "RO"'?
>
Yes. For transparency, even if they are both in the same box.

>
> There could be a separate RO in a more complex flow, but we could define
> this flow to represent where the User and RO are the same party.
>
Yes.

>
>
>> - "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".
>>
>
> I like the word "decoupled" -- would "redirect" then be named "coupled"?
> Or renamed "indirect" to "decoupled"?
>
Not sure.
- Let us use redirect, decoupled and embedded to refer to "families/types
of interaction". In which case "Indirect" will be an interaction mode of
the "decoupled family".
- I wouldn't call "redirect" and interaction mode, as there are many
variants of redirect. Let us keep the keyword for the family and specify
known variants of redirect interaction for more precision.


> While "user_code" and "indirect" are both decoupled, the "indirect" has
> different security properties as it uses a link, which an attacker can
> trick a user into clicking on wherever a link may be used.
>
> I do agree that "user_code" and "indirect" are both a decoupled
> interaction, and calling that out would be useful.
>
Yes.

>
>
>
>>
>> - "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.
>>
>
> I have been thinking that the functionality you describe above would be in
> the "user" object rather than in the "interaction" object as it is not an
> interaction between the GS and the User. IE, the Client presents some
> artifact to the GS that establishes the User in the GS context so that a GS
> / User interaction is not needed.
>
> That looks similar to me to what Denis was proposing in
>
> https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/
>
No. It is different.

>
>
> Does that work, or am I missing something?
>
Embedded in the sense above is about embedding the interaction RO <-> GS
into the communication path User <-> Client <-> GS.
The main purpose is to keep the Link User <-> Client uninterrupted (by any
type of redirect or decoupled interaction).

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