[Txauth] Support of FIDO and data minimization by RSs
Denis <denis.ietf@free.fr> Mon, 06 July 2020 12:39 UTC
Return-Path: <denis.ietf@free.fr>
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 097643A1442 for <txauth@ietfa.amsl.com>; Mon, 6 Jul 2020 05:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.378
X-Spam-Level:
X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no autolearn_force=no
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 nRNyBRuCen7o for <txauth@ietfa.amsl.com>; Mon, 6 Jul 2020 05:39:41 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963EC3A1441 for <txauth@ietf.org>; Mon, 6 Jul 2020 05:39:40 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d61 with ME id zofa2200K4FMSmm03ofbhL; Mon, 06 Jul 2020 14:39:36 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 14:39:36 +0200
X-ME-IP: 86.238.65.197
To: "txauth@ietf.org" <txauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>
Date: Mon, 06 Jul 2020 14:39:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------2BA9BA9FCD5AF2F8AA686FAE"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE>
Subject: [Txauth] Support of FIDO and data minimization by RSs
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: Mon, 06 Jul 2020 12:39:43 -0000
**This is a new thread: a proposal for a RS authorization algorithmand a way to support FIDO by RSs In order to support the privacy principle of "data minimization" by RSs, only the attributes that are strictly necessary to perform an operation requested by a client should be requested by the RS. When a client wants to authenticate, it will usually be informed by the RS on how to do it (see more details about two exceptions at the end of this email). Which conditions are needed to perform other operations will only be disclosed to authenticated users at the time they are willing to perform an operation. Two categories of operations will be considered: authentication operations and other operations. For the "authentication" operation, two cases will be supported: -FIDO U2F or -one or more attributes from one or more ASs. In the second case, an access will be granted by a RS based on an mathematical expression which is formed using some combination of ANDand ORconditions. Examples of combinations: /Condition 1/AND/Condition 2 Condition 1/OR /Condition 2/ (/Condition 1/AND/Condition 2)/OR/Condition 3 (Condition 1/OR /Condition 2)/AND/Condition 3/ The following notation is being used for /a Condition /: /Condition x/= { AS identifier + set of attributes types + optional scope identifier } The presence of the /optional/ scope identifier allows to provide a backward compatibility with ASs from the OAuth 2.0. world: the optional scope identifier is only present when a bilateral relationship has been established between a RS and an AS prior to any access (/and will continue to be maintained/) using "out-of-bands" means. Each RS internally constructs an /authorization table/ with the following content: 1°For the "authentication" operation : either FIDO U2For a mathematical expression using conditions; 2°For any other operation : a mathematical expression using conditions. An example is used to explain the concepts. "Operation(s)/ Mathematical expression" pairs managed by the RO of a RS. *Operation* *Mathematical expression* Authentication /Condition 1/OR/Condition 2/ Operation A OROperation Z /Condition 3/AND/Condition 4/ Conditions table: Condition 1 FIDO U2F 1.2 - - Condition 2 AS 1 set 1 of attributes types Condition 3 AS 4 set 2 of attributes types scope identifier : 21 Condition 4 AS 9 set 3 of attributes types - Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions used in that mathematical expression. The user may then decide whether the set of attributes types which are indicated for a given AS are appropriate to him or not and then select that AS if it has a relationship with it. In this example, one mathematical expression for the combination of conditions using AND and OR operators is "/Condition 3/OR/Condition 4",// which means that///some types of attributes from AS 4 AND some other types of attributes from AS 9 are both needed by RSx to perform on RSx either the Operation A or the Operation Z. In this example, RS 1 and AS 4 have established a bilateral relationship (and have agreed to define and use scope identifiers) whereas RS 1 and AS 9 have not established any bilateral relationship prior to the exchange. The user makes up his mind whether the attributes requested by AS 1 and AS 9 are reasonable and if so, requests two access tokens: one to AS 4 and another one to AS 9. For AS 4, the client shall use the scope identifier with the value 21. For AS 9, the client shall use the set 3 of attributes types indicated in the Condition 4. In order to save one exchange, a RS could publicly publish how its clients can authenticate. However, it is also possible to consider no guidance at all: in such a case, using "out-of-bands" means, the clients should know how to authenticate. Denis
- [Txauth] Support of FIDO and data minimization by… Denis
- Re: [Txauth] Support of FIDO and data minimizatio… Dick Hardt
- Re: [Txauth] Support of FIDO and data minimizatio… Denis
- Re: [Txauth] Support of FIDO and data minimizatio… Justin Richer
- Re: [Txauth] Support of FIDO and data minimizatio… Dick Hardt
- Re: [Txauth] Support of FIDO and data minimizatio… Denis
- Re: [Txauth] Support of FIDO and data minimizatio… Dick Hardt
- Re: [Txauth] Support of FIDO and data minimizatio… Denis
- Re: [Txauth] Support of FIDO and data minimizatio… David Waite
- Re: [Txauth] Support of FIDO and data minimizatio… Denis