Re: [Txauth] Support of FIDO and data minimization by RSs

Dick Hardt <dick.hardt@gmail.com> Mon, 06 July 2020 16:22 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 935213A1629 for <txauth@ietfa.amsl.com>; Mon, 6 Jul 2020 09:22:08 -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 fo-FjzuV2aQn for <txauth@ietfa.amsl.com>; Mon, 6 Jul 2020 09:22:06 -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 4C5E13A15D9 for <txauth@ietf.org>; Mon, 6 Jul 2020 09:22:06 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t9so22915468lfl.5 for <txauth@ietf.org>; Mon, 06 Jul 2020 09:22:06 -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=9n243jFpxoo8QiSLLdfV+3S+8EasPrlVANBfx4YWmsA=; b=sQjq9au3t3QN4wKYLFe8Yz2X9VB3zWUlOJz41003C+TcELqQOBpqlUw5tSZ4FfLfhZ 4iu/EuchgwJILxpzkCWioh4Iq+5bwE31Tx+/phhdslILLJEoUrOskUOeNvO0Z44Ih9jH WgJthYLi+TQ4tdUxD6x8yRMcY2MB4W7b6hNoLOE8t8QiTSoLDa513trV1aldoSNGcAgX 4mUzfu089j0zy6IM7yoppS6U1YdLdmxvQ4osE6BQTIbRVYFnIe3B6S7vaXofxXJ1LYV2 7tOU6Q8vFvQ+KcuJmJ3J6JXaRZBoPz4ViAo75GQLv/veeov9EW0lyzmTDN21UJzlZNYJ E58Q==
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=9n243jFpxoo8QiSLLdfV+3S+8EasPrlVANBfx4YWmsA=; b=dprZNOfRLp9XrPUm42w+5NR8h97d8OUgZur3nzopyjHW0qt+BLotSpaXmlIZuRGbC5 6wlrdpW66EiUZy2oup4mhcfi0HeXePfHUwZ3sEZUlyaNyIbmaoI1iBmlJBiQgaOBVFi4 yR8LZ3wVdai5SyIYDeF37uhOwsCHZJ4On785+m0LBvGpYFOtTWVrHRmvplzFzoiqcHdt fJZXD7gk7z44uNdMIdBgcCYPcCFw/ZCHLRRw+9VQopqC3W6fTOk5L0nVCPLxo/wncvdG zP5SCnNJbBn9k6ZzvqgnSpL6TobRhvSn38WVW35nCs7pMQMdNOdp/sLz3Q7iZEpAg/Go wzLA==
X-Gm-Message-State: AOAM532pLQAZ7HQrMqEhbHxyt+yPrlOHWccAUu6O/qO9W/9BqRA/2Bn1 hI77HrLc1H7O3790v8+ZiJDaT/X9fPCMvQ/6DjZWC/k+
X-Google-Smtp-Source: ABdhPJwiYC8C01t5dTpoBNsDKjMCa5HNM/sFm3r/5XAlrbMhsmIiKGFgOo48YCrXmkCDzqW2+O4xAWLKWwG8CYUrZgY=
X-Received: by 2002:ac2:5093:: with SMTP id f19mr31022330lfm.10.1594052524198; Mon, 06 Jul 2020 09:22:04 -0700 (PDT)
MIME-Version: 1.0
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>
In-Reply-To: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 6 Jul 2020 09:21:28 -0700
Message-ID: <CAD9ie-uHo1hNs6Y767NHyNj1TxmfzcbDk-6iZxBT0QWtqpe+Fg@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000754e7405a9c846e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/GtLfhGD0EhDA_-dpRfHuSQT_U_Q>
Subject: Re: [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 16:22:09 -0000

Hi Denis

Would you provide some background on what you are trying to solve with
this? I'm guessing it is privacy related.

Perhaps a use case would help make it more concrete?

/Dick


On Mon, Jul 6, 2020 at 5:39 AM Denis <denis.ietf@free.fr> wrote:

> This is a new thread: a proposal for a RS authorization algorithm and 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 AND and
> OR conditions.
>
> 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 U2F or 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 OR Operation 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 mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>