Subject: [GNAP] Resource Servers draft

From: Yaron Sheffer <[email-masked]>
Date: Sun, 9 May 2021 16:59:50 +0300

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.

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 9 May 2021 20:33:35 +0200

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Adrian Gropper <[email-masked]>
Date: Sun, 9 May 2021 14:53:29 -0400

macaroons, biscuits, and ZCAP-LD

- Adrian

On Sun, May 9, 2021 at 2:34 PM Fabien Imbault <[email-masked]>
wrote:

>>    - 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
>> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 10 May 2021 09:03:50 +0200

Yes, seems a good place for an extension registry. The most important is
that we can support both simple tokens (jwt or equivalent, ex paseto) as
well a capability tokens (biscuit, macaroon, zcap-ld), and define what's
commonly supported. Yet it seems easier to keep to the rule of not
including linked data as a dependency in the main documents (but that's a
personal opinion).

Fabien

Le dim. 9 mai 2021 à 20:53, Adrian Gropper <[email-masked]> a
écrit :

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

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 10 May 2021 03:17:47 -0400

I agree with not making LD a dependency but the SSI folks are in love so
it’s nice to respect that.

Adrian

On Mon, May 10, 2021 at 3:04 AM Fabien Imbault <[email-masked]>
wrote:

>>> A comment on access token formats: I don't think we should define our
>>> own format, but we can reference other documents such as
>>>>    - Abstract: better use more concrete terms than "piece of
>>>>    software". Even if this creates a dependency on the Terminology section.
>>>>    - Typo: by (AS).
>>>>    - Terminology: include a reference to the Terminology section of
>>>>    the Core doc.
>>>>    - 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".

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 10 May 2021 09:27:11 +0200

Yes, for DIDs it makes sense as it's very established now.
But capability tokens don't have that chance yet, so a registry seems to me
like a better idea, especially if they require that kind of extra
dependency. None of them have been defined as an RFC yet. I could propose
to do the work for biscuits, together with the good folks of CleverCloud.

Fabien