Re: [GNAP] Resource Servers draft

[Fabien Imbault <[e-mail]>]

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

On Mon, May 10, 2021 at 9:17 AM Adrian Gropper <[e-mail]>
wrote:

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