Field name and type for resources
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.
- Whether the name should be (a)
resource
or (b)resources
. - Whether the type (a) should be always an array or (b) may be either an array or a string.
Comments (13)
-
-
-
assigned issue to
-
assigned issue to
-
Looking to resolve this through #457
-
- changed milestone to 2nd Implementers Draft
-
-
assigned issue to
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?
-
assigned issue to
-
@Takahiko Kawasaki @Jacob Ideskog @Brian Campbell @Torsten Lodderstedt
-
reporter The option I implied is the following - simply renaming
resources
toresource
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" } ] }
-
It looks like the source file currently has
resource
in the example while the text hasresources
. This needs to be fixed. -
@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. Multipleresource
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 ?
-
Discussed on a call today. Option 3 from Taka has WG support.
-
Added to this PR: https://bitbucket.org/openid/fapi/pull-requests/347
-
- changed status to open
Related to
#347 -
- changed status to resolved
PR merged
- Log in to comment
This also relates to the issue https://bitbucket.org/openid/fapi/issues/437/grant-management-api-query-response