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:47 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 86FD33A0D84 for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:47:40 -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 v2owTs5yrB23 for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:47:38 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 07D643A0D75 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:47:37 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id 9so175867wmj.5 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:47:37 -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=qnhlk+ic5O5aRXm/WSXTCAUtnVa8m+cGrK5fiNA1T7g=; b=Z4x/gYiN8Re6rxdN21KUEsIk+Q1nw8fZYyFefPIXTrPoDfjQ/bwkfoTZb5PW4l1RCY XvmWw2En3ZfIcsM24q1cV1K0JrKAuRNg2DvJ6HR2MvQv7kxXq0gJDdUBFOqmgXCXze1P /1DuCTpRC8bPYu3GVq6/E7bBNSMyt00xbeOLc=
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=qnhlk+ic5O5aRXm/WSXTCAUtnVa8m+cGrK5fiNA1T7g=; b=UnYaYPcriHFpxRNckGvV4o9ckwahQVMeg/jeGU+5n0MGwx7d0jGg3F1SqlnQpQMVKn PzAGEUP661jVio6K4CW2PlTxXsvbpaGg3awrRgtcrtUgMVR6J1CczsvLkDdCaKvHh+r4 cEtXgprXZmCW3ZdgJRk/2E2s4Vw0gFeF+O+jucG2TbX4Dh0dkn4RHPFBBeHRxqret1Yo cS0O6quSJIclOh57HJYjNinKaOHZ4irx2ndVMWyypsI/LPIJg8Mh6wsSyo0dxg+5+Fgy Z6qUPcc6tFvigUDI314qnJ0CkA/K/C9r88+hTleU8ReRkWX7jhT/fauqGPmXzi3yQGv/ G9Qg==
X-Gm-Message-State: AOAM5314OTFOzAWHs3O3uC+pmSBtNDgJ+0nTvBN91vrfb6Kz/Gv/Mdjf Ps93LwY5KSBdzNAl9hzEaabGq9EHh2MPSYKuqmGL3A==
X-Google-Smtp-Source: ABdhPJw8gllFPL0m51YKYoZHeBwzz+5btrROxfgaxbOmQI/YQywzz6upc6jTfExVeOGq6ToQPciEjN32gZXOICUbC8U=
X-Received: by 2002:a1c:3985:: with SMTP id g127mr5435429wma.64.1597186056372; Tue, 11 Aug 2020 15:47:36 -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: Francis Pouatcha <fpo@adorsys.de>
Date: Tue, 11 Aug 2020 18:47:25 -0400
Message-ID: <CAOW4vyNNLgyZXsBN6Spb5BKUy58+xeQvGFdFtvJNtz-C+bTQ8A@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="00000000000087d7e105aca1db0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/DvtP6uEtPHXSB1SgdRf7NTaqX6o>
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:47:41 -0000

Hello Tom,

On Tue, Aug 11, 2020 at 6:42 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
>
I hope GNAP will be designed to support SII. If you could drop some use
cases here: https://github.com/ietf-wg-gnap/general/wiki

>
>
> 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/
>>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/