Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)

Tom Jones <thomasclinganjones@gmail.com> Tue, 11 August 2020 22:43 UTC

Return-Path: <thomasclinganjones@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 1E1A13A0E11 for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:43:02 -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 ysDKmpgWmdYq for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 15:42:59 -0700 (PDT)
Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 91EC43A0DBD for <txauth@ietf.org>; Tue, 11 Aug 2020 15:42:59 -0700 (PDT)
Received: by mail-oo1-xc29.google.com with SMTP id j19so72473oor.2 for <txauth@ietf.org>; Tue, 11 Aug 2020 15:42:59 -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=K8zOZ8zdDw29axLCsBTbq4dPXMJRocUfOJ5wrK2WoHw=; b=tuwah/mwg7VGgktNexjN8F/+Gj8ax58FsHhLo1BZpfen3OozbTjC9s9u0OOgr0y7Oy TC8bj2qmCxWgAjfnz1Orn7SSJeVbKCFylTGC4NhE+V4VnTe353dILTjSuhh2zKcAB9ON Y9qaOlt8tIjoZHuGjvxPDIpO0WLJRWLsI6DHqXfdXvaJl6zXLgC9S2h1kO5Dx5aVDX4l +k7xh6cnjzag3TNnu+y/JVWXky40wY95ib4mLJz7VORaL5o7jk8NsJLryqWsuR4j9qxk nhlysNtNp7pq6TZ8CW4LRQAg3BM+NPaMfw7T0/qJwpomxnYyF/S8Jq8G70qDTZgZbcfT eK0Q==
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=K8zOZ8zdDw29axLCsBTbq4dPXMJRocUfOJ5wrK2WoHw=; b=jfun97nbu48J0Ud1RalmobCuAZHSK0eZ83iVZUT5rJXsQFYA7IsHcuXJ48aqE02Ltr JZzw0ZocFQoD3Z36tt3OU5xLuzeN8VKXe9lwm5EZczKy0YuxGO9s+y2YHvuZ7ZHKpLgW IGiDOnklAir79znoDTRunJeETmDHOkytOOx4xtNaPEWmDoJ210q9SuOiDmRvhOpYntI6 k3WRryxqXUsYjxVb05ct+Q34Jlh4oyaE1ZZZENlG0HB5b25wvqQnZXXpaBi3O2sEMSPi JK3pj8vuM4sioeAhg6TVm6fwCx/ZMsDhlsRI84P39//kc2Q/2KT8sCHmmvd61+44T635 nt/Q==
X-Gm-Message-State: AOAM531ekLroxy+BVAcfexwFjPNUANWpKO7CIP9MKW/5qmMDN+u715EF 2uNDCp1enaH7GBA3qnUGC/35xzNaeeRfnxnY5gM=
X-Google-Smtp-Source: ABdhPJx6XYVAS1q3pT8rXlpRFw0afpuUp59xgznS9EjbHVggB+XG0Eb4vPQhEA9qvqxv7fHEOlj8/pRZql53u8ZQmVw=
X-Received: by 2002:a4a:aa0e:: with SMTP id x14mr7174404oom.27.1597185778623; Tue, 11 Aug 2020 15:42:58 -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>
In-Reply-To: <CAOW4vyMsuxob5mcqMkPypwg6HsNdCMSW8eHXsWhG7AHG9R+f+g@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Tue, 11 Aug 2020 15:42:47 -0700
Message-ID: <CAK2Cwb42QH-7AF=fu2eKVSLh0Baa1gmU2Ou7kfH_GH--H77xoQ@mail.gmail.com>
To: Francis Pouatcha <fpo@adorsys.de>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9a7ef05aca1cab7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/IJaDgoLW9fln86xoQFyDNXsMWfk>
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:43:09 -0000

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