Re: [Txauth] RS/AS communication for multiparty cases

Denis <denis.ietf@free.fr> Fri, 03 July 2020 10:01 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 BAEB03A0BB3 for <txauth@ietfa.amsl.com>; Fri, 3 Jul 2020 03:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level:
X-Spam-Status: No, score=-1.62 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, URIBL_BLOCKED=0.001] 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 t346I6clYU4I for <txauth@ietfa.amsl.com>; Fri, 3 Jul 2020 03:01:17 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB80D3A0BB2 for <txauth@ietf.org>; Fri, 3 Jul 2020 03:01:16 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d12 with ME id ya1E220014FMSmm03a1ESW; Fri, 03 Jul 2020 12:01:15 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 03 Jul 2020 12:01:15 +0200
X-ME-IP: 86.238.65.197
To: Fabien Imbault <fabien.imbault@gmail.com>, txauth@ietf.org
References: <CAM8feuT20tPAAkCUE2rKyQ1MTc--14bNNRu1cPTs2xvbJAfMcA@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <ecb0bdf2-5ec6-db9b-39f7-054a6b7f7603@free.fr>
Date: Fri, 03 Jul 2020 12:01:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CAM8feuT20tPAAkCUE2rKyQ1MTc--14bNNRu1cPTs2xvbJAfMcA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------13E1A0B07ECCFD039866F606"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/mJVFKBrJ4GqtsGjk5BMmiQsURBk>
Subject: Re: [Txauth] RS/AS communication for multiparty cases
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: Fri, 03 Jul 2020 10:01:19 -0000

Hello Fabien,

In 2017, I made a presentation at the OAuth workshop in Zurich.

The paper is available from: 
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

The slides are available from: 
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
_Note_: The slides should be viewed "full screen" to get the animations.

The general approach is how to construct from scratch a "privacy by 
design" architecture taking also into consideration "security by design".

Coming back to your requirement, I would not cover it if it infringes 
the sentence "the RS and the AS never communicate directly".

You should start your design by defining the trust relationships, then 
apply the privacy requirements while not forgetting the security 
requirements.

Denis

> Hello Denis,
>
> I have been following your comments. I still fail to see the global 
> privacy preserving architecture you're proposing. It would help to get 
> a more thorough proposal if you can.
>
> But more specifically, I have a comment on :
>
> "I would have preferred that you meant: the RS and the AS never
> communicate directly, which is indeed a nice property to follow
> to ensure the user's privacy."
> I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
> I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
> Fabien
>