Re: [GNAP] Embedding GNAP

[Justin Richer <[e-mail]>]

Hi everyone,

I presented this topic (as an individual) at the 113 IETF meeting, and you can see the slides here:

https://datatracker.ietf.org/meeting/113/materials/slides-113-gnap-embedding-gnap-00 <https://datatracker.ietf.org/meeting/113/materials/slides-113-gnap-embedding-gnap-00>

During the meeting, there wasn’t really any support for taking on this embedding work within the WG. As such, I’m personally suspending pushing this idea. If someone else wants to take this up, I’m happy to provide background and support.

 — Justin

> On Feb 9, 2022, at 3:27 PM, Justin Richer <[e-mail]> 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:
> 
> 
> 
> 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
> -- 
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth