The spec states:
https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#ServiceInfo
The ServiceInfo key is the module name and the message name, separated by a colon.
…
ServiceInfo uses key-value pairs. A ServiceInfo key is a module name and a message name:
moduleName:messageName
In the following fsim all the messages are defined with just “.” and no “:” (except for fdo.command which correctly uses a “:”)
fdo-sim/fsim-repository/fdo.command.md (correct)
- ['fdo.command:active', True] Module is active
- ['fdo.command:command', 'sh'] Indicates shell to use
- ['fdo.command:return_stdout, True] send stdout in reverse message
- ['fdo.command:return_stderr, False] do not send stderr (swallow it)
- ['fdo.command:may_fail', True] failure of command does not cause TO2 to fail
- ['fdo.command:args', bstr .cbor *1] request (short) list of file systems. Invokes command.
- ['fdo.commmand:execute, bstr .cbor Null] Invoke command
['fdo.command:stdout', *2] - stdout from invoked command 1
['fdo.command:stdout', *3] - more stdout from invoked command 1
['fdo.command:exitcode', 0] -
All other fsims don’t use the : convention but instead just contain “dots”. I think this is because we said the module would match Java namespace conventions. However, we now don’t have a way to parse the modulename from the message being received.
fdo-sim/fsim-repository/fdo.csr.md (no “:” but “.” instead)
Direction Key Name Value Meaning
o <-> d fdo.csr.active bool Instructs the device to activate or deactivate the module
o <-- d fdo.csr.cacerts-req uint Request to obtain CA certificates
o --> d fdo.csr.cacerts-res tstr CA certificates
o <-- d fdo.csr.simpleenroll-req tstr Certificate enrollment request
o --> d fdo.csr.simpleenroll-res tstr Enrollments of clients
o <-- d fdo.csr.simplereenroll-req tstr Request to re-enroll a client
o --> d fdo.csr.simplereenroll-res tstr Re-enrollment response
o <-- d fdo.csr.serverkeygen-req tstr Request for server-side key generation
o --> d fdo.csr.serverkeygen-res tstr Certificate and private key
o <-- d fdo.csr.csrattrs-req uint Request for CSR attributes
o --> d fdo.csr.csrattrs-res tstr CSR attributes
o --> d fdo.csr.error uint Error Indication
The spec states:
https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#ServiceInfo
The ServiceInfo key is the module name and the message name, separated by a colon.
…
ServiceInfo uses key-value pairs. A ServiceInfo key is a module name and a message name:
moduleName:messageName
In the following fsim all the messages are defined with just “.” and no “:” (except for fdo.command which correctly uses a “:”)
fdo-sim/fsim-repository/fdo.command.md (correct)
['fdo.command:stdout', *2] - stdout from invoked command 1
['fdo.command:stdout', *3] - more stdout from invoked command 1
['fdo.command:exitcode', 0] -
All other fsims don’t use the : convention but instead just contain “dots”. I think this is because we said the module would match Java namespace conventions. However, we now don’t have a way to parse the modulename from the message being received.
fdo-sim/fsim-repository/fdo.csr.md (no “:” but “.” instead)
Direction Key Name Value Meaning
o <-> d fdo.csr.active bool Instructs the device to activate or deactivate the module
o <-- d fdo.csr.cacerts-req uint Request to obtain CA certificates
o --> d fdo.csr.cacerts-res tstr CA certificates
o <-- d fdo.csr.simpleenroll-req tstr Certificate enrollment request
o --> d fdo.csr.simpleenroll-res tstr Enrollments of clients
o <-- d fdo.csr.simplereenroll-req tstr Request to re-enroll a client
o --> d fdo.csr.simplereenroll-res tstr Re-enrollment response
o <-- d fdo.csr.serverkeygen-req tstr Request for server-side key generation
o --> d fdo.csr.serverkeygen-res tstr Certificate and private key
o <-- d fdo.csr.csrattrs-req uint Request for CSR attributes
o --> d fdo.csr.csrattrs-res tstr CSR attributes
o --> d fdo.csr.error uint Error Indication