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

does anyone use response_type=code with OID4VP? #241

Open
jogu opened this issue Sep 1, 2024 · 2 comments
Open

does anyone use response_type=code with OID4VP? #241

jogu opened this issue Sep 1, 2024 · 2 comments

Comments

@jogu
Copy link
Collaborator

jogu commented Sep 1, 2024

https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html#name-response says:

If the Response Type value is code (Authorization Code Grant Type), the VP Token is provided in the Token Response.

(and has a similar entry in the table)

Does anyone actually do this? If not we should probably remove it from the spec, it feels like it might be an unnecessary complication. I'm not sure it's actually fully defined either, e.g. there's no mechanism defined for a client using the x509_san_dns client_id_scheme to actually authenticate at the token endpoint.

(If people are actually using it then the conformance tests might need to support it, they don't currently.)

@Sakurann
Copy link
Collaborator

I don't think we need support for this in the conformance tests, yet. but it also feels premature to remove this. we don't know if wallets will only be native apps and more wallets seem to be using servers for one purpose or the other.

@jogu
Copy link
Collaborator Author

jogu commented Sep 26, 2024

We should almost certainly do one of:

  1. Remove it, or
  2. Fix it so it's clear how you would implement it for the various client id schemes, e.g. how you use x509_san_dns at the token endpoint
  3. Document that it doesn't work for some client id schemes.

If no one is actually using it (which seems likely given people haven't ask questions about how you'd do it with the client id schemes) I believe it would be better to remove it, so we can add it back later when we do have people that use it.

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

No branches or pull requests

2 participants