Subject: [GNAP] Embedding GNAP

From: Justin Richer <[email-masked]>
Date: Wed, 9 Feb 2022 15:27:43 -0500

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

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 10 Feb 2022 12:09:21 +0100

Hi Justin,

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

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.

Cheers
Fabien

On Wed, Feb 9, 2022 at 9:28 PM Justin Richer <[email-masked]> 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:
> 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.
>
> [image:
> 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:
>
> [image:
> 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
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>