Accept scoped PIN tokens for EnumerateCredentialsBegin #82
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As described in #80, we currently require PIN tokens without an RP ID restriction for all credential management operations. For most operations, this is correct.
For EnumerateCredentialsBegin, we should also accept a token that matches the requested RP ID hash. For DeleteCredential and UpdateUserInformation, we should also accept a token that matches the requested credential ID. As it is not trivial to compare the RP ID hash or the credential ID against the RP ID set for the PIN token, I did not handle these cases in the initial implementation.
This led to an incompatibility with libfido2 because it tries to use a restricted PIN token to enumerate credentials. With this patch, we additionally compute the RP ID hash when restricting a PIN token to an RP ID and use that to validate the PIN token for
EnumerateCredentialsBegin operations.
For DeleteCredential and UpdateUserInformation, we still require tokens without an RP ID restriction because determining the RP ID from the credential ID is much harder and this is not known to cause incompatibility issues.
See also: #80