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

[Dick Hardt <[e-mail]>]

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?


> 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!


>
> 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?


>
> 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?



>
> 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?


>
> 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?


>
>
> 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"'?

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.


> - "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"?

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.



>
> - "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/

Does that work, or am I missing something?




>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
ᐧ