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

David Pyke <david.pyke@readycomputing.com> Thu, 09 July 2020 15:24 UTC

Return-Path: <david.pyke@readycomputing.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 5F2A83A0C73 for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 08:24:54 -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, 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=readycomputing.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 96PLBLjHhE_u for <txauth@ietfa.amsl.com>; Thu, 9 Jul 2020 08:24:52 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 D65253A0C71 for <txauth@ietf.org>; Thu, 9 Jul 2020 08:24:51 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id u12so1911509qth.12 for <txauth@ietf.org>; Thu, 09 Jul 2020 08:24:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readycomputing.com; s=google; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ByoWTf8aGkP0icOteOxudG1te6J9BHxucBqHtwJU3Ko=; b=R14Iwmpo9FjUhMNhLnJYUfPoBs6PcZjOUWiIdNaeYXW54M1S/oAouStpI3kebAb9rR ZiiYw3mdTLoJDqaDfoIMvHf+ubObvqb7c2WD/cOrRAWWbpFmAnviA3IA+bo6Fe6bQAPz 1TjLMIA71J5Su0u8xFM96EUwC+WtyIwxVcMRiDoNq+HdmEnxheMJZpJFwla+lG/2HC/D 2UJc/Pv17WsZ9RmuUvVYV5PlbSMihXNobsUlWmGn4sIzWCsbDeYeXuYPIcujO2jWNHYX 2zSAEmFVu8kCLklECDuCoAIA3I2qEEQGgMCB5ef+8Tur0d0KVuShiaoViMU/MnL0k9qi kyzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ByoWTf8aGkP0icOteOxudG1te6J9BHxucBqHtwJU3Ko=; b=XZTxIy8KoVR5Pb4OujzOFtgeVzKT5991RRaKDv79lt/wPYxILgEq2gj52r16E0T2Cz 1g77WgK24g3fZRqN/w1ea5TSqupnFaVxhnMrRhCcSlqtm3Xhs2tmDaoKGmgBXMgzZ73E GsSS1DcmE75W3GQoxZ3ut7dinT6AGCnxG6EGCPCcnoqBp5ealth6JD8hVeV6Mb84Jdw7 BqeSiLRQg86RUhzNSkas82Yz2sjgnK+v5QDhouQplEcHaTWuyCY8/As6MMO4m3IQqbha Ucwerp7M6QT6vekkg1ZTHukOF8ejEjA2/gxJ+LQ2B7ANxrc9QclznDw6pafZLemnFgqn IYpQ==
X-Gm-Message-State: AOAM533/9iSHWAJJSenjCfCu2jCDE0GBUNDIDwXOG+aeS0eR2TQ6ohrq wowTeVbJUNanP4paumT1uU5vnYam1mg/yyEQGJPwlj3c+4UqYsXfQn6gcg0Ty7fnWm6rKIBY/MS 7wJIAgJfxVD5Z5TeFMiFP0MOLOEN838l9hICm4ntSegcML7WQjJaDsqyc5P5OwLXnpOr+TrBX6g ==
X-Google-Smtp-Source: ABdhPJxT/ZfVlbOLpRQjQ8pR2Owic7oIS2BOiZ5nKUnODLksR5FhUOEi4NCjgx3gXHPmkge5fD0shQ==
X-Received: by 2002:ac8:3637:: with SMTP id m52mr67653156qtb.53.1594308290358; Thu, 09 Jul 2020 08:24:50 -0700 (PDT)
Received: from ?IPv6:2607:fea8:aa20:59d:a52f:dc99:fcd2:aefd? ([2607:fea8:aa20:59d:a52f:dc99:fcd2:aefd]) by smtp.googlemail.com with ESMTPSA id y16sm4139736qkb.116.2020.07.09.08.24.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 08:24:49 -0700 (PDT)
From: David Pyke <david.pyke@readycomputing.com>
X-Google-Original-From: David Pyke <David.Pyke@readycomputing.com>
To: Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>
References: <f7cdae74-ac8d-2069-db53-d4f8623c43de@free.fr>
Message-ID: <a07e7a70-2258-e3c8-0af8-65756a7ddeba@readycomputing.com>
Date: Thu, 9 Jul 2020 11:24:48 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <f7cdae74-ac8d-2069-db53-d4f8623c43de@free.fr>
Content-Type: multipart/alternative; boundary="------------0B13F9D2A0FB4D655FC044C4"
Content-Language: en-CA
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/KlJpkpoZJ37_ddKzgzn1utn01tY>
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:24:54 -0000

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

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Logo <http://www.readycomputing.com/>

LinkedIn icon <https://www.linkedin.com/company/ready-computing> Twitter 
icon <https://twitter.com/ready_computing?lang=en> Youtbue icon 
<https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>

	

Office: +1 212 877 3307 x5001

_david.pyke@readycomputing.com <mailto: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.