Re: [GNAP] RS draft - some comments

[Justin Richer <[e-mail]>]

Hi Yaron, Not a lot of contention here — responses inline.

On Aug 27, 2023, at 7:17 AM, Yaron Sheffer <[e-mail]> wrote:

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.

Agreed, let’s file an issue.

  *
  *   RS-facing discovery: I suppose the .well-known URL needs to be registered in the IANA section.

Yes, this needs to be registered explicitly.


  *
  *   RS-facing discovery: please add Optional/Required to all fields in the discovery response.

Will do, this should mirror what’s in the core.


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

This is the RS telling the AS “in order to access me (RS), the token needs to have at least these access elements”. The AS can use that information to determine whether the token in question meets that set of requirements. An empty access array (in the response) does not mean no access is allowed, it means that no access is specified. In all cases, the RS makes the final determination of whether and how to serve the request.

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

The AS is the party that binds the token to a key. The AS would almost certainly know who which client it sent the token to — that’s a core element of the token model. This was added to the draft here: https://github.com/ietf-wg-gnap/gnap-resource-servers/pull/57/files but it seems like the editors’ copy did not update automatically.

Yes, there are several mistakes an introspecting RS could make, but that’s for discussion in the security considerations. Additional text and thoughts on those would be most welcome!


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

I agree of the limited utility here, but it’s mostly telling the AS about the RS’s capabilities. Ultimately the AS is in charge of whether tokens can be introspected or not, or if they need to be.

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

This needs to be aligned with changes in the core doc - the value of this field is meant to be sent as the “access” value in the discovery response from the RS as specified by core. It’s a string-type resource access rights value, according to core.

  *
  *   Deriving a downstream token: should we say that the AS MUST verify that the existing_access_token is targeted at RS1?

I think that’s reasonable to add.


  *

Thanks,
                Yaron

--
TXAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/txauth