Re: [GNAP] Resource Servers draft

[Adrian Gropper <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]> a
> écrit :
>
>> macaroons, biscuits, and ZCAP-LD
>>
>> - Adrian
>>
>> On Sun, May 9, 2021 at 2:34 PM Fabien Imbault <[e-mail]>
>> 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 <[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
>>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>