FIDO UAF Registry of Predefined Values
FIDO Alliance Proposed Standard
- This version:
- https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-reg-v1.0-ps-20141208.html
- Previous version:
- https://fidoalliance.org/specs/fido-uaf-reg-v1.0-rd-20141008.pdf
- Editors:
- Dr. Rolf Lindemann, Nok Nok Labs, Inc.
- Davit Baghdasaryan, Nok Nok Labs, Inc.
- Brad Hill, PayPal
The English version of this specification is the only normative version. Non-normative translations may also be available.
Copyright © 2013-2014 FIDO Alliance All Rights Reserved.
Abstract
This document defines all the strings and constants reserved by UAF protocols. The values defined in this document are referenced by various UAF specifications.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current FIDO Alliance publications and the latest revision of this technical report can be found in the FIDO Alliance specifications index at https://www.fidoalliance.org/specifications/.
This document was published by the FIDO Alliance as a Proposed Standard. If you wish to make comments regarding this document, please Contact Us. All comments are welcome.
Implementation of certain elements of this Specification may require licenses under third party intellectual property rights, including without limitation, patent rights. The FIDO Alliance, Inc. and its Members and any other contributors to the Specification are not, and shall not be held, responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.
THIS FIDO ALLIANCE SPECIFICATION IS PROVIDED “AS IS” AND WITHOUT ANY WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY EXPRESS OR IMPLIED WARRANTY OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document has been reviewed by FIDO Aliance Members and is endorsed as a Proposed Standard. It is a stable document and may be used as reference material or cited from another document. FIDO Alliance's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.
Table of Contents
1. Notation
Type names, attribute names and element names are written as code
.
String literals are enclosed in “”, e.g. “UAF-TLV”.
In formulas we use “|” to denote byte wise concatenation operations.
UAF specific terminology used in this document is defined in [FIDOGlossary].
All diagrams, examples, notes in this specification are non-normative.
1.1 Key Words
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
2. Overview
This section is non-normative.
This document defines the registry of UAF-specific constants that are used and referenced in various UAF specifications. It is expected that, over time, new constants will be added to this registry. For example new authentication algorithms and new types of authenticator characteristics will require new constants to be defined for use within the specifications.
3. Authenticator Characteristics
This section is normative.
3.1 User Verification Methods
The USER_VERIFY
constants are flags in a bitfield represented as a 32 bit long integer. They describe the methods and capabilities of an UAF authenticator for locally verifying a user. The operational details of these methods are opaque to the server. These constants are used in the authoritative metadata for an authenticator, reported and queried through the UAF Discovery APIs, and used to form authenticator policies in UAF protocol messages.
All user verification methods must be performed locally by the authenticator in order to meet FIDO privacy principles.
USER_VERIFY_PRESENCE
0x01
- This flag MUST be set if the authenticator is able to confirm user presence in any fashion. If this flag and no other is set for user verification, the guarantee is only that the authenticator cannot be operated without some human intervention, not necessarily that the presence verification provides any level of authentication of the human's identity. (e.g. a device that requires a touch to activate)
USER_VERIFY_FINGERPRINT
0x02
- This flag MUST be set if the authenticator uses any type of measurement of a fingerprint for user verification.
USER_VERIFY_PASSCODE
0x04
- This flag MUST be set if the authenticator uses a local-only passcode (i.e. a passcode not known by the server) for user verification.
USER_VERIFY_VOICEPRINT
0x08
- This flag MUST be set if the authenticator uses a voiceprint (also known as speaker recognition) for user verification.
USER_VERIFY_FACEPRINT
0x10
- This flag MUST be set if the authenticator uses any manner of face recognition to verify the user.
USER_VERIFY_LOCATION
0x20
- This flag MUST be set if the authenticator uses any form of location sensor or measurement for user verification.
USER_VERIFY_EYEPRINT
0x40
- This flag MUST be set if the authenticator uses any form of eye biometrics for user verification.
USER_VERIFY_PATTERN
0x80
- This flag MUST be set if the authenticator uses a drawn pattern for user verification.
USER_VERIFY_HANDPRINT
0x100
- This flag MUST be set if the authenticator uses any measurement of a full hand (including palm-print, hand geometry or vein geometry) for user verification.
USER_VERIFY_NONE
0x200
- This flag MUST be set if the authenticator will respond without any user interaction (e.g. Silent Authenticator).
USER_VERIFY_ALL
0x400
- If an authenticator sets multiple flags for user verification types, it MAY also set this flag to indicate that all verification methods will be enforced (e.g. faceprint AND voiceprint). If flags for multiple user verification methods are set and this flag is not set, verification with only one is necessary (e.g. fingerprint OR passcode).
3.2 Key Protection Types
The KEY_PROTECTION
constants are flags in a bit field represented as a 16 bit long integer. They describe the method an authenticator uses to protect the private key material for FIDO registrations. Refer to [UAFAuthnrCommands] for more details on the relevance of keys and key protection. These constants are used in the authoritative metadata for an authenticator, reported and queried through the UAF Discovery APIs, and used to form authenticator policies in UAF protocol messages.
When used in metadata describing an authenticator, several of these flags are exclusive of others (i.e. can not be combined) - the certified metadata may have at most one of the mutually exclusive bits set to 1. When used in authenticator policy, any bit may be set to 1, e.g. to indicate that a server is willing to accept authenticators using either KEY_PROTECTION_SOFTWARE
or KEY_PROTECTION_HARDWARE
.
Note
These flags must be set according to the effective security of the keys, in order to follow the assumptions made in [FIDOSecRef]. For example, if a key is stored in a secure element but software running on the FIDO User Device could call a function in the secure element to export the key either in the clear or using an arbitrary wrapping key, then the effective security is KEY_PROTECTION_SOFTWARE
and not KEY_PROTECTION_SECURE_ELEMENT
.
KEY_PROTECTION_SOFTWARE
0x01
- This flag MUST be set if the authenticator uses software-based key management. Exclusive in authenticator metadata with
KEY_PROTECTION_HARDWARE
,KEY_PROTECTION_TEE
,KEY_PROTECTION_SECURE_ELEMENT
KEY_PROTECTION_HARDWARE
0x02
- This flag SHOULD be set if the authenticator uses hardware-based key management. Exclusive in authenticator metadata with
KEY_PROTECTION_SOFTWARE
KEY_PROTECTION_TEE
0x04
- This flag SHOULD be set if the authenticator uses the Trusted Execution Environment [TEE] for key management. In authenticator metadata, this flag should be set in conjunction with
KEY_PROTECTION_HARDWARE
. Exclusive in authenticator metadata withKEY_PROTECTION_SOFTWARE
,KEY_PROTECTION_SECURE_ELEMENT
KEY_PROTECTION_SECURE_ELEMENT
0x08
- This flag SHOULD be set if the authenticator uses a Secure Element [SecureElement] for key management. In authenticator metadata, this flag should be set in conjunction with
KEY_PROTECTION_HARDWARE
. Exclusive in authenticator metadata withKEY_PROTECTION_TEE
,KEY_PROTECTION_SOFTWARE
KEY_PROTECTION_REMOTE_HANDLE
0x10
- This flag MUST be set if the authenticator does not store (wrapped) UAuth keys at the client, but relies on a server-provided key handle. This flag MUST be set in conjunction with one of the other
KEY_PROTECTION
flags to indicate how the local key handle wrapping key and operations are protected. Servers MAY unset this flag in authenticator policy if they are not prepared to store and return key handles, for example, if they have a requirement to respond indistinguishably to authentication attempts against userIDs that do and do not exist. Refer to [UAFProtocol] for more details.
3.3 Matcher Protection Types
The MATCHER_PROTECTION
constants are flags in a bit field represented as a 16 bit long integer. They describe the method an authenticator uses to protect the matcher that performs user verification. These constants are used in the authoritative metadata for an authenticator, reported and queried through the UAF Discovery APIs, and used to form authenticator policies in UAF protocol messages. Refer to [UAFAuthnrCommands] for more details on the matcher component.
Note
These flags must be set according to the effective security of the matcher, in order to follow the assumptions made in [FIDOSecRef]. For example, if a passcode based matcher is implemented in a secure element, but the passcode is expected to be provided as unauthenticated parameter, then the effective security is MATCHER_PROTECTION_SOFTWARE
and not MATCHER_PROTECTION_ON_CHIP
.
MATCHER_PROTECTION_SOFTWARE
0x01
- This flag MUST be set if the authenticator's matcher is running in software. Exclusive in authenticator metadata with
MATCHER_PROTECTION_TEE
,MATCHER_PROTECTION_ON_CHIP
MATCHER_PROTECTION_TEE
0x02
- This flag SHOULD be set if the authenticator's matcher is running inside the Trusted Execution Environment [TEE]. Exclusive in authenticator metadata with
MATCHER_PROTECTION_SOFTWARE
,MATCHER_PROTECTION_ON_CHIP
MATCHER_PROTECTION_ON_CHIP
0x04
- This flag SHOULD be set if the authenticator's matcher is running on the chip. Exclusive in authenticator metadata with
MATCHER_PROTECTION_TEE
,MATCHER_PROTECTION_SOFTWARE
3.4 Authenticator Attachment Hints
The ATTACHMENT_HINT
constants are flags in a bit field represented as a 32 bit long. They describe the method an authenticator uses to communicate with the FIDO User Device. These constants are reported and queried through the UAF Discovery APIs [UAFAppAPIAndTransport], and used to form Authenticator policies in UAF protocol messages. Because the connection state and topology of an authenticator may be transient, these values are only hints that can be used by server-supplied policy to guide the user experience, e.g. to prefer a device that is connected and ready for authenticating or confirming a low-value transaction, rather than one that is more secure but requires more user effort.
Note
These flags are not a mandatory part of authenticator metadata and, when present, only indicate possible states that may be reported during authenticator discovery.
ATTACHMENT_HINT_INTERNAL
0x01
- This flag MAY be set to indicate that the authenticator is permanently attached to the FIDO User Device. A device such as a smartphone may have authenticator functionality that is able to be used both locally and remotely. In such a case, the FIDO client MUST filter and exclusively report only the relevant bit during Discovery and when performing policy matching.
This flag cannot be combined with any other ATTACHMENT_HINT
flags.
ATTACHMENT_HINT_EXTERNAL
0x02
This flag MAY be set to indicate, for a hardware-based authenticator, that it is removable or remote from the FIDO User Device. A device such as a smartphone may have authenticator functionality that is able to be used both locally and remotely. In such a case, the FIDO UAF Client MUST filter and exclusively report only the relevant bit during discovery and when performing policy matching.
ATTACHMENT_HINT_WIRED
0x04
- This flag MAY be set to indicate that an external authenticator currently has an exclusive wired connection, e.g. through USB, Firewire or similar, to the FIDO User Device.
ATTACHMENT_HINT_WIRELESS
0x08
- This flag MAY be set to indicate that an external authenticator communicates with the FIDO User Device through a personal area or otherwise non-routed wireless protocol, such as Bluetooth or NFC.
ATTACHMENT_HINT_NFC
0x10
- This flag MAY be set to indicate that an external authenticator is able to communicate by NFC to the FIDO User Device. As part of authenticator metadata, or when reporting characteristics through discovery, if this flag is set, the
ATTACHMENT_HINT_WIRELESS
flag SHOULD also be set as well. ATTACHMENT_HINT_BLUETOOTH
0x20
- This flag MAY be set to indicate that an external authenticator is able to communicate using Bluetooth with the FIDO User Device. As part of authenticator metadata, or when reporting characteristics through discovery, if this flag is set, the
ATTACHMENT_HINT_WIRELESS
flag SHOULD also be set. ATTACHMENT_HINT_NETWORK
0x40
- This flag MAY be set to indicate that the authenticator is connected to the FIDO User Device ver a non-exclusive network (e.g. over a TCP/IP LAN or WAN, as opposed to a PAN or point-to-point connection).
ATTACHMENT_HINT_READY
0x80
- Thif flag MAY be set to indicate that an external authenticator is in a "ready" state. This flag is set by the ASM at its discretion.
Note
Generally this should indicate that the device is immediately available to perform user verification without additional actions such as connecting the device or creating a new biometric profile enrollment, but the exact meaning may vary for different types of devices. For example, a USB authenticator may only report itself as ready when it is plugged in, or a Bluetooth authenticator when it is paired and connected, but an NFC-based authenticator may always report itself as ready.
ATTACHMENT_HINT_WIFI_DIRECT
0x100
- This flag MAY be set to indicate that an external authenticator is able to communicate using WiFi Direct with the FIDO User Device. As part of authenticator metadata and when reporting characteristics through discovery, if this flag is set, the
ATTACHMENT_HINT_WIRELESS
flag SHOULD also be set.
3.5 Transaction Confirmation Display Types
The TRANSACTION_CONFIRMATION_DISPLAY
constants are flags in a bit field represented as a 16 bit long integer. They describe the availability and implementation of a transaction confirmation display capability required for the transaction confirmation operation. These constants are used in the authoritative metadata for an authenticator, reported and queried through the UAF Discovery APIs, and used to form authenticator policies in UAF protocol messages. Refer to [UAFAuthnrCommands] for more details on the security aspects of TransactionConfirmation Display.
TRANSACTION_CONFIRMATION_DISPLAY_ANY
0x01
- This flag MUST be set to indicate, that some form of transaction confirmation display is available on this authenticator.
TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE
0x02
- This flag MUST be set to indicate, that a software-based transaction confirmation display operating in a privileged context is available on this authenticator.
A FIDO client that is capable of providing this capability MAY set this bit for all authenticators of type
ATTACHMENT_HINT_INTERNAL
, even if the authoritative metadata for the authenticator does not indicate this capability.
Note
Software based transaction confirmation displays might be implemented within the boundaries of the ASM rather than by the authenticator itself [UAFASM].
TRANSACTION_CONFIRMATION_DISPLAY_TEE
0x04
- This flag SHOULD be set to indicate that the authenticator implements a transaction confirmation display in a Trusted Execution Environment ([TEE], [TEESecureDisplay]).
TRANSACTION_CONFIRMATION_DISPLAY_HARDWARE
0x08
- This flag SHOULD be set to indicate that a transaction confirmation display based on hardware assisted capabilities is available on this authenticator.
TRANSACTION_CONFIRMATION_DISPLAY_REMOTE
0x10
- This flag SHOULD be set to indicate that the transaction confirmation display is provided on a distinct device from the FIDO User Device.
3.6 Tags used for crypto algorithms and types
These tags indicate the specific authentication algorithms, public key formats and other crypto relevant data.
3.6.1 Authentication Algorithms
The UAF_ALG_SIGN
constants are 16 bit long integers indicating the specific signature algorithm and encoding.
Note
FIDO UAF supports RAW and DER signature encodings in order to allow small footprint authenticator implementations.
UAF_ALG_SIGN_SECP256R1_ECDSA_SHA256_RAW
0x01
An ECDSA signature on the NIST secp256r1 curve which MUST have raw R and S buffers, encoded in big-endian order. I.e.
[R (32 bytes), S (32 bytes)]
UAF_ALG_SIGN_SECP256R1_ECDSA_SHA256_DER
0x02
DER [ITU-X690-2008] encoded ECDSA signature [RFC5480] on the NIST secp256r1 curve. I.e. a DER encoded
SEQUENCE { r INTEGER, s INTEGER }
UAF_ALG_SIGN_RSASSA_PSS_SHA256_RAW
0x03
RSASSA-PSS [RFC3447] signature MUST have raw S buffers, encoded in big-endian order [RFC4055] [RFC4056]. The default parameters as specified in [RFC4055] MUST be assumed, i.e.
- Mask Generation Algorithm MGF1 with SHA256
- Salt Length of 32 bytes, i.e. the length of a SHA256 hash value.
- Trailer Field value of 1, which represents the trailer field with hexadecimal value
0xBC
.
I.e.[ S (256 bytes) ]
UAF_ALG_SIGN_RSASSA_PSS_SHA256_DER
0x04
DER [ITU-X690-2008] encoded OCTET STRING (not BIT STRING!) containing the RSASSA-PSS [RFC3447] signature [RFC4055] [RFC4056]. The default parameters as specified in [RFC4055] MUST be assumed, i.e.
- Mask Generation Algorithm MGF1 with SHA256
- Salt Length of 32 bytes, i.e. the length of a SHA256 hash value.
- Trailer Field value of 1, which represents the trailer field with hexadecimal value
0xBC
.
I.e. a DER encodedOCTET STRING
(including its tag and length bytes).
UAF_ALG_SIGN_SECP256K1_ECDSA_SHA256_RAW
0x05
An ECDSA signature on the secp256k1 curve which MUST have raw R and S buffers, encoded in big-endian order. I.e.
[R (32 bytes), S (32 bytes)]
UAF_ALG_SIGN_SECP256K1_ECDSA_SHA256_DER
0x06
- DER [ITU-X690-2008] encoded ECDSA signature [RFC5480] on the secp256k1 curve.
I.e. a DER encoded
SEQUENCE { r INTEGER, s INTEGER }
3.6.2 Public Key Representation Formats
The UAF_ALG_KEY
constants are 16 bit long integers indicating the specific Public Key algorithm and encoding.
Note
FIDO UAF supports RAW and DER encodings in order to allow small footprint authenticator implementations. By definition, the authenticator must encode the public key as part of the registration assertion.
UAF_ALG_KEY_ECC_X962_RAW
0x100
Raw ANSI X9.62 formatted Elliptic Curve public key [SEC1]. I.e.
[0x04, X (32 bytes), Y (32 bytes)]
. Where the byte0x04
denotes the uncompressed point compression method.UAF_ALG_KEY_ECC_X962_DER
0x101
- DER [ITU-X690-2008] encoded ANSI X.9.62 formatted
SubjectPublicKeyInfo
[RFC5480] specifying an elliptic curve public key. I.e. a DER encodedSubjectPublicKeyInfo
as defined in [RFC5480].
Authenticator implementations MUST generate namedCurve
in the ECParameters
object which is included in the AlgorithmIdentifier
. A FIDO UAF Server MUST accept namedCurve
in the ECParameters
object which is included in the AlgorithmIdentifier
.
UAF_ALG_KEY_RSA_2048_PSS_RAW
0x102
Raw encoded RSASSA-PSS public key [RFC3447]. The default parameters according to [RFC4055] MUST be assumed, i.e.
- Mask Generation Algorithm MGF1 with SHA256
- Salt Length of 32 bytes, i.e. the length of a SHA256 hash value.
- Trailer Field value of 1, which represents the trailer field with hexadecimal value
0xBC
.
That is, [n (256 bytes), e (N-n bytes)]
. Where N
is the total length of the field.
This total length should be taken from the object containing this key, e.g. the TLV encoded field.
UAF_ALG_KEY_RSA_2048_PSS_DER
0x103
ASN.1 DER [ITU-X690-2008] encoded RSASSA-PSS [RFC3447] public key [RFC4055]. The default parameters according to [RFC4055] MUST be assumed, i.e.
- Mask Generation Algorithm MGF1 with SHA256
- Salt Length of 32 bytes, i.e. the length of a SHA256 hash value.
- Trailer Field value of 1, which represents the trailer field with hexadecimal value
0xBC
.
That is, a DER encoded SEQUENCE { n INTEGER, e INTEGER }
.
3.7 Assertion Schemes
Names of assertion schemes are strings with a length of 8 characters.
UAF TLV based assertion scheme “UAFV1TLV”
- This assertion scheme allows the authenticator and the FIDO Server to exchange an asymmetric authentication key generated by the authenticator. The authenticator MUST generate a key pair (UAuth.pub/UAuth.priv) to be used with algorithm suites listed in section Authentication Algorithms (with prefix
UAF_ALG
). This assertion scheme is using a compact Tag Length Value (TLV) encoding for the KRD and SignData messages generated by the authenticators. This is the default assertion scheme for the UAF protocol.
4. Predefined Tags
This section is normative.
The internal structure of UAF authenticator commands is a “Tag-Length-Value” (TLV) sequence. The tag is a 2-byte unique unsigned value describing the type of field the data represents, the length is a 2-byte unsigned value indicating the size of the value in bytes, and the value is the variable-sized series of bytes which contain data for this item in the sequence.
Although 2 bytes are allotted for the tag, only the first 14 bits (values up to 0x3FFF) should be used to accommodate the limitations of some hardware platforms.
A tag that has the 14th bit (0x2000) set indicates that it is critical and a receiver must abort processing the entire message if it cannot process that tag.
A tag that has the 13th bit (0x1000) set indicates a composite tag that can be parsed by recursive descent.
4.1 Tags used in the protocol
The following tags have been allocated for data types in UAF protocol messages:
TAG_UAFV1_REG_ASSERTION
0x3E01
- The content of this tag is the authenticator response to a Register command.
TAG_UAFV1_AUTH_ASSERTION
0x3E02
- The content of this tag is the authenticator response to a Sign command.
TAG_UAFV1_KRD
0x3E03
- Indicates Key Registration Data.
TAG_UAFV1_SIGNED_DATA
0x3E04
- Indicates data signed by the authenticator using UAuth.priv key.
TAG_ATTESTATION_CERT
0x2E05
- Indicates DER encoded attestation certificate.
TAG_SIGNATURE
0x2E06
- Indicates a cryptographic signature.
TAG_ATTESTATION_BASIC_FULL
0x3E07
- Indicates full basic attestation as defined in [UAFProtocol].
TAG_ATTESTATION_BASIC_SURROGATE
0x3E08
- Indicates surrogate basic attestation as defined in [UAFProtocol].
TAG_KEYID
0x2E09
- Represents a generated KeyID.
TAG_FINAL_CHALLENGE
0x2E0A
- Represents a generated final challenge as defined in [UAFProtocol].
TAG_AAID
0x2E0B
- Represents an Authenticator Attestation ID as defined in [UAFProtocol].
TAG_PUB_KEY
0x2E0C
- Represents a generated public key.
TAG_COUNTERS
0x2E0D
- Represents the use counters for an authenticator.
TAG_ASSERTION_INFO
0x2E0E
- Represents authenticator information necessary for message processing.
TAG_AUTHENTICATOR_NONCE
0x2E0F
- Represents a nonce value generated by the authenticator.
TAG_TRANSACTION_CONTENT_HASH
0x2E10
- Represents a hash of the transaction content sent to the authenticator.
TAG_EXTENSION
0x3E11, 0x3E12
- This is a composite tag indicating that the content is an extension.
TAG_EXTENSION_ID
0x2E13
- Represents extension ID. Content of this tag is a UINT8[] encoding of a UTF-8 string.
TAG_EXTENSION_DATA
0x2E14
- Represents extension data. Content of this tag is a UINT8[] byte array.
A. References
A.1 Normative references
- [FIDOGlossary]
- R. Lindemann, D. Baghdasaryan, B. Hill, J. Hodges, FIDO Technical Glossary. FIDO Alliance Proposed Standard. URLs:
HTML: fido-glossary-v1.0-ps-20141208.html
PDF: fido-glossary-v1.0-ps-20141208.pdf
- [ITU-X690-2008]
- X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), (T-REC-X.690-200811). International Telecommunications Union, November 2008 URL: http://www.itu.int/rec/T-REC-X.690-200811-I/en
- [RFC2119]
- S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
- [RFC3447]
- J. Jonsson; B. Kaliski. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. February 2003. Informational. URL: https://tools.ietf.org/html/rfc3447
- [RFC4055]
- J. Schaad; B. Kaliski; R. Housley. Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. June 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4055
- [RFC4056]
- J. Schaad. Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS). June 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4056
- [RFC5480]
- S. Turner; D. Brown; K. Yiu; R. Housley; T. Polk. Elliptic Curve Cryptography Subject Public Key Information. March 2009. Proposed Standard. URL: https://tools.ietf.org/html/rfc5480
- [SEC1]
- Standards for Efficient Cryptography Group (SECG), SEC1: Elliptic Curve Cryptography, Version 2.0, September 2000.
A.2 Informative references
- [FIDOSecRef]
- R. Lindemann, D. Baghdasaryan, B. Hill, FIDO Security Reference. FIDO Alliance Proposed Standard. URLs:
HTML: fido-security-ref-v1.0-ps-20141208.html
PDF: fido-security-ref-v1.0-ps-20141208.pdf
- [SecureElement]
- GlobalPlatform Card Specifications GlobalPlatform. Accessed March 2014. URL: https://www.globalplatform.org/specifications.asp
- [TEE]
- GlobalPlatform Trusted Execution Environment Specifications GlobalPlatform. Accessed March 2014. URL: https://www.globalplatform.org/specifications.asp
- [TEESecureDisplay]
- GlobalPlatform Trusted User Interface API Specifications GlobalPlatform. Accessed March 2014. URL: https://www.globalplatform.org/specifications.asp
- [UAFASM]
- D. Baghdasaryan, J. Kemp, R. Lindemann, B. Hill, R. Sasson, FIDO UAF Authenticator-Specific Module API. FIDO Alliance Proposed Standard. URLs:
HTML: fido-uaf-asm-api-v1.0-ps-20141208.html
PDF: fido-uaf-asm-api-v1.0-ps-20141208.pdf
- [UAFAppAPIAndTransport]
- B. Hill, D. Baghdasaryan, B. Blanke, FIDO UAF Application API and Transport Binding Specification. FIDO Alliance Proposed Standard. URLs:
HTML: fido-uaf-client-api-transport-v1.0-ps-20141208.html
PDF: fido-uaf-client-api-transport-v1.0-ps-20141208.pdf
- [UAFAuthnrCommands]
- D. Baghdasaryan, J. Kemp, R. Lindemann, R. Sasson, B. Hill, FIDO UAF Authenticator Commands v1.0. FIDO Alliance Proposed Standard. URLs:
HTML: fido-uaf-authnr-cmds-v1.0-ps-20141208.html
PDF: fido-uaf-authnr-cmds-v1.0-ps-20141208.pdf
- [UAFProtocol]
- R. Lindemann, D. Baghdasaryan, E. Tiffany, D. Balfanz, B. Hill, J. Hodges, FIDO UAF Protocol Specification v1.0. FIDO Alliance Proposed Standard. URLs: