-
Notifications
You must be signed in to change notification settings - Fork 19
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
chore: c_nonce is recommended and AS takes care #323
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO c_nonce from the AS's token endpoint shouldn't even be an option and, while there wasn't enough consensus to remove it*, I'm absolutely not okay recommending it.
How about adding this recommendation for the |
if the point of this PR is to recommend the usage of c_nonce in general (regardless of how the issuer provides c_nocne), the specification right now actually intends to mandate c_nonce (either from the token endpoint or credential endpoint).... i am inclined to close this issue until there is more clarity on the issues including #331 |
with the discussion in #331, the direction is to remove an option to return c_nonce from the token endpoint |
This PR aims to resolve the issue #313 where @andprian expressed her sensibility about some details that amtters about the security and the behaviour that an implementer may expect from the AS.
This PR does not address the revocation of a credential when a request for the same credential type occurs. As noted in the related issue, this behavior may be influenced by various factors outside the scope of this specification, including legal requirements already mentioned.