[GNAP] Re: GNAP RS-AS interaction questions

[Erin Shepherd <[e-mail]>]

> On 4 Dec 2024, at 22:39, Justin Richer <[e-mail]> wrote:
> 
> 
> 
>> On Dec 4, 2024, at 10:18 PM, Erin Shepherd <[e-mail]> wrote:
>> 
>> 
>> 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.

One difference here is that for OIDC Core you have an established client relationship with the OIDC issuer. For GNAP you have a relationship with the GNAP issuer. Now, if the two are related (or colluding) that’s effectively one and the same thing, but how can the application know this?

> 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.

I actually think that an RS also being an RP is the most common case - but primarily they do so for authenticating a user to themselves. Consider a mail service - it’s an RS when someone wishes to access it over JMAP/IMAP/etc, and an RP when it’s offering webmail (or a configuration UI, or..)

Anyway yes it’s very important to distinguish between an ID token assertion and an access token assertion - but when you deal with both of them you need to be able to correlate users across them. If I’m an RS+RP client to an OIDC AS, I’m basically guaranteed to get the same iss+sub combination in both the access tokens I receive from other RPs when behaving as an RS, and in the ID tokens I receive when behaving as an RP.  (RFC 9068 doesn’t explicitly state this, but it is the only logical option in most situations, and cases where the AS has decided to do otherwise are probably intentional)

I’m not quite clear on how I’d do that with GNAP.

- Erin