[Openid-specs-fapi] Issue #455: Impact of grant_management_action=update on AT implementation and introspection (openid/fapi)

[Takahiko Kawasaki]

New issue 455: Impact of grant_management_action=update on AT implementation and introspection
https://bitbucket.org/openid/fapi/issues/455/impact-of-grant_management_action-update

Takahiko Kawasaki:

Impact of `grant_management_action=update` on access token implementation and introspection will be bigger than the impression the specification may give if the specification expects \(and probably does\) that the access token generated as a result of `grant_management_action=update` internally keeps \(in other words, does not reduce\) relations between `scope` and `resource`. At least, the standard specification of access token introspection \([RFC 7662](https://www.rfc-editor.org/rfc/rfc7662.html)\) cannot express the relations, so resource server implementations which rely on the standard introspection won’t be able to validate the access token as the grant management specification expects.

Suppose three access tokens are created as below.

1. `grant_management_action=create` & `scope=s1` & `resource=r1` → `grant_id=g1` & `access_token=a1`
2. `grant_management_action=update` & `scope=s2` & `resource=r2` & `grant_id=g1` → `access_token=a2`
3. `grant_management_action=update` & `scope=s3` & `resource=r3` & `grant_id=g1` → `access_token=a3`

After the three authorization requests above, the grant identified by `g1` will hold the following information.

```json
{
  "scopes": [
    { "scope":"s1", "resource":["r1"] },
    { "scope":"s2", "resource":["r2"] },
    { "scope":"s3", "resource":["r3"] }
  ]
}
```

If it were allowed to reduce the relations the access token `a3` should maintain to the following,

```json
{
  "scope": "s1 s2 s3",
  "resource": [
    "r1", "r2", "r3"
  ]
}
```

impact on access token implementation and introspection would be negligible.

On the other hand, if the grant management specification requires that the access token `a3` keep the relations in the same way as the grant `g1` holds, a new specification needs to be developed as to how to express the relations in access token introspection so that resource servers can protect their APIs based on the information.

For example, an introspection result for the access token `a3` should hold information like below where `"grant"` is the snapshot of the content of the grant `g1` when the access token `a3` was generated.

```
{
  "scope": "s3",
  "resource": "r3",
  "grant": [
    { "scope":"s1", "resource":["r1"] },
    { "scope":"s2", "resource":["r2"] }
  ],
  ......
}
```

Decisions that need to be made are as follows.

1. Whether to allow information reduction or not
2. If reduction is not allowed, how to express the snapshot of the grant in access token introspection

‌