Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)
Francis Pouatcha <fpo@adorsys.de> Tue, 11 August 2020 22:40 UTC
Return-Path: <fpo@adorsys.de>
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 027DF3A0D66 for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:40:21 -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 (1024-bit key) header.d=adorsys.de
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 ky6UHzEgu8Kh for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:40:17 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 CA1EF3A0B34 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:40:16 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id 88so271278wrh.3 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2sdU3XB5tPxMH/5JexTOzzcgrgz5zLizkLe+RWxSMhA=; b=ckxVXgG1+DVX6Ng+ViYlnlBceov/Aj5AVaW9XWX58oqlXN6RdqdCfXeOBNyqM4+Wui 6/4iHAqcTm+McNHfgSi25YwbtbphEAzsDQd2wlKMNCB2GWKOEYq7+jvfIgFIli4BkOTJ qQJJq/EF77i3LpqqIj5p8k+853A7ML7EDD4AY=
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=2sdU3XB5tPxMH/5JexTOzzcgrgz5zLizkLe+RWxSMhA=; b=RdkAgmCjUvs1+XxfDJJfyQmCLRZnKDNnNV6bZ4HP9G7EeGSzbMP2YEk59N4tnwJl8c R64h5CmqF+WHe//rJTR+x6iTXKS1l9qPe4Akof3oN3FAWjellzKrecKn2CvDv7yjh1Rb l9Ym4A/AEEN6NzaVHcO+PGtmzyRSzewPUsQxvTtpwoZ+8476x+hi0wYvHC/1kE60mTZJ Dk8h8jV94ygW/gLx0ROW9g8A3humNLaYAECNVdtxMtegRrsD8+OAIFpvOdd59ThWcRgO qAH1qSvu3HhepB37dQ2deT3mxQzmIwpBr3x/uGf4G+L6aD32+zP9FWHew1Tt97lA3Tms gPLw==
X-Gm-Message-State: AOAM533dX9ZHJ3TKsGkjin8O6oIKupRGlh5+/4AILT3wgwZ3twV7ntNa Anke0rEWNA6jXIwu3pLY8lcOy35z3N0tZlvYCqmXOg==
X-Google-Smtp-Source: ABdhPJzsJdsjVTXGll5kI14nSsWXXxl+LLGNVq/WpGPBmpb3tMOGZhhycKkEJqIB1o3AIqo0jbyDmeTXug1/Qepj7SI=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr30359282wrs.283.1597185615129; Tue, 11 Aug 2020 15:40:15 -0700 (PDT)
MIME-Version: 1.0
References: <d2ee5da2-8e88-15c8-8646-087860463d2c@free.fr> <CAOW4vyOwQTMoo2Nmb8KNcVM5hdOW69FzZTK5XQ2fRL9CC8+SUA@mail.gmail.com> <CAM8feuT2K2xpF=VES11kihsqfGK4RCzdSCU=HCLijxLvnc=8LA@mail.gmail.com> <CAOW4vyM0jkw9qTzohzGaNwvvT6JGqcUbdqXnJFq9ahqnRPnuGQ@mail.gmail.com> <CAK2Cwb65cdpoX=B5e4cE6fk2-8fNA_KQhJ-tA2FVZ6mFA2N7-w@mail.gmail.com>
In-Reply-To: <CAK2Cwb65cdpoX=B5e4cE6fk2-8fNA_KQhJ-tA2FVZ6mFA2N7-w@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Tue, 11 Aug 2020 18:40:04 -0400
Message-ID: <CAOW4vyMsuxob5mcqMkPypwg6HsNdCMSW8eHXsWhG7AHG9R+f+g@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003b043b05aca1c118"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/IYBuw32n5UCTD3p56WAEhKlyJ3w>
Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)
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: Tue, 11 Aug 2020 22:40:21 -0000
On Tue, Aug 11, 2020 at 6:27 PM Tom Jones <thomasclinganjones@gmail.com> wrote: > "The token request must not mention any reference of the RS." > this cannot be an absolute rule. I have cases were the client needs to > tell the user which they are coming back for additional grants. > The reason is typically because a request by the client for data/access > from the rs was rejected. The reason for the rejection is important for the > client to make the case to the user for additional permissions. > Peace ..tom > - If you want privacy, *don't* expose RS identity to AS. - If you want transparency, expose RS identity to AS. You can't have both.... /Francis > > > > On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha <fpo= > 40adorsys.de@dmarc.ietf.org> wrote: > >> Hello Fabian, >> >> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> >> wrote: >> >>> Hi Francis, >>> >>> I think Denis points to the fact that, in the current situation, the AS >>> receives the resource request from the Client and therefore knows what >>> tokens are asked. >>> >> The token request must not mention any reference of the RS. >> >> >>> Then it also implements the consent interface (and possibly the login >>> too) and so it also knows who validates and what is accepted or not. >>> >> Decoupling this does not change the privacy context, as the AS issues the >> Token. AS needs to add a reference to the RC in the token. SO AS can >> correlate on StudentId anyway. >> >> >>> I don't think the abstract flow deals with those privacy concerns. >>> >> To solve the privacy problem addressed in this thread, we need to go the >> (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC >> (Verifiable Credential) to the Student (in his role of RC). The Student >> will then present this claim to UNIV-1 during his registration. In this >> case we need no Grant negotiation and no AS. >> >> Best regards. >> /Francis >> >>> >> >>> >>> Then I agree with you on the audience field of the token, if left empty >>> it simplifies part of the problem, although it removes a big part of the >>> control you may want from directed tokens. That's why I'm willing to better >>> develop the RS hiding idea. >>> >>> Fabien >>> >>> Le mar. 11 août 2020 à 05:58, Francis Pouatcha <fpo= >>> 40adorsys.de@dmarc.ietf.org> a écrit : >>> >>>> Hello Denis, >>>> >>>> what you describe in the use case seems to be the default behavior of >>>> the protocol. Let me map it with this abstract protocol flow: >>>> >>>> +-----------+ +--------------+ +-----------+ +----+ >>>> +---------------------+ >>>> | Requestor | | Orchestrator | | RS | | GS | | Resource >>>> Controller | >>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>> is | >>>> | Staff | | Registr. App | | Server | | AS | | >>>> Student | >>>> +-----------+ +--------------+ +-----------+ +----+ >>>> +---------------------+ >>>> |(1) RegisterStudent | | | >>>> | >>>> |---------------------->| | | >>>> | >>>> | |(2) RequestRecordIntent(RecordType,StudentId, >>>> | | >>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>> | |<-------------->| | >>>> | >>>> | | | | >>>> | >>>> | |(3) >>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>> | |--------------------------->| >>>> | >>>> | | | |(4) >>>> ConsentRequest(RecordType, >>>> | | | | >>>> OrchestratorId):Consent >>>> | | | >>>> |<-------------->| >>>> | >>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>> | |<---------------------------| >>>> | >>>> | | | | >>>> | >>>> | |(2) >>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>> | | :RecordOf[StudentId] | >>>> | >>>> | |<-------------->| | >>>> | >>>> |(7) Registered | | | >>>> | >>>> |<----------------------| | | >>>> | >>>> + + + + >>>> + >>>> >>>> we assume the authz request sent by "Client" to "AS" describes the >>>> protected resource without referring to the authz server. An AS can issue >>>> the authz to release the graduation record of a student >>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to >>>> the target university. >>>> >>>> What matters for this authz object is: >>>> - StudentId: a reference to the student as known to the resource server. >>>> - RecordType: a reference to a resource of type graduation record as >>>> understandable by the resource server. >>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>> authz to Orchestrator.. >>>> >>>> But: >>>> - RS must trust AS issued token. >>>> - StudentId must be known to RS, AS and Orchestrator. >>>> >>>> Therefore, the AS does not need to know the RS. Keep the audience field >>>> empty. >>>> >>>> Same principle applies for the second use case. >>>> >>>> What privacy problem do you see here? >>>> >>>> Best regards. >>>> /Francis >>>> >>>> On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote: >>>> >>>>> I tried my best twice to download three use cases in the Use cases >>>>> directory, but I failed. >>>>> >>>>> Rather than failing a third time, here is the direct link of the >>>>> second try: >>>>> >>>>> >>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>> >>>>> Denis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>>> -- >>>> Francis Pouatcha >>>> Co-Founder and Technical Lead >>>> adorsys GmbH & Co. KG >>>> https://adorsys-platform.de/solutions/ >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead >> adorsys GmbH & Co. KG >> https://adorsys-platform.de/solutions/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/
- [Txauth] Three Client-Server use cases with sever… Denis
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha
- Re: [GNAP] [Txauth] Three Client-Server use cases… Tom Jones
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha
- Re: [GNAP] [Txauth] Three Client-Server use cases… Tom Jones
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha
- Re: [GNAP] [Txauth] Three Client-Server use cases… Dick Hardt
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Denis
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Denis
- Re: [GNAP] [Txauth] Three Client-Server use cases… Fabien Imbault
- Re: [GNAP] [Txauth] Three Client-Server use cases… Justin Richer
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha
- Re: [GNAP] [Txauth] Three Client-Server use cases… Francis Pouatcha