Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

make credential_identifiers mandatory for authorization_details flow #346

Merged
merged 12 commits into from
Jul 10, 2024
Merged

make credential_identifiers mandatory for authorization_details flow #346

merged 12 commits into from
Jul 10, 2024

Conversation

paulbastian
Copy link
Contributor

@paulbastian paulbastian commented Jun 12, 2024 •
edited
Loading

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

@paulbastian paulbastian linked an issue Jun 12, 2024 that may be closed by this pull request
Potential improvements for the big picture of issuance flows #294
Closed
peppelinux
peppelinux approved these changes Jun 13, 2024
View reviewed changes
Copy link
Member

@peppelinux peppelinux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small passionate editorials

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved
openid-4-verifiable-credential-issuance-1_0.md Show resolved Hide resolved
openid-4-verifiable-credential-issuance-1_0.md Outdated
@@ -611,6 +611,12 @@ grant_type=authorization_code
&client_assertion=eyJhbGciOiJSU...
```

### Request Issuance of a Certain Credential using authorization_details Parameter

Credential Issuers MAY support requesting authorization to issue a Credential using the authorization_details parameter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved
openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved
openid-4-verifiable-credential-issuance-1_0.md Outdated
@@ -721,8 +729,8 @@ For cryptographic binding, the Client has the following options defined in (#cre

A Client makes a Credential Request to the Credential Endpoint by sending the following parameters in the entity-body of an HTTP POST request using the `application/json` media type.

* `format`: REQUIRED when the `credential_identifiers` parameter was not returned from the Token Response. It MUST NOT be used otherwise. It is a 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.
* `credential_identifier`: REQUIRED when `credential_identifiers` parameter was returned from the Token Response. It MUST NOT be used otherwise. It is a String that identifies a Credential that is being requested to be issued. When this parameter is used, the `format` parameter and any other Credential format specific parameters such as those defined in (#format-profiles) MUST NOT be present.
* `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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Sakurann reviewed Jun 17, 2024
View reviewed changes
openid-4-verifiable-credential-issuance-1_0.md Outdated
@@ -721,8 +729,8 @@ For cryptographic binding, the Client has the following options defined in (#cre

A Client makes a Credential Request to the Credential Endpoint by sending the following parameters in the entity-body of an HTTP POST request using the `application/json` media type.

* `format`: REQUIRED when the `credential_identifiers` parameter was not returned from the Token Response. It MUST NOT be used otherwise. It is a 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.
* `credential_identifier`: REQUIRED when `credential_identifiers` parameter was returned from the Token Response. It MUST NOT be used otherwise. It is a String that identifies a Credential that is being requested to be issued. When this parameter is used, the `format` parameter and any other Credential format specific parameters such as those defined in (#format-profiles) MUST NOT be present.
* `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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sakurann
Sakurann reviewed Jun 17, 2024
View reviewed changes
Copy link
Collaborator

@Sakurann Sakurann left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@Sakurann Sakurann mentioned this pull request Jun 17, 2024
Closed
@Sakurann Sakurann requested review from pmhsfelix and bc-pi June 20, 2024 15:48
@jogu jogu requested a review from David-Chadwick June 27, 2024 15:27
David-Chadwick
David-Chadwick approved these changes Jun 27, 2024
View reviewed changes
Copy link
Contributor

@David-Chadwick David-Chadwick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subject to minor editorials

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved
openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved
openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved
@TakahikoKawasaki
Copy link

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.

@TakahikoKawasaki TakahikoKawasaki mentioned this pull request Jul 2, 2024
Closed
@jogu
Copy link
Contributor

jogu commented Jul 4, 2024

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
Copy link
Contributor Author

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.

@paulbastian @peppelinux @David-Chadwick
Apply suggestions from code review
c283425 
Co-authored-by: Giuseppe De Marco <[email protected]>
Co-authored-by: David Chadwick <[email protected]>
@jogu
Copy link
Contributor

jogu commented Jul 4, 2024

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
Copy link
Contributor Author

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

@jogu
Copy link
Contributor

jogu commented Jul 10, 2024

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

@jogu jogu merged commit 0e01ec5 into main Jul 10, 2024
2 checks passed
@TimoGlastra TimoGlastra mentioned this pull request Jul 19, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@peppelinux peppelinux peppelinux approved these changes

@jogu jogu jogu approved these changes

@David-Chadwick David-Chadwick David-Chadwick approved these changes

@Sakurann Sakurann Awaiting requested review from Sakurann

@decentralgabe decentralgabe Awaiting requested review from decentralgabe

@pmhsfelix pmhsfelix Awaiting requested review from pmhsfelix

@bc-pi bc-pi Awaiting requested review from bc-pi

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Potential improvements for the big picture of issuance flows
6 participants
@paulbastian @TakahikoKawasaki @jogu @peppelinux @David-Chadwick @Sakurann