Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)
Dick Hardt <dick.hardt@gmail.com> Tue, 11 August 2020 23:29 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 B700C3A0DCB for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 16:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=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 xjxBEfkkccWX for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 16:29:47 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 ADD8D3A0C90 for <txauth@ietf.org>; Tue, 11 Aug 2020 16:29:46 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id 185so183293ljj.7 for <txauth@ietf.org>; Tue, 11 Aug 2020 16:29:46 -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=WWzyNpL/Wc/9t/l9nXctzHIVeIzc0JpACmoqFcIZDcY=; b=UMlcJ3iMvt9usI+wSFP9r92Ch0+Qnlsrsg8zRSoDufeoObuWt4BVOM5EdqdcMxDqAz MkSwNPvcJv3QT2xkjhWKSShEjB4ozuRHANKi8yj0CdgGv5Ie7nYMK8DF0PhPNpdgM3p6 DoGndyn2Rimdily9ZFsKUAPD+XAl7kh8PU+RkxDYeLz5PdHuvaELVzm77Ag5kEGVfMv3 o9wgKwQ0bx6V/wRw53O1DCwLYhh7tEv7YRAqqH57JKqhVCRmjrDeTJZ/69FGrkQvAM8g F1D4v4dMLwa4NDJc3ZW4yD4Yw3G/xs+9MJJPMMjOGt7s/O96W3vVjMKqNRt2KcsfLoAI 16Cg==
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=WWzyNpL/Wc/9t/l9nXctzHIVeIzc0JpACmoqFcIZDcY=; b=pCd8Q2qbqKuxMA0JZYlLp2GQAC38VBsfVUKnaHSVOj5NRdbxGsQUHLPbTYyUH0lTQB oFMOwi+6mATQaeyGQkGpNhPaHTh06pMP8EA1zLFQ7gbTqLCVUEGVh3ePeVM05TgBDgCc ytgiDhh31fsmFvij4e5ib5GaPMg6t1Ct2LwLGKqU2ay9NOCVRHqXfnihSQRJllafdVAU AcZN3e7FvoMalpYww6CR+7tFy8A0cRTBTpNmCMfbI3w4GYgWP+lWI61JiLNIwjwgRLhB 0ibarhQzhSzcEr+huOA7NKIUQkBc6WSe5gOEc0TDbruoKfWZuXfuL84YrWvPoaQRtyOT SRQA==
X-Gm-Message-State: AOAM5324sRTLSjoQwhDgfxZ6Ix4NBwo6l7edrO4D869M+266aTXoW+D5 6WTq8Gx8yqtl9XbOnhMVmhmWpR3Rqdqp0fVSohU=
X-Google-Smtp-Source: ABdhPJwgcb22ZpocTGpk6xfnxRjKybdT6P9IQch/KORbmEpx2KhRFistnsNtU3OoAmdraNeUc1e4lkQFm5xYD2FVSfw=
X-Received: by 2002:a2e:865a:: with SMTP id i26mr3774188ljj.246.1597188584809; Tue, 11 Aug 2020 16:29:44 -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> <CAOW4vyMsuxob5mcqMkPypwg6HsNdCMSW8eHXsWhG7AHG9R+f+g@mail.gmail.com> <CAK2Cwb42QH-7AF=fu2eKVSLh0Baa1gmU2Ou7kfH_GH--H77xoQ@mail.gmail.com>
In-Reply-To: <CAK2Cwb42QH-7AF=fu2eKVSLh0Baa1gmU2Ou7kfH_GH--H77xoQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 11 Aug 2020 16:29:08 -0700
Message-ID: <CAD9ie-sD_wrHwOrL9RMBbK-Z41hNqub2qftnsv5K52=Ukqgw=w@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Francis Pouatcha <fpo@adorsys.de>, Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ca79705aca2726d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/SYjs6qARfRRrXppqPYomuLLYLw4>
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 23:29:51 -0000
Tom, do you have a straw man on how a client would interact with an AS on the user's device? ᐧ On Tue, Aug 11, 2020 at 3:43 PM Tom Jones <thomasclinganjones@gmail.com> wrote: > I guess I need to ask the group as a whole then. > Will GNAP support self-issued Identifiers? > If so then the AS is on the user's device. > I need to understand that SII are in-scope. > Peace ..tom > > > On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha <fpo@adorsys.de> wrote: > >> 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 mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [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