Re: [GNAP] Resource Servers draft

macaroons, biscuits, and ZCAP-LD

- Adrian

On Sun, May 9, 2021 at 2:34 PM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> 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 <yaronf.ietf@gmail.com>
> 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
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>