[GNAP] Resource Servers draft

[Yaron Sheffer <[e-mail]>]

Hi Editors,

 

Here’s a bunch of comments to the latest version (Editor’s Draft as of today). Please respond with what is easy to fix, and what I should open an issue for.

 

Thanks,

                Yaron

 

• Abstract: better use more concrete terms than "piece of software". Even if this creates a dependency on the Terminology section.
• Typo: by (AS).
• "client-facing discovery mechanism" - I'm not seeing any client-facing protocol in the document (and it wouldn't belong here anyway).
• Terminology: include a reference to the Terminology section of the Core doc.
• Access Token Formats: IMO we should specify a minimal, generic format in an appendix, as a non-normative starting point for developers. It would be better than having each implementation make its own mistakes.
• Macaroons, biscuits, other baked goods: add a reference.
• AS Discovery: why do we need a "well known" URI? Either we use GNAP Core to pass the AS address to the RS, and then we could pass a full URI, or we don't, and then how does the RS even know how to find the AS?
• Protecting RS requests to the AS: the RS, by definition, owns resources. This means that it needs to have a persistent identity, in addition to the (ephemeral) keys being presented. Otherwise (especially with TOFU registration) we could easily have Resource Servers squatting on other people’s resources. It is very hard to manage the mapping of RS to resources if we don't have such a persistent identity.
• Token Introspection: it is not clear to what depth we are defining the API: is it only the existence of the "introspect" endpoint? Or do we define a minimal set of standard attributes that need to be returned? The API would not be useful for interoperability unless we define some of the returned attributes. At the very least: "active".
• "client instance's request" - should be "Resource Server's request".
• And we should add: the AS MUST validate that the token is appropriate for the RS that presented it, and return an error otherwise.
• Typo: internal link to "token format".
• IANA Considerations: the "well known" URL should be registered (BTW, it's a well-known *URI*). Also, please list the registries that we need to establish.