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 03:58 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 5F4E73A09AF for <txauth@ietfa.amsl.com>; Mon, 10 Aug 2020 20:58:35 -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 bsWENShre28r for <txauth@ietfa.amsl.com>; Mon, 10 Aug 2020 20:58:34 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 BA0723A0985 for <txauth@ietf.org>; Mon, 10 Aug 2020 20:58:33 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id g75so1027316wme.4 for <txauth@ietf.org>; Mon, 10 Aug 2020 20:58:33 -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=H8sEN/EHDBMTUeN6HL+zP2HOVTu7ZudI3//COfkedvE=; b=BaBsCjGgSTZTL628a4J5SvtHowzgHyjZYt5FGdIsmeam0VKpccyuX5JWkbN1LRuq6w 9CL7bo+hfXarirjMLYuecMO4WpJbIXU7gtsQjaRccFo+G03FsEoBXll81qxvlHbExB59 iwUC/RS0hfOtOMDJFa4B0l4dJz1UNM3FKYROw=
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=H8sEN/EHDBMTUeN6HL+zP2HOVTu7ZudI3//COfkedvE=; b=CV/tfz7gpz7lImfF4aHuXftzwLaKNr1eP6sUi2LQfuVcRvLivVLw25sKNsFfFiDUv3 FDrug+nvxX1AO4Gc06dsyfRwEhgFVABGw7FlAJ0r3cjVakUy6sxUXuC0UOKUQQQ2ruRW njs87J1AeaNT1fgfm4OlxPL0rTT3r23ioQKGZ70UO4hgDcuWY4xF4JWYrf0JhM0w2z87 aHQgmGF0grx9pSUqIGVSqrEdUFew1CrqZLwPTbwar7cfSlCY2MHe/hyYuD4yf3tJhEbL BNE07JtUh9MjkSbNToLRA9lfQRYlmmS9o/Lav6bOEWfzta5ozosyxxNMkUHisSMPO8Re HgEg==
X-Gm-Message-State: AOAM530D1QjeZK7eQ4JytljLvs3bBP3JGGovR69r5EgEfb0tfeRBEc3I TGWoPLxsDGcN46ZfRd0SOj1A6+cPEj0X85Eb+Sl75Q==
X-Google-Smtp-Source: ABdhPJxGOp8XFtFPuyObQxhBGFQrmDDhJ9cRF/svGdxiDFOVOLHOYpmqKNuNXBCPJHNh3EUV8CJt7fN+aN6KC4BfWUY=
X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr1980754wml.38.1597118311642; Mon, 10 Aug 2020 20:58:31 -0700 (PDT)
MIME-Version: 1.0
References: <d2ee5da2-8e88-15c8-8646-087860463d2c@free.fr>
In-Reply-To: <d2ee5da2-8e88-15c8-8646-087860463d2c@free.fr>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Mon, 10 Aug 2020 23:58:20 -0400
Message-ID: <CAOW4vyOwQTMoo2Nmb8KNcVM5hdOW69FzZTK5XQ2fRL9CC8+SUA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a14bd405ac9215da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/bjJrZmvPtYaEhRekj9w_MsUrq-w>
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 03:58:35 -0000

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/