Difference between revisions of "Use-case Free Description"

From SQRLauth.net
Jump to: navigation, search
m
m
Line 19: Line 19:
  
 
=== Client ===
 
=== Client ===
A SQRL-Client application (PC Program, Smartphone App, Single use device) in the possession of the user that captures the SQRL link and uses it to authenticate the users chosen identity to the Server in a pseudonymous way in relation to the predefined Resource indicated on the SQRL-Link.
+
A SQRL-Client application (PC Program, Smartphone App, Single use device) in the possession of the user that captures the SQRL link and uses it to authenticate the users chosen identity to the Server in a pseudonymous way in relation to the predefined Resource referenced by the SQRL-Link.
  
 
=== Server ===
 
=== Server ===

Revision as of 16:33, 6 March 2015

{Page Build In Progress}

Contents

What is this document

This is a deliberately use-case agnostic description of SQRL, such that it can form a guide to production of use-case specific implementations more simply without compromising core advantages.

Abstract

SQRL is an open licence, patent unencumbered, pseudonymous resource authentication protocol. At its core it makes use of Elliptic Curve Cryptographic (ECC) processes {Ed25519, Curve25519} and a simple keyed-Hashed Message Authentication Code (HMAC-SHA256) to deterministically produce Resource specific key-pairs that are used to offer a zero knowledge proof of secret key possession on a random challenge.

Parts of SQRL

Broadly SQRL consists of four main parts (see below and diagram>>). Depending upon use-case these four parts may be combined in a number of ways into a smaller number of logical devices.

Functional outline with data flows


Resource

This is the (item, transaction, state, interactive session identifier etc.) being authenticated to by a user. A reference to it is specified within an SQRL-Link generated by the Server and presented upon the Display where an action by the user transfers that link from the Display to the Client.

Display

A place (PC browser, Sticker, POS device, Voting sheet) where an SQRL-Link fetched from the Server is displayed such that it can be passed from the Display to the Client.

Client

A SQRL-Client application (PC Program, Smartphone App, Single use device) in the possession of the user that captures the SQRL link and uses it to authenticate the users chosen identity to the Server in a pseudonymous way in relation to the predefined Resource referenced by the SQRL-Link.

Server

A device that can accept network queries from, and make responses to, the Client and possibly also the Display. Perform all the action needed to securely and uniquely authenticate the Clients presented identity to the requested Resource.

==

SQRL-Link

A Resource reference displayed to the user possibly in the form of a QR-Code with an associated link URL with the scheme ({s}qrl://). This link is them passed to the Client to initiate a conversation between the client and the Authentication_Server. The Authentication_Server to be used is referenced by the endpoint (Domain + Path) of the URL. The Resource to be authenticated via SQRL (Link-nut) is defined either in default implementations as a GET parameter in the URL with the argument nut or alternatively by any other URL safe in-line means.

Link-nut: A base64URL encoded reference that leaks no information as to the exact Resource but can be associated to a specific predefined one by the Authentication_Server. Nuts can be static over time or dynamically generated for each use, but are always linkable to a specific predefined Resource by the Authentication_Server.

  • Link-nut*

The first use is in the SQRL-link {Link-nut}. There the nuts primary need is to carry the authentication resource reference from where the nut is displayed to the client (i.e. The browser session_id), it can do this internally as an encrypted string (stateless) or as a totally random string referenced to server stored state (statefull). Secondarily there is a security requirement for the nut to be unique and unpredictable to mitigate replay attacks.

  • Auth-nut*

The Second use of nut is in the server responses to client requests {Auth-nut}. Here its primary use is to mitigate replay attacks by the same means as mentioned above plus a side benefit of securing stateless MAC confirmations. It can have a secondary *optional* use for the server to loop state information as to the internal authentication state via the client and possibly resource references.


Resource: The item that identity is being authenticated against e.g. (Auser account, A system folder, A monetary transaction, A purchase, Abuilding entrance, An alarm system, A municipal/federal Ballot item etc.)