Data Types

COSE Algorithm Identifiers

The WebAuthn specification uses COSE Algorithm Identifiers to specify which signing algorithms are allowed for new WebAuthn passkeys during registration and also the signing algorithm that a given passkey is using. These identifier values are defined by the IANA COSE Algorithms registry. FusionAuth supports a subset of these algorithms.

Supported algorithms

Instants

FusionAuth stores all time references as the number of milliseconds since the unix epoch. This is is the same as unix time except the precision is milliseconds instead of seconds.

For example, consider the following date.

10:45 AM MST on July 4th, 2015

In order to send this value to FusionAuth, you would need to convert this date time to the number of milliseconds since the unix epoch which is 1436028300000 and then send this value as an input parameter. Convert instants to human readable dates or vice versa.

When you retrieve these same values from FusionAuth you may then easily convert the value to any date and time format you wish with as much or little precision as you wish. For example, you may display only the day, month and year to the user, or include hours and minutes, but excludes the seconds. Because everything we store is in UTC - converting this value to a local time zone is easy and there is no guess work.

Locales

FusionAuth accepts and returns Locales on the API using the Java standard format of a ISO 639-1 two letter language code followed by an optional underscore and a ISO 3166-1 alpha-2 country code. Below is a table of common language and country codes and the resulting locale string that can either be sent into an API or be expected on the API response. This is not an exhaustive list but only provided as an example.

Locale Codes

Time Zone

FusionAuth accepts time zones in an IANA time zone format.

For example, the following values are all valid time zone formats.

• America/Chicago
• America/Denver
• America/New_York
• Asia/Tel_Aviv
• Asia/Tokyo
• Europe/Amsterdam
• Europe/Belfast
• Europe/Kiev
• Europe/Paris
• Pacific/Tahiti
• US/Central
• US/Pacific
• US/Mountain
• US/Eastern
• UTC-7
• UTC+2

UUIDs

Data types specified as UUID are expected to be in a valid string representation of a universally unique identifier (UUID). The API specifically expects the UUID to be provided in its canonical form which is represented by 32 lowercase hexadecimal digits displayed in five groups separated by hyphens.

This representation takes the form of 8-4-4-4-12 for a total of 36 characters, 32 hexadecimal characters and four hyphens. In case you are converting an array of bytes, the break down of bytes for the hexadecimal String is 4-2-2-2-6. UUIDs are version 4.

Here’s an example of a UUID in the expected canonical string format in a JSON request or response body.

{
  "foo": {
    "id": "965865ef-b17d-4153-b952-d8902e584f7d"
  }
}

Here’s an example of a UUID being provided as a URL segment for an API.

/api/user/965865ef-b17d-4153-b952-d8902e584f7d

Now that you’re all excited about UUIDs, do you want to generate you own? Go ahead, we won’t tell anyone - check out our ad-free Online UUID generator.

Unix time

Unix time is the number of seconds since the unix epoch.

You’ll mostly find unix time used in token claims because that is what the specification requires.

Unix epoch

An epoch is simply a fixed point in time used as reference point from which we can measure things. The unix epoch is 1 January 1970 00:00:00 UTC.

You can pronounce epoch however you wish, we’re not the boss of you, but common pronunciations include ee-pok as well as eh-pock.