Re: [Txauth] A model with a User Consent Element (with a clean figure)

Fabien Imbault <fabien.imbault@gmail.com> Thu, 09 July 2020 15:11 UTC

Return-Path: <fabien.imbault@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756F93A0C32 for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 08:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1qxQ0CxrTLm for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 08:11:45 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE473A0C24 for <txauth@ietf.org>; Thu, 9 Jul 2020 08:11:45 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id y2so2689863ioy.3 for <txauth@ietf.org>; Thu, 09 Jul 2020 08:11:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MQKZChuKSzefmRmF8fnsNBfjCy2jmC5GOGDOMO0Ad7Y=; b=Zkkul1uANjkPFDwbYa3MGirU6d+keTJjP5SnFxTXOaPmsoDcORFPlEkLE5XHlh8JVD SGZyH99ZDHIrcvX1QEgLYux4JPCIr6lhm1Z7d5jMiOzc59Di4IBnCdm8zbNkR/wv3t/f f4HgP9hAhbYDkdvhAMGZBVxOry+SG0DAr5HnKft+tdsn5/VA58LlRsbQSIkAZk6z1WQn VKs2br/IvbMeAofOiTZGcqbiRMcl6tw3J9I1GjNu10OJstKLGsJxGkqnSBv0SABZf37V R5HYEPqSY6/f5eieOoN1NZuoqTkl69Wi9tG9XN/9jqnb0UkZgSPnVkCnwFwT1v2aGzlk a+Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MQKZChuKSzefmRmF8fnsNBfjCy2jmC5GOGDOMO0Ad7Y=; b=kR01foe6DgJa7ncNchBeJIyi5DJ5Q2vjcPptk2A6uIM/rraG5v1CARqcznzSoDrbOv 50ZbCsfAvqGJB324OR/5K8j1Y6Pg24Xqm0bxPiQ3a5EjFTt+HonTss6/4i7q1T4txchd 0QmljCXW3pZsQN/tG9rqbjgsX924JhVaMkDKvH30JR02Oa6RKFmzoxu3/gVpcwR2yU0u fkAvwo3FaqamrY252ZFK3P9k1rhjdoxlEk/5VXQTjwiKSIFrqFeHsVm0yw+HGPkGKbsW s/c0BUb70TaTDfMuzC3evRHHNvqxgkzToP9mkZrFG4lJTH9nyb8wkUhgEjG1BrtmQ/pG cqmQ==
X-Gm-Message-State: AOAM5326jt9sB3T4Gs5pNX4k7PQRU135ecWCxvFjTFTr7KYrmhVCDtBj 0It6RkaENUjpYVm/QchizJPXBMhjri98enOuMTgka2aPIA0=
X-Google-Smtp-Source: ABdhPJxF6pYSHdpLog2aKDJTwc9Fw7iBPnsQc7o3Dk7PjMHWSTQfBbSexGqxyPbLq8aZIVMY2N2LrvPtJX85Fx84TeI=
X-Received: by 2002:a02:c948:: with SMTP id u8mr21178441jao.124.1594307503345; Thu, 09 Jul 2020 08:11:43 -0700 (PDT)
MIME-Version: 1.0
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 9 Jul 2020 17:11:32 +0200
Message-ID: <CAM8feuQh6ztVfLyZSx0P5DMHtsz2OYRgv-5moN_O9mRO-XGXqQ@mail.gmail.com>
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006651b205aa03a4a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/xmiZvWtH_vn1S2dE2JwwIQ0WUTw>
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 15:11:48 -0000

Hi Denis,

I think it's interesting, but also very different to XYZ/XAuth so it raises
many questions ;-)
The figure is impossible to read.

So let me try to summarize the suggested approach, with a concrete example,
to make sure we understand well:

*0. The client authN to the AS (in whatever way is supported)*
Ex : client is a corporate financing called "finapp". finapp contacts AS0
for authentication (say an openbanking service).
User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if needed,
maybe some verified credential from NeedMoney Holding that John is indeed
CFO).

*Dear John, *
*to access to your finapp, please identify yourself through your prefered
openbanking account.*
*Thanks*

*1. The client contacts a RS in a discovery phase, which includes the
selection of (at least) an operation, for which the RS returns the required
authZ attributes *
Ex : finapp needs to use NeedMoney's data to evaluate how much credit it
can offer.

Op1 : compute the credit rating, from RS1 (this is outsourced to an
external credit analyst), through the external service's own AS1.
But to do that, RS needs your historic bank statements.

Op2 : get your list of banks, RS2 (as registered within finapp),
through openbanking AS0

and retrieve the bank statements :
Op3a : get historic data from his main bank, RS2a (say an international
bank), through openbanking AS0
Op3b : same from a second bank account, RS2b (say a local bank), through
openbanking AS0

*2. User consent *
RS1 aggregates the list of attributes required (from all RS) and sends it
to finapp.

*Dear John, *
*To evaluate your credit request, we need the following information: *
*- your list of bank accounts (retrieved from your finapp account)*
*- the associated banking statements over the past 12 months (from each
bank)*
*- we'll pass that data to the credit agency, which will return your credit
score *
*Do you agree ?*

John approves (or not..., maybe he'll agree only for one specific bank),
via finapp directly (I like that, albeit in a more traditional flow, I'm
also separating the UI from the rest of the protocol of XYZ, and it works
too).

*3. Requests to the protected resources *
The client gets the access tokens and uses the services for which access
was granted.


*Analysis: (maybe I didn't get everything right, if so let me know) *
The trust model is focused around the relationship between the enduser
(John) and his application (finapp), which seems fine.

=> I see some potential issues :

a. it will be really difficult for an end user to understand what AS0 and
AS1 are, why they're different, and why he needs to authenticate to each of
them. How do you enable a federated experience? (especially as there could
be many)

b. deciding what is the main RS (here RS1) to be called by the client seems
very critical, as it is the one that needs to orchestrate everything. This
seems a very hierarchical and imperative model which seems somewhat counter
intuitive in terms of developer experience (as least as it is made today,
we clearly don't go into so much details). The call hierarchy may quickly
become very complex, which may also become a problem when separate services
evolve.

c. RS1 gets all the information required to access all sub-resources, and
therefore gets also a lot of responsibility (and power). But from finapp's
point of view, it is the one that has the relationship with the user and is
providing the core value proposition, while RS1 is just an external service.

d. multi-user (common B2B scenario): John wants to authorize a read access
to his finapp account to his external auditor, Ann (who is not a direct
user of finapp herself, but might already be registered by openbanking
AS0). How do you do that? Does it require the access token itself to be
able to delegate rights?

e. more generally, a threat model would be required, as there are many more
interactions now.

Cheers,
Fabien