Skip to main content

Authentication

When multiples independents worlds are visited by the same traveler, there is a need for each of these spaces to be able to identify their visitor. Whenever someone leave a mark somewhere (being a remark, feedback, moving objects, or interacting with some sort of local inventory), that persistence must be maintained and retrieved by its rightful owner the next time they visit the space. If a traveler gain a object to be used in this world (supposing the object makes sense only in that local world), probably no one but them should be able to use that object.

Authentication could be performed per world, with traditional credentials systems we already know, being password (discouraged), magic links/One Time Password or WebAuthN (passkeys).

We can however start building right now with new authentication standards and benefit from modern security standards and features such as biometrics, multi-factor authentication, social recovery, and more.

The choice made with ONCHAINID is to always authenticate the traveler for their identity, being their ONCHAINID smart contract, using any authentication key available on this contract. The same keys can be used across all protocols and media: games, immersive worlds, websites, social networks, ...

Authentication flow​

Any relying party willing to authenticate an identity owner or delegate should follow the authentication flow.

Challenge format​

Inspired by EIP-4361, authentication messages should be of the following format:

${domain} wants you to sign in with your ONCHAINID:
${onchainid-address}

${statement}

URI: ${uri}
Version: ${version}
Chain ID: ${chain-id}
Nonce: ${nonce}
Issued At: ${issued-at}
Expiration Time: ${expiration-time}
Not Before: ${not-before}
Request ID: ${request-id}

Message Field Descriptions​

  • domain is the RFC 3986 authority that is requesting the signing.
  • onchainid-address is the ONCHAINID address of the user that is signing.
  • statement (optional) is a human-readable ASCII assertion that the user will sign, and it must not contain '\n' (the byte 0x0a).
  • uri is an RFC 3986 URI referring to the resource that is the subject of the signing (as in the subject of a claim).
  • version is the current version of the message, which MUST be 1 for this specification.
  • chain-id is the EIP-155 Chain ID to which the session is bound, and the network where Contract Accounts MUST be resolved.
  • nonce is a randomized token typically chosen by the relying party and used to prevent replay attacks, at least 8 alphanumeric characters.
  • issued-at is the ISO 8601 datetime string of the current time.
  • expiration-time (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message is no longer valid.
  • not-before (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message will become valid.
  • request-id (optional) is a system-specific identifier that may be used to uniquely refer to the sign-in request.