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

Dick Hardt <dick.hardt@gmail.com> Thu, 09 July 2020 17:58 UTC

Return-Path: <dick.hardt@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 B688F3A0DE1 for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 10:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BX_Y5Y9nk_bm for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 10:58:42 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 BA7D73A0D9D for <txauth@ietf.org>; Thu, 9 Jul 2020 10:58:41 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t74so1689733lff.2 for <txauth@ietf.org>; Thu, 09 Jul 2020 10:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7xGdskrBcWKlnQ6tSP2oAE5eflZjIhBvvQCxTnw9kRw=; b=msBHplb3W6eSbDdz5oQXYiUkO3mQIuHM6bn96tZCwnhRYkFwpjV4CcJz3hrNdevAvA d2VsdbUZ4HQCXLnNX3Ip0gqSxkkZGIhtEXTEC2+GNpo1VvkDz9Oh0QgdVj7TPekok0oo T9nOuoZE8IYkJM3Ur8X+9p8ZBRcSQK3qBXtGEYxD0wLd7oDMdYS9OdodykKsDsosoHoD skceF8NzMnBzoikVPEFvEWqOkoSJQlvrsNpfvOheznl+BuY+vg611hMKJ7/QBNcUr+In 19aNROKonYGiQxO95TBfVWOGvgYa+uoCHYwGKCDu9bVKBdT9NkQQRgwtZachqwH64gWQ SdZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xGdskrBcWKlnQ6tSP2oAE5eflZjIhBvvQCxTnw9kRw=; b=kUtMJ1m719cmkpw8ksgjoijYNu917Q42TcNcIlM7UURgILB6CcfxlUlW76rpO4ygUV 5w2WRGPIJ34n6e9VxOVoN0n0/kmPIBV7LidTB4GafwThYxkB7EdQecm/0MKspJJoKjoX aXVJDyfoIaUpDaMrgPFmSsPenQBu/utAmfeg7ig9f7sYm6bbIJkPLDYw9SygBvg4nSki O8vqP0QDPc9BW01XmkF4uZ3wn9a6UbmA6NpkMI2DlyaFGtqp83fTYpw7Ks+OBf4ghahC btisdbbQsP8ZINPvARfvMKcZElaJ0ESjRgiQKJRPq5hd0MzXZILe2SBukcsIYwuorco+ /6Jg==
X-Gm-Message-State: AOAM533qACEmfrvystwBvBL9kS7agGNINaiaP5+dZU9syjoTVb6JV6Av 2CaiVCDdr9EWrBIz1ciRFWDTdqXL6WCtuzP+XNM=
X-Google-Smtp-Source: ABdhPJyL9+BoLc7/SMCC7BwoPGm5Yx0QmHERW1pVBA0B66cFhQwcTNaIj0xi2ELy4g/Wb8mtAhNLIysKfowtDEv5PoU=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr40546922lfm.23.1594317519393; Thu, 09 Jul 2020 10:58:39 -0700 (PDT)
MIME-Version: 1.0
References: <f7cdae74-ac8d-2069-db53-d4f8623c43de@free.fr> <ead88d07-83a6-07f7-4d78-0ee35f599d98@free.fr>
In-Reply-To: <ead88d07-83a6-07f7-4d78-0ee35f599d98@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 9 Jul 2020 10:58:00 -0700
Message-ID: <CAD9ie-tbzzUUUFKj3Vmr+Q0GkUbhy8C6nU05=TJaCWJoOzz7pg@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006718a105aa05f9a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/NJERCyg2ryZwkxBV19mHqHPH-jU>
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 17:58:49 -0000

Hi Denis, thanks for sharing the model. I don't fully understand what is
going on, questions inserted:

FWIW: having paragraphs start with the step number (1), (2) etc. would make
it easier to map between the description and the diagram.

On Thu, Jul 9, 2020 at 3:26 AM Denis <denis.ietf@free.fr> wrote:

