Field name and type for resources

Issue #449 resolved
Takahiko Kawasaki created an issue

The reasons the PR #283 “FAPI Grant Management ID1 Review: Editorial Fixes” (which was merged into the master branch during the public review period) changed resources in the example in “6.4. Query Status of a Grant” in “Grant Management for OAuth 2.0” to resource are (1) the explanation about the scopes following the example uses resource and (2) the explanation mentions RFC 8707 Resource Indicators for OAuth 2.0 which defines resource and states as follows, indicating that the name of the paramter resource does not change but its type may be an array to hold multiple values.

For an authorization request sent as a JSON Web Token (JWT), such as when using the JWT Secured Authorization Request [JWT-SAR], a single resource parameter value is represented as a JSON string while multiple values are represented as an array of strings.

However, I’m afraid that this change is not recognized well.

It seems that we should have discussion about the field name and type for resources. Points are as follows.

  1. Whether the name should be (a) resource or (b) resources.
  2. Whether the type (a) should be always an array or (b) may be either an array or a string.

Comments (13)

  1. Dima Postnikov

    Sounds like we have 2 options:

    Option 1

    {
      "scopes": [
        {
          "scope": "contacts read write",
          "resources": [
            "https://rs.example.com/api"
          ]
        },
        {
          "scope": "contacts read write",
          "resources": [
            "https://rs.example1.com/api",
            "https://rs.example2.com/api"
          ]
        },
        {
          "scope": "openid"
        }
      ]
    }
    

    Option 2

    {
      "scopes": [
        {
          "scope": "contacts read write",
          "resources": {
            "resource": "https://rs.example.com/api"
          }
        },
        {
          "scope": "contacts read write",
          "resources": [
            {
              "resource": "https://rs.example1.com/api"
            },
            {
              "resource": "https://rs.example2.com/api"
            }
          ]
        },
        {
          "scope": "openid"
        }
      ]
    }
    

    This option, while more verbose, looks more aligned to https://www.rfc-editor.org/rfc/rfc8707.html

    What do you think?

    Any other options?

  2. Takahiko Kawasaki reporter

    The option I implied is the following - simply renaming resources to resource so that the parameter name can align with RFC 8707:

    Option 3

    {
      "scopes": [
        {
          "scope": "contacts read write",
          "resource": [
            "https://rs.example.com/api"
          ]
        },
        {
          "scope": "contacts read write",
          "resource": [
            "https://rs.example1.com/api",
            "https://rs.example2.com/api"
          ]
        },
        {
          "scope": "openid"
        }
      ]
    }
    

  3. Brian Campbell

    It looks like the source file currently has resource in the example while the text has resources. This needs to be fixed.

  4. Dima Postnikov

    @Takahiko Kawasaki @Brian Campbell thanks.

    Does RFC 8707 imply that resource is a single value?

    resource

    Indicates the target service or resource to which access is being requested. Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]. The URI MUST NOT include a fragment component. It SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of the resource parameter, such as when one or more query parameters are used to scope requests to an application. The resource parameter URI value is an identifier representing the identity of the resource, which MAY be a locator that corresponds to a network-addressable location where the target resource is hosted. Multiple resource parameters MAY be used to indicate that the requested token is intended to be used at multiple resources.

    Just wondering if this has to be aligned?

    I don’t particularly mind either way personally..

    @Jacob Ideskog @Torsten Lodderstedt ?

  5. Log in to comment