Re: [GNAP] Embedding GNAP

Fabien Imbault <> Thu, 10 February 2022 11:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E7D93A0818 for <>; Thu, 10 Feb 2022 03:09:39 -0800 (PST)
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 8kEvqQsxXfoZ for <>; Thu, 10 Feb 2022 03:09:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 183D33A080A for <>; Thu, 10 Feb 2022 03:09:34 -0800 (PST)
Received: by with SMTP id d3so3992133ilr.10 for <>; Thu, 10 Feb 2022 03:09:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ip85iL1EPmbT6dPPV0x97f/85I/hoAKUbq9h95UK0g=; b=jUEwMHP8K6ztEtA1VFg5fUhQe846/7G4G7kqqEm7pD4bMKftJ14ko0LwrWUM/r+bWc CeMvSFqoPT8BGtBCTgIf4c6IHQkaw2l8S+pqiYITl0FO+9sQ483A6SPAbGrTWtCQW95K PDlHgvAlx0O53sxutMBK7n1qXQM3N+ylTvlyXwPJ4su4Ovf6Iyl8g21N4RNyEJtNzzXL HebBnFA8g4vUazdgdiPGXkjbF99wISaX6hY6J4KsQYYspibRXpP34WwX7Ows3Ni/lF7M 8yiQ6UX5NxZjeajLTNOTKg9ywcBsTCXALir2GSeg5GHglXNosRbRpKAgz+exsQPcBwLD pidg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ip85iL1EPmbT6dPPV0x97f/85I/hoAKUbq9h95UK0g=; b=dM5ZPEVx0D7gOcm1cFfqOY7zEG8pABliMiv0ghtLeDTuAZB24qJGnrq8cy+b2+AHLm 2yz38QbIDNkR6pPIPfD2UYYBfGVM9HW4Vx/AEIlP84r0V+wmOisD9pLscAErKIw5myGV xrZWe57KiAidLeOuL/IZlozW/Tv4WnYgeMeuSIsT6fbVroJC4WXtcYGYKEAVDuaoaOTs 2Wm0f4C2RVb3ddF1Fa6Cx5O0qDqETl+wJZML02TAez2WMP6jr+t3Kc5Ew+ChntYlPi66 l0N2e9kzcghSykPGbCY+mX8xnUd42yhPbGeh82lOgDOYWqZk9glmQz58kUDtS9rItDbK WKMg==
X-Gm-Message-State: AOAM532nBgIKXyHTea3NPda/FdIOQUoXdy693HrMmggy+O5sUYRNNUYb l6VGHZWCMjvtfHwWIsRyFQXGDNORsKBiF36KWLl5ErlY
X-Google-Smtp-Source: ABdhPJxjVQm6RS1MYoOGypVV0S9G75CTF4cVX7irFQvtImz9J1NCgWHZRIYI1HcPYVxjVOuNu8PddCH0vHsqgI9FAyQ=
X-Received: by 2002:a92:c52f:: with SMTP id m15mr2904752ili.160.1644491372117; Thu, 10 Feb 2022 03:09:32 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Thu, 10 Feb 2022 12:09:21 +0100
Message-ID: <>
To: Justin Richer <>
Cc: GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="00000000000012448605d7a7fcb3"
Archived-At: <>
Subject: Re: [GNAP] Embedding GNAP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Feb 2022 11:09:39 -0000

Hi Justin,

Thanks to you and Dmitri for bringing that up. That seems really

Option 2 (embed protocol in GNAP) would really be beneficial.

Option 3 (embed GNAP in protocol) is more ground breaking and illustrates
the power of interactions in GNAP. I can think of a few use cases which
would be very ad-hoc today (ex : update the credit card about to expire).

I think it would be good to at least test what that would mean (entry
point, output). Coding it on a specific use case (VC-API or something else)
would likely provide valuable feedback.


On Wed, Feb 9, 2022 at 9:28 PM Justin Richer <> wrote:

> Dmitri Z’s presentation at the interim has had me thinking about how GNAP
> connects with other protocols, including other security and identity
> systems. In particular, I think it brings to light two different ways of
> looking at GNAP that have been in the system’s design from the beginning
> but hasn’t gotten a lot of discussion. I’m hoping we can start that
> discussion on this thread. While it’s VC’s that spawned this discussion
> most recently, there were also use cases early on about using GNAP for
> things like mid-protocol step-up authentication and interaction.
> First I want to show the more “traditional” model that allows for a full
> separation of the security and authorization layer from the API. This
> should be of zero surprise to anyone who’s worked with GNAP, OAuth, UMA, or
> any number of similar systems for many years, but I’m including it as a
> baseline for discussion:
> [image:
> Second, we can embed a protocol inside of GNAP. GNAP’s “interaction”
> mechanism is inherently more flexible much of what’s come before, so it’s
> entirely possible, if you’re already doing GNAP, to embed a whole new
> protocol in the middle as part of the interact/continue-grant process,
> especially if it’s dealing with identity and user information.  We can even
> include the “Foo” protocol information in our response from the AS, and
> OpenID Connect showed us the power of this by including the ID Token
> assertion alongside the access token of an OAuth response.
> [image:
> This is something I think that would be particularly valuable to use
> VC-API in, since the context of the ongoing grant request adds everything
> that the VC API would need to make its decisions. And especially with
> VC-API, we can provide the ultimate VC generated as part of the response
> from the AS in the last step, in the subject information block. This is
> something I’ve proposed to the VC-API working group to take up, but there
> hasn’t been interest there to date. I do think it makes a lot of sense,
> though.
> Finally, and this is where Dmitri’s work is heading, is the idea that you
> could embed a portion of GNAP inside of a completely separate protocol. The
> result would be specific to whatever protocol you’re using to wrap things,
> but it could look something like this:
> [image:
> What I find interesting about this last model is the concept that the
> “Foo” API responds with its own wrapped version of the GNAP response,
> including information about accessing a GNAP Grant Continuation Endpoint
> (including access token). The client can communicate with whatever
> endpoints and protocols the Foo-AS needs, but importantly they’re all
> wrapped up in otherwise standard GNAP “interaction” hooks. And finally, at
> some point, the client makes a “grant continuation” call but instead of
> getting back a GNAP response, it gets back the Foo response it asked for
> back in step 1.
> Now, this is weird for a lot of reasons, and it certainly is not GNAP, not
> really anyway. So it’s not for this WG to decide what this would look like
> for every protocol — but my question to this group is twofold: do we want
> to write guidance about how to do this kind of embedding? Is the proposed
> VC-API work a good candidate for this kind of thing with a concrete
> protocol?
>  — Justin
> --
> TXAuth mailing list