> This is a new thread.
>
> Preamble: This model is quite different from the XAuth model.
> In particular, a RO has no relationship with any AS and a Client does not
> need to be associated with any AS prior to any access to a RS.
>
> A key point of this model is that the user's consent is handled locally by
> the Client and hence no AS nor RS is handling a man machine interface
> for the user consent. This allows to support locally the user consent for
> multiple ASs while keeping all ASs ignorant about the choices of the user
> made for accessing a particular RS.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *       +--------+                           +------------+        |
> User  |                           |  Resource  |        |
> |                           | Owner (RO) |        +--------+
>                   +------------+            |
> \                              |            |
> \                             |            |
> \                            |            |
> \                           |     +-----------+     +---------------+
> +------------+     |           |---->| Authorization |     |            |
>     |           | (2) |  Server (AS)  |     |            |     |
> |<----|               |     |            |     |  Client   |
> +---------------+     |            |     |
> |-------------------------->|  Resource  |     |   User    |
> (1)             |   Server   |     |  Consent
> |<--------------------------|    (RS)    |     |  element
> |                           |            |     |
> |-------------------------->|            |------>     |
> |           (3)             |            |  (4)     |
> |<--------------------------|            |<------
> +-----------+                           +------------+ *
> The flow of operations is as follows:
>
> The Client (which may have been previously authenticated using FIDO)
>
Which party has the client authenticated to? The client authenticating with
FIDO is confusing to me. FIDO is usually how a user authenticates.


> contacts the RS and after some dialogue with the RS selects an operation
>
How does the client know which RS to contact?


> that it wants to perform on the RS (1a). Note that it may also indicate
> directly the operation that it wants to perform on the RS without any prior
> dialogue.
> In return (1b), the RS informs the Client about which attributes are
> needed by the RS for performing the requested operation and from which
> Attributes Servers
> they may be obtained.
>

(1a) and (1b) are not labeled. There is only (1)

>
> This information is specifically marked to indicate that it shall be
> handled by the "User Consent element" from the Client.
>
Why? What is the significance of this? Which information is marked?


> The presentation of that information is up to the man machine interface
> supported by the "User Consent element" from the Client.
>

Which information?

>
> The user can see which attributes are requested by the RS for performing
> the requested operation and, if it consents, the Client contacts one or
> more
> appropriate Authorization Servers (2a).
>
How does the client know which AS(s) to contact?


> The user consent is hence captured locally by the Client (i.e. there is no
> dialogue with any AS nor any RS).
>

No dialogue with who? The client is calling the AS is it not?

>
> When the Client got the access tokens from these authorization servers
> (2b), it sends all of them in a single request to the RS (3a).
>

So the RS must trust the AS that issued the tokens. And the AS must trust
the Client to have gathered consent. And the AS must have a relationship
with the user. It is unclear what role the RO is playing in this though.
The RO and RS look to be the same entity from all the other parties.

>From my current understanding, at a high level, this looks like it is
supported by GNAP with the addition of the discovery step (1). There have
been a number of proposals for doing this discovery, and perhaps now there
are enough use cases to look at standardizing something.  No interaction is
needed between the AS and the  User as the Client is providing enough
"information" in the user object of the Grant Request to satisfy the AS
releasing the access tokens.

Perhaps as I understand the model in more detail I will understand what is
missing from GNAP (besides the discovery step).

/Dick

(I've skipped reviewing the delegation use case below until I understand
the simple use case)


> End of the story for a simple access
>
>
> Start of a subsequent story for a delegation case
>
> Let us now suppose that the RS is unable to fulfil the request by its own
> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
> indicates the operation
> that it wants to perform on RS2 (that operation may not be the same as the
> original operation). In return (4b), RS2 informs RS1 about which attributes
> are needed
> by RS2 for performing the requested operation and from which Attributes
> Servers they may be obtained. RS1 forwards that information to the Client.
>
> This information is marked to indicate that it shall be handled by the
> "User Consent element" from the Client. The presentation of that
> information is up to the man machine
> interface from the Client. The user can see which attributes are requested
> by RS2 for performing the new requested operation and, if it consents, the
> Client contacts one or more
> appropriate Authorization Servers. The user consent is hence captured
> locally by the "User Consent element" from the Client. (i.e. there is no
> dialogue with any AS, nor RS1, nor RS2).
>
> When the Client got the access token(s) from the authorization server(s),
> it sends all of them in a single request to RS1. RS1 then forwards the
> additional access token(s) to RS2.
>
>
> Some observations:
>
> The user nor the Client are linked with any particular AS. A user may use
> today an AS of the Bank of America and may change tomorrow to the Bank of
> Missouri.
> As soon as he will be registered with the Bank of Missouri, he will be
> able to get access tokens from the AS of the Bank of Missouri. The AS of
> Bank of America
> has not been able to know where its access tokens have been used. This
> will be the same for AS of the Bank of Missouri. There is no need for any
> direct dialogue
> between any AS and any RS at the time a client is making an access. There
> is no need for any RO to contact any AS.
>
> This model has been constructed following a "Privacy by Design" approach.
> Denis
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
ᐧ