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.
SKFS Policies contain an MDS section that defines authenticator status behaviors:
"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"
}]
}
When checking, SKFS looks for the authenticator status object from the MDS; based on the status, it will check the current FIDO policy and act accordingly. It can either ignore, deny, or accept the request.
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.