@Steve So these are all the SQRL-specific fields needed, for full functionality, since the API takes care of the rest?
Yes, exactly. The SSP API creates a clean abstraction of SQRL protocol and interaction with SQRL clients.
So, tell me if I understand the SQRL registration process correctly:
- A user authenticates, and sends the server a 24 character authentication token
- The web server sends this token to the SSPAPI to receive a 12 character unique user identifier (the 12 character unique identifier is created if the user has not authenticated before)
- The web server then sends the 12 character identifier to /add.sqrl together with an existing, or just created, arbitrary identifier used by the website to identify a user (it also adds the 12 character identifier to its own database). The arbitrary identifier will be returned next time /cps.sqrl is called with the same 24 character authentication token, so the server can log in the correct user.
And more or less the same thing happens when a user adds sqrl to their account.
Yes. You have that right. But I can offer a bit of clarification.
For his XenForo/SQRL add-on, Rasmus chose to use the 12-character SQRL user ID returned by the SSP API directly, since the existing XenForo system already contained provisions for 3rd-party identification through its "Connected Accounts" provision.
However, in order to accommodate use by a website that may not have such provision, the SSP API also allows the website to provide whatever sort of account identifier it already uses, which the API will store and return to subsequently identity the website's account whenever the user authenticates.
So, in your point #3 above, while you
could do both -- store the 12-char SQRL user ID provided by the API, and also provide the API the website's user account identifier for it to store -- you would normally choose one or the other depending upon the features available for your web server. The API is fully flexible in its abstraction and allows either or both.
If the API returns the web server account id for a registered account (when calling /cps.sqrl), and that identifier can be used for all API calls, in which cases does one use the SQRL identifier from the webserver's database? It seems it's never explicitly required since the web server account id can be used instead.
Exactly right.
If one does not plan to use MSA, can the username handle be omitted at all times? I let a user change their name at any time, and one account only has one username, so it doesn't seem like my accounts are compatible with MSA or the way the SSP API sees usernames. Or is the username used by MSA different from a user displayname?
Right again. The API off-loads all of the responsibility it can from the web server. Since it's necessary to somehow identify users for shared access, it provides that mechanism, too. But the user names are only there for MSA management and, again, only if the webserver wishes not to provide its own naming.