[GNAP] Embedding GNAP

Justin Richer <jricher@mit.edu> Wed, 09 February 2022 20:27 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E84963A0A7D for <txauth@ietfa.amsl.com>; Wed, 9 Feb 2022 12:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aGZUFLtLoUqM for <txauth@ietfa.amsl.com>; Wed, 9 Feb 2022 12:27:46 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15DE3A0BE3 for <txauth@ietf.org>; Wed, 9 Feb 2022 12:27:45 -0800 (PST)
Received: from smtpclient.apple (static-71-174-62-56.bstnma.fios.verizon.net []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 219KRhLa023623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <txauth@ietf.org>; Wed, 9 Feb 2022 15:27:44 -0500
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2973A845-C636-4FCC-BD8D-A2500453D19A"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
Message-Id: <9B662493-2636-41B4-AF00-396D4E09A995@mit.edu>
Date: Wed, 09 Feb 2022 15:27:43 -0500
To: GNAP Mailing List <txauth@ietf.org>
X-Mailer: Apple Mail (2.3693.
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/KNB3BJhwmAYyJ68y_m1VnnS2kQ4>
Subject: [GNAP] Embedding GNAP
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <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: Wed, 09 Feb 2022 20:27:52 -0000

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:

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgRW1iZWQgR05BUCBpbiBQcm90b2NvbCAobmF0aXZlKQoKQ0ktPkZvbzogU3RhcnQgdGhlIEZvbwAhCQpGb28tPkNJOiBXV1ctQXV0aDoASQUKb3B0AAMGQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTADAGcwBRBWludGVyYWN0ICJmb28iACQPY29udGludWUAKwlhY2Nlc3MgdG9rZW4vaWRlbnRpdHkvZXRjCmVuZCBvcHQAgSsKRm9vIHAAgU0Idy8ALgwKCg&s=default <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgRW1iZWQgR05BUCBpbiBQcm90b2NvbCAobmF0aXZlKQoKQ0ktPkZvbzogU3RhcnQgdGhlIEZvbwAhCQpGb28tPkNJOiBXV1ctQXV0aDoASQUKb3B0AAMGQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTADAGcwBRBWludGVyYWN0ICJmb28iACQPY29udGludWUAKwlhY2Nlc3MgdG9rZW4vaWRlbnRpdHkvZXRjCmVuZCBvcHQAgSsKRm9vIHAAgU0Idy8ALgwKCg&s=default>

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.

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgRW1iZWQgcHJvdG9jb2wgaW4gR05BUAoKQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTLT5DSTogc3RhcnQgaW50ZXJhY3QgImZvbyIKb3B0IFRoZSBGb28gUABKBwpDSTwtPkZvbzogRG8gdAAPDyBpbiBDb250ZXh0CkZvbwBWBgBNCWZpbmlzaAplbmQgb3B0AIEDD2NvbnRpbnVlAIEKCWFjY2VzcyB0b2tlbi9pZGVudGl0eS9mb28vZXRjCg&s=default <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgRW1iZWQgcHJvdG9jb2wgaW4gR05BUAoKQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTLT5DSTogc3RhcnQgaW50ZXJhY3QgImZvbyIKb3B0IFRoZSBGb28gUABKBwpDSTwtPkZvbzogRG8gdAAPDyBpbiBDb250ZXh0CkZvbwBWBgBNCWZpbmlzaAplbmQgb3B0AIEDD2NvbnRpbnVlAIEKCWFjY2VzcyB0b2tlbi9pZGVudGl0eS9mb28vZXRjCg&s=default>

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:

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgRW1iZWQgR05BUCBpbiBQcm90b2NvbCAob3B0aW1pemVkKQoKQ0ktPkZvby1BUzogRm9vABwKUmVxdWVzdAoAFwYtPkNJOiBlbWJlZGRlZCBncmFudCByZXNwb25zZQpvcHQAYQZzbmlwcGV0AEkNACYGY29udGludWUKQ0k8AGgKaW50ZXJhY3QvABcIL2V0YwAiHGVuZCBvcACBCA5Gb28gcACBVQgAgQsJCg&s=default <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgRW1iZWQgR05BUCBpbiBQcm90b2NvbCAob3B0aW1pemVkKQoKQ0ktPkZvby1BUzogRm9vABwKUmVxdWVzdAoAFwYtPkNJOiBlbWJlZGRlZCBncmFudCByZXNwb25zZQpvcHQAYQZzbmlwcGV0AEkNACYGY29udGludWUKQ0k8AGgKaW50ZXJhY3QvABcIL2V0YwAiHGVuZCBvcACBCA5Gb28gcACBVQgAgQsJCg&s=default>

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