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

Fabien Imbault <> Mon, 10 August 2020 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93FB13A1568 for <>; Mon, 10 Aug 2020 06:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EO1MZ_MPGb7B for <>; Mon, 10 Aug 2020 06:26:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 437993A1566 for <>; Mon, 10 Aug 2020 06:26:59 -0700 (PDT)
Received: by with SMTP id g14so8843841iom.0 for <>; Mon, 10 Aug 2020 06:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=siOdo0VFhyJ4OT46iLp0ZDnb+kuHwEBUnMo4SPwIeSk=; b=k38/RzR9XbZXvlDgeZzh7GUUYcr7UtPFsPiU9kn41SmjtBo0lURwGH1hikgEz3wTIq Pvf+Ci0Gh++9NiBzjvAeyupxCna3DEDSy1K+xtQJnsGA3DklDNbTR8sMBJoK/vsW7DvH gTtfTaR+EEx5b18Yh5aBzUwahDNvOHN+AJyX6RYiA6n3XULBPW+myi9pna702Q8mGLZB XihZ3RC3vYEWaRfex8iRPcE7K8PURda9TIVdkDWi2DmtlDevNCELX8PH3m16T6LrztzE Fk7J9lfYD1utKVBPRl6QRizMNWq14T7V8dV7mVU2hHku5MvC/KR6YIw5wqQl+WVqrky6 y8RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=siOdo0VFhyJ4OT46iLp0ZDnb+kuHwEBUnMo4SPwIeSk=; b=p3L4Z+t561mP34+rECeQ3fdRu1SD5Eex9q68wUuPJZy2wMBsXIEFJ7gF7ramOly72Q ZhiobaHw7tdXYUTocezNb36VjltVNf7Tk4IWmQuVfdg8madF81788z8wYUPr41xaq9cc Uibvs9YTmYTZyS0MojPkB+EiynN+mlOKtOTSJVIZBmLj/ARGQjPL2GUvN0+mukG2Ka+S 6nguN0gOk9e+MS8fB2G62WlLVBITS9e3rt3u2tUDQ89LYUrbOAFwXwLYF69n1iOZf+FF 3yod4eiDqYgcx6L1HdlIoJqanDoowMVh1qWAsT5Zhf7rL8TJXM5wdiAn1WsEJx0u8wt2 nOgw==
X-Gm-Message-State: AOAM531bJzGZnGBl3tmQ+oj2txE9H0jglLcK2VSkGDZnrCPf6NB2i+sA Krj5RvBLuv4o1P51kT2I5rpJ8fCu/i2uQrJHcAM=
X-Google-Smtp-Source: ABdhPJzIR0IMN6mJL5GzneRzEsDdWGz62JWdubdRB620sNtTpTILmhyXe8GjGaAy6NthYFCJSTIi0OQiAImdZhzjTOg=
X-Received: by 2002:a6b:e31a:: with SMTP id u26mr16827273ioc.162.1597066018437; Mon, 10 Aug 2020 06:26:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Mon, 10 Aug 2020 15:26:47 +0200
Message-ID: <>
To: Denis <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000b6432a05ac85e882"
Archived-At: <>
Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2020 13:27:01 -0000

Thanks Denis for that proposal.

I believe we can already implement most of your idea with In
particular, we can easily provide an interaction server that is chosen by
the Client (which might be operated by the Client itself for instance, or
by a party distinct from the AS). But for now, I'm still going through the
AS, who knows what the tokens are used for. Your use case has the ability
to change that.

So, I'm trying to figure out how 6.2 would work, regarding RS hiding and
the need for non opaque tokens.

You're saying : "The choice of hiding or not hiding the true name of the RS
is a choice made by the Client. Such a choice may be handled through a
local configuration of the Client. If "privacy by default" is applied,
hiding the true name of the RS should be the default choice.
The role of the AS is to deliver the requested types of attributes into an
access token without necessarily knowing to which RS(s) the access token is

So, after the interaction with the RO, suppose we get a list of tokens to
mint (for instance in the format defined in XYZ), in this case we expect to
generate token1:

"token1": [
            "actions": [
            "locations": [
            "datatypes": [

As per rfc7523, the AS would then mint a JWT access token, including "aud":""quot;.
Later the RS can check that the token has been generated with the right
audience (amongst other things).
Note that there's a proposal to provide more guidance on that topic We can
imagine it can soon become fairly complex.

If I understand you well, you're suggesting an additional layer of
indirection, in the form of alias to the locations url?
Something in the form of:
1) The Client contacts the RS for information
2) The RS responds to the Client (including one-off aliases and their time
to live)
3) The Client deals with consent (cf proposal related to the IS component),
and the AS doesn't have to know what is asked
4) Based on what the RO consented, the AS is asked to mint token1, token2,
etc. with aliases
5) The Client uses the aliased tokens with the RS

I see the reason why you're suggesting that, but implementing that at scale
may be tricky. I don't see how a local configuration of the client (as you
suggest) is enough, you'll also need to share that information with the RS
at some point. To work, the mapping between the Client and the RS would
have to be private and probably even transient (if we can to avoid AS from
scrawling RS endpoints for durable aliases, which would defeat the
purpose), which pose questions of cache invalidation and the
synchronicity with the token itself.

Also you're saying (before step 5 occurs): "Once the Client has obtained
the requested access tokens, they are not immediately presented to the RS:
the Client should be able to verify that the content of each access token
is in accordance with each access token request."
I don't see the reason why the AS would present something else, especially
if it has no notion what is actually requested to whom (if the previous
scheme is effective). If we suppose we're asking for read access, maybe it
could try a write access too, but for what use?
The suggested verification scheme on the Client side supposes that the
Client is honest anyway. If so, the Client would only use the token for a
read request, so I don't understand which threat we're trying to avoid
(except from something theorical). If the Client is dishonest, it won't
care anyway.

Am I over complexifying what you have in mind?


On Tue, Aug 4, 2020 at 11:08 AM Denis <> 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:
> Denis
> --
> Txauth mailing list