Re: [GNAP] RS draft - some comments

[Yaron Sheffer <[e-mail]>]

Quick reminder to the authors. Thanks!

 

From: Yaron Sheffer <[e-mail]>
Date: Sunday, 27 August 2023 at 4:17
To: GNAP Mailing List <[e-mail]>
Subject: RS draft - some comments

 

Hi,

 

I have read the latest version of the draft (the editor’s copy). Here are some comments. Let’s discuss the on the list first, and then open issues as needed.

 
Macaroons and Biscuits - please include references.
RS-facing discovery: I suppose the .well-known URL needs to be registered in the IANA section.
RS-facing discovery: please add Optional/Required to all fields in the discovery response.
Introspection: semantics of the access element in the request is not clear, and it may be easier to remove it completely. Otherwise, we should say that the access element in the response MUST be filtered per the request. On a related note: is it explicitly stated anywhere that an empto access array means no access is allowed?
Introspection: I'm wondering about the key element in the response. How does the AS know that the token is bound, and how does it know what key the Client should be using? In fact does it (and should it) even know who the Client is? Also, if I understand the situation correctly, the RS is supposed to send a not-fully-trusted access token to the AS first, and only then validate that it's bound to the correct key. This can easily go wrong.
Resource registration: the token_introspection_required element doesn't seem useful. If set to false but the AS receives an introspection call, should it reject it? If set to true and the call is not made, the AS would never know!
Resource registration: how is the returned resource_reference used? Perhaps it should also be returned in an introspection request, to allow the RS to validate that the Client is using the right token for the resource?
Deriving a downstream token: should we say that the AS MUST verify that the existing_access_token is targeted at RS1?
Thanks,

                Yaron