Re: [GNAP] Embedding GNAP

[Fabien Imbault <[e-mail]>]

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 <[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:
>
> [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>