Alt-ID & My use cases

  • New Wordpress Plug-In Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to the Wordpress plug-in which Daniel Persson originated and has been making great progress on. You'll find it under "Server-Side Solutions."

    /Steve.

berossm

New member
Sep 28, 2018
3
0
38
8Alt-ID SupportCore FeaturePending decisionNone

From your list I see Alt-ID is listed as Pending decision. I would really like to see this feature.

I am already using 1 alternate ID regularly. I move my blog (well revived it from an abandoned state) so I could use the SQRL plugin. My normal identity is for my Editor level account and an Alt-ID for the admin account. The lack of Alt-ID is not a major issue as I can't think of a use case where I would think its a good idea to log into the admin panel not on a trusted device.

Where this will be more important to my work flow is when (really hoping its a when not an if) Google allows SQRL.

I have intentionally separated Google accounts one is only for work related things that I need when on travel and don't have access to our internal email. Mostly flight, hotel, and car rental related. Printing info from business centers was part of the original inspiration for the protocol so being able to have both accounts accessible via QR code would be very useful.

TLDR: I think having an iOS app with Alt-ID may really help push adoption by major site operators.
 

Gristle

Well-known member
Feb 16, 2019
341
70
No longer contributing to this forum due to harassment from PHolder.
 
Last edited:
  • Like
Reactions: ahauser

PHolder

Well-known member
May 19, 2018
918
124
There are no optional features for SQRL clients
Stating this as an absolute is simply false. There is a minimum set of features that are required... but there is no maximal set... and as yet, with the documentation unfinished and not yet officially published, there is NO defined feature set for any developer to follow or meet.

With no organization to hold a trademark, any old developer could claim whatever they want, whether it's true or not... There is no one to pay to certify a SQRL client as meeting some standard. The design of the forums here will lead to providing people guidance... one presumes client's that aren't quality won't get a section on the forums.

The concern most people would have is getting "trapped" on a client that did things in it's own non-standard way such that they could never port their ID to another client. Not having a feature that most other clients would probably have is not trapping you in this way... and in fact might prompt one to eventually move to a more feature filled client.

That said, the alternate ID is clearly part of the base protocol, so choosing not to provide a UI for it would probably be folly.
 

Dave

Well-known member
May 19, 2018
388
73
Gardner, MA
Stating this as an absolute is simply false. There is a minimum set of features that are required... but there is no maximal set... and as yet, with the documentation unfinished and not yet officially published, there is NO defined feature set for any developer to follow or meet.

With no organization to hold a trademark, any old developer could claim whatever they want, whether it's true or not... There is no one to pay to certify a SQRL client as meeting some standard. The design of the forums here will lead to providing people guidance... one presumes client's that aren't quality won't get a section on the forums.

The concern most people would have is getting "trapped" on a client that did things in it's own non-standard way such that they could never port their ID to another client. Not having a feature that most other clients would probably have is not trapping you in this way... and in fact might prompt one to eventually move to a more feature filled client.

That said, the alternate ID is clearly part of the base protocol, so choosing not to provide a UI for it would probably be folly.
I realize you are arguing semantics. Anything any client wants to add is optional. But the statement, as asserted, has precedence in canon:

However, there is nothing that's optional for SQRL. We deliberately kept SQRL to a minimum.
 

PHolder

Well-known member
May 19, 2018
918
124
@Dave, I know what Steve says, but I think the point I was making is that there is NOTHING to stop anyone from claiming anything as a SQRL standard client... other than an appeal to human decency. When I openly considered a client with features that would not be 100% backward compatible, you blasted me over it, and so I abandoned my work on the idea, rather than appear to be a troll. But trolling does happen.... For example, if someone with a worry of being surpassed (say LastPass) wanted to kill SQRL, they could make a very broken implementation and call it "standard"... and all the noise and confusion would just scare people away from adoption.
 

Dave

Well-known member
May 19, 2018
388
73
Gardner, MA
@Dave, I know what Steve says, but I think the point I was making is that there is NOTHING to stop anyone from claiming anything as a SQRL standard client...
Ah! I missed your point. You are quite correct.

When I openly considered a client with features that would not be 100% backward compatible, you blasted me over it.
Sorry if I came across quite that heavy handed.

and so I abandoned my work on the idea, rather than appear to be a troll.
Wow! You have my apologies! That certainly was not my intent. As I recall, I was arguing - yes, adamantly - for, at the very least, maintaining interoperability with other clients if at all possible. If you wanted to write an enhanced client that stored a whole bunch of non-standard [sic] stuff, in any internal format you wish, I would have no problem with that at all (which is probably good, given that I have absolutely no right, claim, or standing to object to anything). It just made no sense in my mind to create a proprietary island, unable to import AND export compatible storage formats. Again, if I recall correctly, the S4 format is a tagged file format, sufficiently extensible as to allow that. Lesser clients would simply ignore/lose any extra exported information on import.

But trolling does happen.... For example, if someone with a worry of being surpassed (say LastPass) wanted to kill SQRL, they could make a very broken implementation and call it "standard"... and all the noise and confusion would just scare people away from adoption.
Valid point and valid concern. Though, to your point, there is little to prevent anyone that devoid of ethics from doing so with virtually any nascent software in defiance of any adopted standard or license.

Again, sorry if you felt beaten up. I really am a nice guy. 😇

Dave
 

sengsational

Well-known member
Feb 17, 2019
115
34
Taking it to the extreme, I'd say you need only a couple of the official features on your mobile device to have a handy logon tool.

This presumes that most of your SQRL identity management is done on your desktop computer.

If you had a client that only could import an identity from a paper QR code and use that (one) identity to log on to web sites, you'd have an incomplete, but useful tool that "most people" would be satisfied with.

Alt-ID would be an easy addition, but if you were going for simplicity in a client, it would be one to leave-off.