[GNAP] Re: GNAP RS-AS interaction questions

[Justin Richer <[e-mail]>]

On Dec 4, 2024, at 10:18 PM, Erin Shepherd <[e-mail]> wrote:



On 4 Dec 2024, at 20:27, Justin Richer <[e-mail]> wrote:

Hi Erin, some answers inline.

On Dec 4, 2024, at 7:49 PM, Erin Shepherd <[e-mail]> wrote:

Hi,

I’ve been looking at implementing GNAP with some interest (on the whole I find it a very readable and straight-forward specification!) but I’ve spotted a few of areas of difficulty:

1. The GNAP-RS spec says, in the introspection response

iss (string): REQUIRED. Grant endpoint URL of the AS that issued this token.

This seems a little limiting? Let’s say I have an existing OAuth IDP that I’m adding GNAP support to; it seems that the spec basically requires that a GNAP RS will see different sub+iss values from an OAuth RS?


That’s likely to be the case - the issuer of a GNAP token is the AS which is itself defined by its grant endpoint URL. GNAP is largely designed to not need a discovery protocol, so starting with the single URL alone (the grant endpoint) you can kick off everything else you need with an immediate request. This was a deliberate design decision to depart from OAuth, and it prevents a host of attacks, including several forms of AS mixup that can occur in a poorly configured OAuth system.

I understand the goal, but I’m a bit concerned about the implications in heterogeneous environments. If a GNAP client asks for an ID token, what sub/iss combo do I put in there? How does it even know how to validate the ID token?

(I guess it actually doesn’t really need to validate it because it was received over a secured channel, unlike front-channel ID tokens in OIDC, but the thought remains)

One of the things I’m concerned about is - lets say we consider an RS+RP that speaks GNAP, receives OIDC ID tokens from the AS, and handles user provisioning/synchronization with SCIM - how do we ensure consistent identity mapping across all of these?


ID tokens are not access tokens - so the access token format listed in the GNAP RS document doesn’t apply. They’re assertions defined by OIDC core and would have the OIDC issuer claim in them. So a GNAP client would get an ID token as part of the subject information and validate it just like it would for core OIDC — the 'iss' claim would be different but that’s not really a problem here.

An RS+RP would be an odd combination, since the RP maps to the client in the OAuth/GNAP model. What’s the use case for this type of application where it would have multiple different roles simultaneously? And in such a case, wouldn’t it be important to distinguish between an ID token assertion and an access token, anyway? You wouldn’t want them to behave the same way or get confused with each other.



2. The GNAP-RS spec lists five different token formats that an AS can declare support for but provides no information regarding the contents or validation of those tokens. It seems like the only way (within the written text of the specification) to validate a token would be to submit it to the introspection endpoint, which seems like it rather defeats the purpose of knowing the format.

I would have liked to see some guidance on

* How to locate the AS’ token signing keys for "jwt-signed” access tokens
* How to agree encryption keys for "jwt-encrypted” access tokens
* Required JWT claims & claim values
* Similar for the other formats (with which I have less experience)

i.e. something along the lines of RFC 9068 I guess (That could perhaps even have been referenced directly, with minor differences?


In my opinion, details for that level of interoperability are better fit for a technology specific profile, than in a general specification like this. I think it would have been great to have separate specifications detailing each token type and registering them, but the most that the WG agreed on was listing the token types on their own at this level.

I don’t disagree, but I also think that perhaps the registry entries shouldn’t have been created at all in that case. The purpose of registering things like that, to me, is to say we both implement the same interoperability spec.


3. As far as I can tell, there’s no way for the AS to return subject information to the RS beyond the fixed set of introspection response values?

I would have expected something similar to the Subject Information defined in GNAP s3.4 to be returned (or requitable)

That’s a great idea, but would need to be defined by an extension at this point. Unfortunately the RS spec did not get as much attention as the core spec in its final days, and so features were fairly limited.


4. Its unfortunate that the discovery URI was not defined to work by splicing /.well-known/gnap-as-rs into the start of the path segment in the same way as OAuth Authorisation Server Metadata is. Oh well, such is life, it would appear.

This was another intentional divergence. The way that the OAuth AS Metadata document does things is problematic, as it was trying to adapt what the OIDC discovery spec did with paths — which was itself in conflict with the definition of ".well-known" in the first place. The result is a bit of an awkward compromise. We deliberately sidestepped that in the GNAP specification. I’ll also note that we did not use any .well-known path in the core specification, but the rs-facing discovery needed to be separated and so we went with .well-known here.

I almost wonder why the metadata wasn’t just added to the GNAP metadata, but alas. I’m sure reasoning was solid.

That was suggested at the time, but the consensus was that the RS-facing components would need to be sufficiently different to warrant a different document.


Anyway, thanks for the comments

- Erin