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.
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: https://github.com/Nitrokey/fido-authenticator/issues/80