Daily use with Multiple Identities vs. Alternate Identity


Status
Not open for further replies.

Hzy

Active member
Feb 27, 2019
38
6
Bama
I think use of an "Alternate Identity" is much more of an edge case then the day-to-day need to use a different identity than the default or the last selected which I think is the way the windows client works now (and I like as long as it's easy to change). I think the current "user" list should be presented as the first "option", with "Alternate ID" as the exception with all of the corresponding UI complexity hidden either under a tab or a second screen.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
@Hzy : IF the use of multiple identities was common I would agree and I could see your point. But I am unhappy that my client even offers multiple identities. I believe that the use of multiple SQRL identities reflects a misuse and misunderstanding of SQRL. I haven't yet had anyone produce a convincing use-case for having multiple identities. And I have just finished encouraging Jeff to remove them from his iOS client. I am an iOS user exclusively and I have no need for more than a single identity -- ever. I just cannot see any use-case for them.

The ONLY REASON I have them in my client was that (a) it began life as a proof-of-concept for SQRL and so it needed to support them and (b) the case was made that there were households where, rather than each user having their own logon session, everyone shares a single logon account. Therefore it's NECESSARY to allow multiple identities. But I'm not happy about it.

Consequently, the "Alt-ID" is there to solve the problem of SQRL's tight identity binding and to allow the "ad hoc" quick and short term creation of an alternate identity for a specific logon.
 

warwagon

Well-known member
May 20, 2018
165
64
Iowa
@Hzy : I believe that the use of multiple SQRL identities reflects a misuse and misunderstanding of SQRL.
It doesn't reflect a misuse of SQRL, it's exactly what SQRL is. Everyone has 1 identity for life. But how do you do that on a machine that is shared by more than one person? You have to be able to have each person select their own identity. SQRL was created so each individual can have their own identity, not each household. iPhone is usually used by only one person, but an iPad might be used by a family.

So with that feature not present in the iOS client, how would the Father use SQRL to log into his account on an iPad that only has the mothers identity? Does he have to start scanning QR codes with his phone?
 
  • Like
Reactions: Hzy

Andrew Godfrey

Well-known member
Mar 6, 2019
83
21
Seattle
Ouch, there are a lot of worlds colliding here. I understand SQRL best when I think of it as a password manager that has automated password generation, and then introduced asymmetric keys to avoid having to actually send a generated password to the web site. I think that helps here:
How do you use a password manager on a shared local user account? Well, the password manager I use does have UI for that - I've never used the feature myself, but it is very clearly phrased - I must 'log out' of my current identity, and then in the 'log in' screen (where I enter my master password) there's a "change account' link. I do think the GRC client could do with a similar treatment - that it is only 'logged in' to one SQRL ID at a time.

Looking at it this way would also make it clearer to me (as a user) when to use an alt-id.

P.S. I also looked at how my password manager behaves on my iPhone. It has the same feature there - log out, switch account - BUT when I tap "switch account", it pops up a warning, saying that switching account will discard my current account data from the device. (Presumably I'd be able to sync it from the server again later, but this part has no analogy in SQRL).
 

PHolder

Well-known member
May 19, 2018
1,232
205
The larger issue is that the hierarchy of SQRL as currently conceived is the selection of the .sqrl file leads to the master identity key which leads (via a hash with the URL of a site) to the IDK (and necessary private key to go with it). In an attempt to be more secure, SQRL kicks the master secret out as soon as it's done generating the IDK. The .sqrl file doesn't store more than the master secret and any previous ones (after a rekey.)

If SQRL were actually a password manager, then you could generate the IDK by ANY means rather than deriving it from the master secret. This would allow for all kinds of interesting features, but would block simplicity and impact security. It would require the client to store more data and thus would likely prevent the easy movement of said data via QR codes.

If a different SQRL client decided to break with compatibility with the GRC client (and in particular with the .sqrl file format) then it could be more like a password manager (like say LastPass) is today, with new risks and new benefits accordingly.
 

Andrew Godfrey

Well-known member
Mar 6, 2019
83
21
Seattle
All I meant by comparing SQRL to a password manager, is that it “knows” your secrets for web sites. It works completely differently - by knowing how to generate the secret, rather than by storing it. But the “master password” part is actually pretty identical (at the high level) to how my password manager works; locally-stored secret information is protected by a master password and the client app has to carefully manage when it discards decrypted secrets.

And, again at the high level, you can view the GRC client’s state of “encrypted with short password” as being analogous to the “logged in “ state. The details do differ, just like they differ between device. On my iPhone, I have to TouchID every time I bring up my password manager. While on my PC, it stays “logged in” for a while where I can switch back to use another secret without having to reauthenticate.
 
G

Gristle

Guest
So with that feature not present in the iOS client, how would the Father use SQRL to log into his account on an iPad that only has the mothers identity? Does he have to start scanning QR codes with his phone?
My opinion is that the father wouldn't be able to login directly. Plain and simple.

If he wanted to login to a device that doesn't have his ID, he's use the QR code and his personal device that does have it.

I have never liked the idea of multiple people sharing a common "home" directory in any OS. It's a terrible practice, but I get it. Until iOS allows multiple accounts, like macOS, I recommend treating SQRL the same way. One user per "home" directory, (which is one user per device on iOS 12 because there's only one "home" folder).

It doesn't make sense to clutter SQRL and confuse users. It's much better to have less features and minimize confusion at the risk of upsetting some edge cases, versus supporting all the edge cases and over complicating the UI and introduce poor security practices.
 
G

Gristle

Guest
And I agree with Andrew that for newcomers, it does help to think of SQRL as providing the same functions as a password manager, it's just the passwords don't need to be stored.

I know it's not actually like that, but I imagine if LastPass or 1Password integrates SQRL, it will be a much cleaner story than having a separate SQRL app. And even better if browsers implement clients directly!
 

Hzy

Active member
Feb 27, 2019
38
6
Bama
I think because I didn't add details for the use-case I was thinking of, what I was trying to point out may have been unintentionally confusing. First, I completely agree that an individual person is unlikely to need more than one "SQRL ID" (identity). I also think ref text does a pretty good job of informing new users about this. I was trying to say, that in order for multiple people (one SQRL ID per person) to use the app on one device, which is guaranteed to happen in a family, it should be easy to pick which one a person needs to use. This is already supported in all of the apps, but to get to this list in the Windows app, you have to go through the Alt. ID screen. Because I think the need for Alt. IDs is low (or very low) for most people, the people "SQRL ID" picker should be easier to find - so, in the current design, I would simply put the SQRL ID list before the Alt. ID screen.

My main problem with Alternative ID's is that the App does nothing to help you remember where you may have used whatever you used. On the plus side id doesn't give the user another full "SQRL ID" to manage. I suggest that at least the Smartphone apps separate this out as a "Pro" paid feature.
I think the related help text does a pretty good job of discouraging use.
223
from the Help window
224

I also did a quick search on GRC - kudos Steve for having your history searchable, and found where Steve addressed both these points in response to a listener question on SN 499:
"So this is what Kyle is asking, is what if I want two accounts, if I, I myself, my identity, want two accounts at the same domain? And what we have is a - we're still not sure what we're going to call it, a sub ID or an account ID or an alternate ID. The idea is that remember I was just saying earlier that every single time you authenticate, the first time you give it your full password, and then subsequently you can give it a shortcut. We call it the password hint. And if you did that, you'd just get your normal sort of primary account at that domain.

If you wish to appear for any reason you have, we're not telling you how or why, you want to just, for some reason, one time you want to appear to be someone else, or you do want to maintain sort of formally additional accounts at the same domain, there's a button on the dialogue that just says "Account." And so you type in your shortcut, do do do do, hit the Account button, and then anything you want. You could number them, one, two, three. You could do A, B, C. You could use your own little acronym for the second account and third account. And there's no limit.

What we do is we take whatever you type in after you press the Account button, and that gets added to the hash. So it creates an infinite number of alternative identities for your primary identity at that domain. So it just expands it infinitely. And I'll just mention that this is different than multiple users sharing a computer because Kyle's question was a little mixed up. For example, he talks about he and his wife. In the two different people mode, SQRL clients will support multiple, like, people identities.

So in a household who had a shared computer, you could have Mom, Dad, Bobby, and Susie, and their client would show those four identities. And so they would choose who they are and then just normally log in under that identity. And then all of those identities, if they wish to, could have multiple accounts under them. So, I mean, we got that. That's in there, too. And it's going to end up being very simple and easy to use and give people complete control and freedom.
"
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
Hzy...

I see your point. Though I'm still surprised that any household would not have created separate logons for every user? We now have fast user switching and it'e trivial to create separate windows account for Mom, Dad, Bobby, and Susie which they switch to when they sit down.

I say this, because, as we know. website logons are sticky and "Susie" certainly doesn't want "Bobby" logging on as her to her Facebook account. So I would imagine that the kids shared computer logon passwords are closely guarded secrets and that Bobby and Suzie both logout of their shared computer session very deliberately after they are done.

My point is... SQRL =automatically= and properly handles this mode of use. Since its identities are stored in the USER'S Documents/SQRL directory, the identity automatically changes on-the-fly as the user's session is changed and/or various users logon and off the PC.
 

Hzy

Active member
Feb 27, 2019
38
6
Bama
Agreed. I was not clear on how/where userids were stored, so thanks for clearing that up. Separate "user" accounts on a PC are effectively separate PC's. The single user case is absolutely clear and not a problem.
My wife and I have always used a single "User" account on our "main" pc. She does have her own computer/laptop and an iPad, but when she want's to do something on our main computer, she damn well expects it to be ready for her to do whatever it is she needs to do. If she (or I) are going to do anything, it is likely we will need to login somewhere. Therefore we both need access to our SQRL IDs. Since we share all devices, we we will want our id's available on every device. The win app handles this (2 SQRL IDs) already of course, but I think it should be easier to access than it currently is because it's what I personally envision needing to do. I imagine there will be others also.

A smartphone example. My wife asks me to use my phone because hers is upstairs (or wherever), I unlock it and hand it over! Come on guys...Tell me I'm the only one!

I don't really know if user switching will be used more than alt-ids, but it seems to me that it will.
 

Andrew Godfrey

Well-known member
Mar 6, 2019
83
21
Seattle
It seems like the GRC SQRL client is where it is because having a "logout" button would be undesirable for some reason. Maybe there's a concern that users would think they need to log out for safety, and SQRL doesn't believe that is really necessary?

I'll also point out that on a shared machine, when users have their phone with them then they can log in by QR code instead.

Steve I do think one tweak suggests itself - in the login screen under Options, the button is labelled "User" but in the main window it's labelled "Select Identity".
Wouldn't it be better to use the same label in both places? Additionally I'd suggest "Switch user" or "Switch to a different user" as a label, to further explain this is meant for different people, not alternate ID's for the same person.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
Steve I do think one tweak suggests itself - in the login screen under Options, the button is labelled "User" but in the main window it's labelled "Select Identity".
Wouldn't it be better to use the same label in both places? Additionally I'd suggest "Switch user" or "Switch to a different user" as a label, to further explain this is meant for different people, not alternate ID's for the same person.
Yeah. I agree that the inconsistent use needs to be fixed. Thanks!
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
It seems like the GRC SQRL client is where it is because having a "logout" button would be undesirable for some reason. Maybe there's a concern that users would think they need to log out for safety, and SQRL doesn't believe that is really necessary?
I don't understand what you mean? One of the struggles we had was in deciding what SQRL was. Earlier versions of the protocol and of its definition (which were reflected in the protocol) had the client more "involved". But that didn't set well so I proposed and we finally decided that SQRL should be =ONLY= about asserting a user's identity, with as little more as possible. The "Ask" facility is an example of the one "non-auth" extension that we tolerated because it was potentially SO very useful. And if it wasn't in there from the start it would never be in there.

So... "Logout" is not something that SQRL does to a website.

But if you meant "logging out of the SQRL client itself?"... That's not there because there's no sense of logging in. In that sense SQRL is stateless, as I think it should be. Each use of SQRL stands alone and requires some form of reassertion of the user's identity.

I never considered having a user "login" and "logout" of the client as a means of establishing their "SQRL session identity." But since this whole multiple identity thing is really a tempest in a teapot, I think the client's balance is just right.

It's very clear to me that as the number of cooks in the kitchen has recently exploded, many of the carefully considered decisions I've made and discussed and settled upon over the years are being revisited and reconsidered. I have NO PROBLEM with that, other than the time it takes for me to re-defend my previous choices. And additional tweaks DO often result, which also makes the revisiting worthwhile. I'm also sure that it's not possible for any design to satisfy everyone all of the time. And I'm okay with that, too.
 
G

Gristle

Guest
Steve, in my opinion, taking additional time to defend your previous decisions to people who haven't spent as much time as you thinking through these nuances is not a worthwhile use of time. We've all been waiting for 5+ years for this.

I feel like the burden for answering the multi-user-on-a-single-device is one that should be owned by the operating system, not the SQRL client. If someone has such a demanding need to use their shared iPad like this, and they insist on using SQRL for multiple people in their family, then a market will exist for a client to create that type of feature (perhaps with a notion of logging in and logging out).

In my experience, a lot of people share an iPad, but few share the phone. I think that's a great reason to use the cross-device feature of SQRL! In fact, I have my own iPad with the SQRL client, and I tend to use the cross-device QR code just because it's so fun and magical!
 

Andrew Godfrey

Well-known member
Mar 6, 2019
83
21
Seattle
Yes I meant logging out of the client. It does feel a bit complicated to have both “Switch user” and “discard quick logon” as separate concepts when they both feel a bit like logging out. But I do think this part can be figured out through user feedback (I mean, if large numbers of people ask for it and can clarify the usage landscape).

Re. removing multiple-user support from the iOS client: I think the same - user feedback can guide it. In fact I see some sense in following this path even if it turns out that some users need multi-user support in the client. Steve is right to be concerned about initial usage patterns.
 
G

Gristle

Guest
It's a catch 22 right now. Users won't be able to give feedback if they don't adopt and try it. I feel like we have enough users to make reasonable decisions about the right way to proceed. The good news is that despite having many cooks in the kitchen, the final decision for the SQRL iOS client is up to Jeff and Steve and I think we should honor their decision if it doesn't satisfy all of us.
 
G

Gristle

Guest
Go for it! If you need beta testers, I'd gladly give it a shot.
 
Status
Not open for further replies.