FIDO Server now enables the use of the FIDO MetaDataService (MDS) 3.x. SKFS is configured to automatically download FIDO MDS and load it in memory at regular intervals. It is governed by the following properties (shown with default values):
SKFS attempts to download the MDS every day and checks if there is an update. If there is an update, then it parses the full MDS and loads up all the statements in memory.
Below is an example of the full SKFS Policy MDS JSON section; the SKFS Policy MDS section defines authenticator status behaviors and MDS certificate check resolutions:
"mds": {
"authenticatorStatusReport": [
{
"status": "FIDO_CERTIFIED_L1",
"priority": "1",
"decision": "IGNORE"
},
{
"status": "FIDO_CERTIFIED_L2",
"priority": "1",
"decision": "ACCEPT"
},
{
"status": "UPDATE_AVAILABLE",
"priority": "5",
"decision": "IGNORE"
},
{
"status": "REVOKED",
"priority": "10",
"decision": "DENY"
}],
"checkResolutions": {
"enabled": true,
"noAaguidInMds": "ACCEPT",
"hasX5c": {
"hasMdsAttestation": {
"invalidPkix": "DENY"
},
"noMdsAttestation": {
"invalidPkix": "DENY"
}
},
"noX5c": {
"hasMdsAttestation": {
"formatNone": "DENY",
"formatPacked": "DENY"
},
"noMdsAttestation": "ACCEPT"
}
}
}
As of 4.4.3, MDS is only configured to work with packed attestation.
SKFS uses a property to determine whether to just ignore MDS for an aaguid that doesn't exist in the official FIDO Alliance MDS, or deny those requests. By default the server ignores MDS checks if it doesn't find the aaguid in the official list.
This is because the MDS is evolving. StrongKey will evolve accordingly.
The metadata statement is only stored in memory and not permanently stored in any database. There is no provision to return the MDS in the getKeysinfo web service.