]> Registries for Credential Exchange Bitwarden
ohinton@bitwarden.com
1Password
rene.leveille@1password.com
credential exchange credential types extensions This specification defines IANA registries for Fido Alliance Credential Exchange Format (CXF) credential types and extension identifiers. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction The FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default. This specification establishes IANA registries for the Credential Exchange Format credential types and extension identifiers. The initial values for these registries are in the IANA Considerations section of the specification.
Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
IANA Considerations This specification establishes two registries:
  • The "Credential Exchange Credential Type Identifiers" registry (see )
  • The "Credential Exchange Extension Identifiers" registry (see )
Any additional processes established by the expert(s) after the publication of this document will be recorded on the registry web page at the discretion of the expert(s).
Credential Exchange Format Credential Type Identifier Registry Credential Exchange Format credential type identifiers are JSON compatible strings defined in "Credential Types Registry". Credential type identifiers MUST be unique across all registered credential type identifiers.
Registering Credential Type Identifiers Credential Exchange Format credential type identifiers are registered using the Specification Required policy (see Section 4.6 of ). The "Credential Exchange Format Credential Type Identifiers" registry is located at https://www.iana.org/assignments/credential-exchange. Registration requests consist of at least the following information:
Credential type identifier:
An identifier meeting the requirements given in .
Description:
A short description of the credential type.
Requires an additional payload:
A "Y" or "N" value indicating whether the credential type requires an additional payload outside of the Credential Exchange Format JSON document.
Specification Document(s):
Reference to the document or documents that specify the credential type.
Registrations MUST reference a freely available, stable specification, e.g., as described in Section 4.6 of . This specification MUST include security and privacy considerations relevant to the credential type.
Registration Request Processing As noted in , Credential Exchange Format credential type identifiers are registered using the Specification Required policy.
Initial Values in the Credential Type Identifiers Registry The values listed in the "Credential Types Registry" section of the specification will be used to populate the initial values in the registry. The Change Controller entry for each of those registrations is:
Change Controller:
Fido Alliance Technical Working Group (todo: email)
Credential Exchange Extension Identifiers Registry Credential Exchange Format extension identifiers are JSON compatible strings defined in "Extension Registry". Extension identifiers MUST be unique across all registered extension identifiers.
Registering Extension Identifiers Credential Exchange Format extension identifiers are registered using the Specification Required policy (see Section 4.6 of ). The "Credential Exchange Format Extension Identifiers" registry is located at https://www.iana.org/assignments/credential-exchange. Registration requests consist of at least the following information:
Extension name identifier:
An identifier meeting the requirements given in .
Description:
A short description of the credential type.
Requires an additional payload:
A "Y" or "N" value indicating whether the credential type requires an additional payload outside of the Credential Exchange Format JSON document.
Specification Document(s):
Reference to the document or documents that specify the credential type.
Registrations MUST reference a freely available, stable specification, e.g., as described in Section 4.6 of . This specification MUST include security and privacy considerations relevant to the extension.
Registration Request Processing As noted in , Credential Exchange Format extension identifiers are registered using the Specification Required policy.
Initial Values in the Credential Exchange Extension Identifiers Registry The values listed in the "Extension Registry" section of the specification will be used to populate the initial values in the registry. The Change Controller entry for each of those registrations is:
Change Controller:
Fido Alliance Technical Working Group (todo: email)
Security Considerations See for relevant security considerations.
Normative References Credential Exchange Format Fido Alliance Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.