make credential_identifiers mandatory for authorization_details flow

[paulbastian]

Closes #294

• make credential_identifiers mandatory in credential request for RAR (can still use format/credential_config_id in authorization req)
• enable returning credential_identifiers from the token endpoint for Pre-Auth Code Flow when RAR is used
• enable authorization_details with credential_configuration_id in Token Request for Pre-Auth Code Flow (already enabled by RAR)
• discuss whether to enable credential_identifiers for non-authorization_details flow as well or pit this to separate PR

There is a separate discussion to make credential_identfiiers available to scope flow as well, I would try to keep the discussion separate from this PR

[peppelinux]

small passionate editorials

[peppelinux]

Credential Issuers MAY allow the request for authorization to issue a specific Credential using the authorization_details parameter.

[Sakurann]

Suggested change

	Credential Issuers MAY support requesting authorization to issue a Credential using the authorization_details parameter.
	Credential Issuers MAY support requesting authorization to issue a Credential using the `authorization_details` parameter.

[peppelinux]

Suggested change

* `format`: REQUIRED if the `credential_identifiers` parameter was not returned from the Token Response. It MUST NOT be used otherwise. String that determines the format of the Credential to be issued, which may determine the type and any other information related to the Credential to be issued. Credential Format Profiles consist of the Credential format specific parameters that are defined in (#format-profiles). When this parameter is used, the `credential_identifier` Credential Request parameter MUST NOT be present.

* `format`: REQUIRED if `credential_identifiers` was not returned in the Token Response. It MUST NOT be used otherwise. This string specifies the format of the Credential to be issued, including type and related details. Credential Format Profiles, which detail format-specific parameters, are defined in (#format-profiles). When using this parameter, `credential_identifier` MUST NOT be present in the Credential Request.

[Sakurann]

can we please stick to REQUIRED when or REQUIRED if throughout the specification text?

[Sakurann]

I would like to see this point made clearer (made suggestions):

3: enable authorization_details with credential_configuration_id in Token Request for Pre-Auth Code Flow (already enabled by RAR)

[David-Chadwick]

Subject to minor editorials

[TakahikoKawasaki]

How does a user approve the value of the authorization_details request parameter in a token request?

For example, when a client application makes an authorization request without the authorization_details request parameter but includes the authorization_details request parameter with {"type":"openid_credential",...} in the subsequent token request, should the authorization server issue an access token that can be used for verifiable credential issuance? If the authorization server issues such an access token in this case, client applications can obtain an access token with arbitrary authorization_details without user approval.

[jogu]

How does a user approve the value of the authorization_details request parameter in a token request?

For example, when a client application makes an authorization request without the authorization_details request parameter but includes the authorization_details request parameter with {"type":"openid_credential",...} in the subsequent token request, should the authorization server issue an access token that can be used for verifiable credential issuance? If the authorization server issues such an access token in this case, client applications can obtain an access token with arbitrary authorization_details without user approval.

My understanding is the authorization server should return an access token with no more than the permissions that were already granted. The mechanism shouldn't be used to obtain new permissions without user approval.

[paulbastian]

How does a user approve the value of the authorization_details request parameter in a token request?
For example, when a client application makes an authorization request without the authorization_details request parameter but includes the authorization_details request parameter with {"type":"openid_credential",...} in the subsequent token request, should the authorization server issue an access token that can be used for verifiable credential issuance? If the authorization server issues such an access token in this case, client applications can obtain an access token with arbitrary authorization_details without user approval.

My understanding is the authorization server should return an access token with no more than the permissions that were already granted. The mechanism shouldn't be used to obtain new permissions without user approval.

That's my view as well, authorization_details in Token Request is only really applicable to PreAuthCode Flow.

[jogu]

We discussed this PR on today's WG call and seemed to have consensus that this was good to merge once the two suggestions I posted above are applied (and the git conflicts fixed!).

[paulbastian]

PR was discussed at latest DCP WG Call, I made the proposed changes and PR is ready from my side

[jogu]

3 approvals, open for over a week, all comments addressed, discussed on last week's wg call - merging!