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.

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

Reuse Credential Offer identifier from metadata in authorization_details Authorization Request parameter #102

Closed
paulbastian opened this issue Nov 6, 2023 · 6 comments · Fixed by #137

Comments

@paulbastian
Copy link
Contributor

During IETF Prague, discussion came up to reuse the identifier used in Credential Offer that was introduced with #86 in the Authorization Request with authorization_details, e.g.:

[
   {
      "type": "openid_credential",
      "credential_description": "UniversityDegreeCredential"
   }
]
@Sakurann Sakurann changed the title Reuse Credential Offer idenfitier from metadata in Authorization Request Reuse Credential Offer identifier from metadata in authorization_details Authorization Request parameter Nov 6, 2023
@tlodderstedt
Copy link
Collaborator

I think this makes sense. We should have done this when we introduced the credential identifiers.

@markuskreusch
Copy link

From an implementation perspective this seems reasonable. I so far preferred the scope over the authorization details because it was a single identifier that could reference the credential in the metadata. With this approach the same is possible but in a more concise way and without the need for a scope per credential.

Especially with SD-JWTs there could be some confusion of the type used here for the authorization_details with the credentials_supported array in the issuer metadata, where each supported SD-JWT has a type as well. As far as I understood this will be called vct in the future and thus be distinguishable from each other. JWT VCs have types as well. The spec could stress, that this is a different type.

@Sakurann
Copy link
Collaborator

agreed this makes sense. looks like ready for PR

@paulbastian
Copy link
Contributor Author

@tlodderstedt @Sakurann so you see this as an optional alternative or the only way to use authorisation details?

@Sakurann
Copy link
Collaborator

Sakurann commented Dec 7, 2023

I would say the only way.

@paulbastian
Copy link
Contributor Author

That's also my perception. Is it ready for PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants