Re: [GNAP] Resource Servers draft

[Fabien Imbault <[e-mail]>]

Hi Yaron,

A comment on access token formats: I don't think we should define our own
format, but we can reference other documents such as
https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-access-token-jwt
and the references to macaroons, biscuits.

The rest I believe makes good issues, most of which should be quick to fix.

Cheers
Fabien

On Sun, May 9, 2021 at 4:00 PM Yaron Sheffer <[e-mail]> wrote:

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