Re: [GNAP] Resource Servers draft

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 <agropper@healthurl.com> a
écrit :

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