update manage URI section

[fimbault]

Close #70

[netlify[bot]]

✔️ Deploy Preview for gnap-core-protocol-editors-draft ready! Built without sensitive environment variables

🔨 Explore the source changes: 00d478c5ff0bc5603d237c1ab0bd3cacb76b353d

🔍 Inspect the deploy log: https://app.netlify.com/sites/gnap-core-protocol-editors-draft/deploys/62056d6a34200a0007f9aca3

😎 Browse the preview: https://deploy-preview-383--gnap-core-protocol-editors-draft.netlify.app/draft-ietf-gnap-core-protocol

[adeinega]

I do like that this requirement goes away. Now, assuming we don't have it anymore... why don't make it available through the sever's discovery information?

Furthermore, you might want to have all examples/references with "manage" to be consistent as right now it doesn't appear to be true.

[jricher]

@adeinega It is still allowed and even intended that you can return different management URIs per token, so putting it in the discovery document is not reasonable. The client needs to be ready to take any value handed back in this space at runtime, and that's up to the AS's discretion.

[adeinega]

@jricher, I understand that the AS can return different management URIs and the clients should "obey" that.

Although, in the most simple use cases, you can definitely make a life a bit easier for certain types of clients and don't require them to store somewhere an extra piece of the information along with ATs or even without them... For example, for the latter, should be a client on an RS' side be able to revoke ATs and if so, how would it know where their mngt endpoints?

[jricher]

A client would only be able to revoke an access token if the AS provides a management URI with the access token. It's a significantly simpler model for clients if the information can only show up in one place, instead of potentially being in one place (discovery doc) and maybe being overridden at runtime (token response). Nothing requires the client to store the information if they don't want to revoke or rotate the tokens.

An RS revoking an access token is outside the scope of this draft, but could be discussed in the RS draft. (I haven't heard a call for that functionality before, though it's interesting.)

[adeinega]

I would love you guys to take care of

An RS revoking an access token is outside the scope of this draft, but could be discussed in the RS draft. (I haven't heard a call for that functionality before, though it's interesting.)

as this is something I was failed to understand before but never brought to the table before as always considered it to be a minor detail.

[jricher]

@adeinega I filed a new issue for that at ietf-wg-gnap/gnap-resource-servers#52, please add comments about the use case and utility there. Thank you!

[adeinega]

@jricher, thank you, I will do that.

Regarding the clients who obtain, store and use ATs, or in other words, these clients that don't reside on RS' side... all those clients need to store information about the mngt URI along with ATs they have. This is just a bit of extra work and isn't a big deal at the first glance but let's consider that

1. a client is implemented and deployed as something like a service/lambda function in one of the cloud providers without the luxury to (easily) store something say on the filesystem and/or with a bunch of requirements or specific restrictions on where and how things should be stored. This is the first thing. It's still solvable... yes, I agree... but there is also another thing; you aren't a developer of the client and your goal is to explain what should happen to dozens of other teams who might have a little interest and tell you they we want to have/store only ATs and the location of the AS as they used to work this way before with OAuth 2, etc.

2. you are working on the "generic" GNAP client library for your most liked programming language and you want to provide a convenient API for its consumers taking into account that your client in some cases knows what's the location of the token mngr URI and in some cases, it simply doesn't

[jricher]

@adeinega the client in (1) still needs to store the access token, which is a dynamic value. This is another dynamic value next to it. Your proposed optimization makes that case much more difficult because now the code needs to be able to pull the value either from the previously-configured place or the dynamic place, instead of always in the dynamic place.

For the library in (2) it's even more simple: the client never "knows" ahead of time what the URI is, it's always told by the protocol, so the library always just handles it directly.

But that's only if you want to do the revocation/rotation for the client. You can ignore it entirely if all you want to store is the AS's base URI and the token value. In both (1) and (2), if the client doesn't know how to deal with dynamic management URI values then it simply doesn't deal with them.

Yes, this is a different model from OAuth 2, but that's on purpose. Several of the major attacks against OAuth 2 (like AS mix-up) stem from the discovery document containing a bunch of different URLs that the client needs to knit together to make a single picture of the AS.