Re: [Txauth] A model with a User Consent Element

Tom Jones <thomasclinganjones@gmail.com> Thu, 09 July 2020 15:50 UTC

Return-Path: <thomasclinganjones@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 88F433A0CCE for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 08:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 CLtDpijGJ6W1 for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 08:50:18 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 0892D3A0CC7 for <txauth@ietf.org>; Thu, 9 Jul 2020 08:50:18 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id r8so2254771oij.5 for <txauth@ietf.org>; Thu, 09 Jul 2020 08:50:17 -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=3Nr5VonlMfgxy+n+jb5fBD7p8XVYgqgGOc2fva9WnmY=; b=OTCpLGzic8ovkfflnSOD+QXxmMtKibI8pn6LUIMBKO78BmJZjs0Cl7XT50QZsJyM2C pbVOV2Ub++WKlEWMlR7QIgstKizW7ZLqcSETL7X5IO/SuVjgsnSVKxbOjBQ+3gKLDZmk c+VEkq744eka/mzhiUIKq0Hv19Ne5KXHrqAmMDWRaRP2aqg1mCTfss1x5u/yssnNhgee o5etXgG0hU2Mh1z14R1/e6Szwo3vTduIH27MTQi5pbMLAjl+cSb/p+nuruU+jqAmgsuv eq1IaMxDzLyGCbrKtMj/ogTuC7yjdtx6XX6+h198zbT8EdzJOJnbYi960ybb9in/YIOY lKZA==
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=3Nr5VonlMfgxy+n+jb5fBD7p8XVYgqgGOc2fva9WnmY=; b=YuHnagl1z8Z7JN7Pq2rNwETrhzz7DZrXytf6NEU5Rn2kfHI4butCwhxEihTBHtWs6y +EGGHku5lK072ptPETAqHjqGff4fmRKwpnjF0/0Uz5jam3OZuvHZzDCKUl+bn7moBBVi Dv232Anb44HmGMjKqjAq1LTqmJTmZzJZYKTYt+ySG0y2NH/4VSeIUA0+OniGAkBJ5dbO UZU0jk1pmR5weda53pC123Q472eNNfezkipwRFDWq1JmK3+dPUHXxwrs6dKLXxWeTHXs J8EMcl84LWcy67bUylWjY2vkJ960m5AWP5pP9vyCd0aTQ6YNw9kXOkIP65R3Vx19oYBl lnlA==
X-Gm-Message-State: AOAM533BeW+bbk9Nruf84D7kZfNuIIRUciqyponUHUod6sehpSN7k+ZP FJhwhPNbvVZiZee1i2aCUZRM0O6pVory9svlRVQ=
X-Google-Smtp-Source: ABdhPJzJ7v9juZ/Jv2JkEQinlcf50xXmB2U9E7cWwmiYQok1l1XhaNOAYawXC8o0RGifJY4ygK3lzhkffxJEmIS1fLI=
X-Received: by 2002:aca:4905:: with SMTP id w5mr624038oia.172.1594309817128; Thu, 09 Jul 2020 08:50:17 -0700 (PDT)
MIME-Version: 1.0
References: <f7cdae74-ac8d-2069-db53-d4f8623c43de@free.fr> <a07e7a70-2258-e3c8-0af8-65756a7ddeba@readycomputing.com>
In-Reply-To: <a07e7a70-2258-e3c8-0af8-65756a7ddeba@readycomputing.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Thu, 9 Jul 2020 08:50:02 -0700
Message-ID: <CAK2Cwb5wrpHhSe-Xz9jgdyPCoSNp_Uz9DRQYe=1PV9=2pqEVeg@mail.gmail.com>
To: David Pyke <david.pyke=40readycomputing.com@dmarc.ietf.org>
Cc: Denis <denis.ietf@free.fr>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004fd8f605aa042e9f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/XAAKt_HshJUez1-xX2S61jPIrBU>
Subject: Re: [Txauth] A model with a User Consent Element
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:50:21 -0000

David: Kantara has been working on standardizing the health care model you
describe. Where clients are known, this model works. I would suggest that
the model requires federation of some sort to assess the parties to a
transaction, and so is fundamentally different from the more typical oauth
model where the client must be considered to be an adversary.

I doubt that a common protocol can be enabled for both models. But I am
open to hearing that both models can share message formats. That would be a
good start.

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 8:25 AM David Pyke <david.pyke=
40readycomputing.com@dmarc.ietf.org> wrote:

> This is frequently done in healthcare, with the User Consent Element
> holding a URI to a fetchable document or OID that outlines consent
> requirements or provisions.  If the URI points to a (I)ACP, it can be
> computable (XACML or other) consent that can be ingested automagically.
> On 2020-07-09 6:19 a.m., Denis 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)
> contacts the RS and after some dialogue with the RS selects an operation
> 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.
>
> This information is specifically 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
> supported by the "User Consent element" from the Client.
>
> 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). The user consent is hence captured
> locally by the Client (i.e. there is no dialogue with any AS nor any RS).
>
> 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).
>
> 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
>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> [image: Logo] <http://www.readycomputing.com/>
>
> [image: LinkedIn icon] <https://www.linkedin.com/company/ready-computing> [image:
> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com <david.pyke@readycomputing.com>*
>
> * www.readycomputing.com <http://www.readycomputing.com/>*
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachments
> is intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. Any
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warrant
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message. --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>