Condition for a token response to include a grant_id

[Takahiko Kawasaki]

Section 5.4 Token Response of Grant Management for OAuth 2.0 ID1 states as follows.

The AS will return a grant_id if it supports any of the grant management actions query, revoke, update, replace.

Q1. Is it allowed for the authorization server to issue a new grant ID even when the authorization request does not include grant_management_action=create explicitly?

Q2. Is it allowed for an implementation NOT to issue a new grant ID when the authorization request does not include grant_management_action=create explicitly even if the implementation supports query, revoke, update and/or replace?

Q3. Why is create excluded from the list of the grant management actions?

If asked, I would change the paragraph to like below.

The AS will return a grant_id if the authorization request includes grant_management_action.

‌

[Dima Postnikov]

Q1. Is it allowed for the authorization server to issue a new grant ID even when the authorization request does not include grant_management_action=create explicitly?

Yes, it is allowed.

Q3. Why is create excluded from the list of the grant management actions?

It was missed.

Agree with the following text:

The AS will return a grant_id if the authorization request includes grant_management_action.

We have discussed also an additional parameter to the token request for client to indicate that they require grant_id to be issued.

[Torsten Lodderstedt]

I would lean towards making issuance of a grant id in case the client requested grant management action create a MUST, which would turn the answer to Q2 to “No”.

The reason for proposing the new token response parameter is mainly migration scenarios, where the client first need to pick up the pre-existing grant id in order to be able to later update, replace, query, revoke it.

[Dima Postnikov]

I removed Q2 answer, because the question can be interpreted in multiple ways. Out proposed text should clarify it either way.

[Takahiko Kawasaki]

I noticed that a grant ID should not be issued to public clients because “5.1. Requirements for Authorization Servers” says “Grant management is restricted to confidential only clients due to security reasons.”

If an authorization server implementation which supports Grant Management must always issue a grant ID regardless of whether the grant_management_action request parameter is given or not, the server cannot support public clients. To be exact, if the server supported public clients, its behavior (“always issue a grant ID”) would become logically strange.

Possible options would be:

1. a grant ID should not be issued if the grant_management_action request parameter is not given.
2. a grant ID should be always issued regardless of whether the grant_management_action request parameter is given or not if (a) the server supports Grant Management AND (b) the client type of the client is “confidential”.

The first option is intuitively understandable and straightforward for both AS implementers and RP developers.

‌

[Dima Postnikov]

unless there are objections I will update the spec to: a grant ID should not be issued if the grant_management_action request parameter is not given

[Dima Postnikov]

Raised a pull request: https://bitbucket.org/openid/fapi/pull-requests/294

[Nat Sakimura]

Fixed #445.

Merged in Dima-Postnikov/specify-if-grant-id-should-be-issued-if--1637161957736 (pull request #294)

Conditions for grant ID issuance

Approved-by: Torsten Lodderstedt Approved-by: Takahiko Kawasaki Approved-by: Stuart Low

→ <<cset 1ddff0715df5>>