FYI Email Feature Request

  • 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.

Vela Nanashi

Well-known member
May 19, 2018
633
107
SQRL does not use an email for anything, so I am not sure why the app would ask for the email, what purpose would that have?
 
Jul 13, 2019
7
0
@Dave @Vela Nanashi On the android app "Save identity" screen when it asks for "Identity name" (option) & "password". Include a box for an email address. This would allow a user to signup for a newsletter using SQRL.
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
Sites are free to ask for additional information from the user when they are signing up, SQRL is not designed to give any extra information to sites. Also there is as far as I know no newsletter provided by the developer of the android app.
 
  • Like
Reactions: kalaspuffar

Vela Nanashi

Well-known member
May 19, 2018
633
107
You should be able to go to your account and set those on WP sites I think, it is all in the server implementation though, not client, so you had me confused due to posting this in the android client forum, not the WP plugin forum :)

The name in the client I think is just to be convenient for the user when interacting with the client. It is never sent to any site. Most of us want it to stay that way.
 

PHolder

Well-known member
May 19, 2018
918
124
When creating an identity including an email with it should be offered.
This doesn't fit within the SQRL protocol, which is focused on being a MINIMAL authentication ONLY protocol/process. A client could collect and store extra info if wanted to, but there is no way in the current protocol to communicate it to a server. I think we need to focus on getting what exists working well and supported... now is not the time to dream up new features. If work wanted to start on a future SQRL 2.0 protocol, that might be a better idea, but then that could distract resources away from even reaching 1.0.
 

ahauser

Well-known member
Feb 22, 2019
82
24
The name in the client I think is just to be convenient for the user when interacting with the client. It is never sent to any site. Most of us want it to stay that way.
Exactly right. Naming your (first) identity is fully optional in the Android client, and it's just there so that one can distinguish one identity from the other if more than one is present. Identity names are never transmitted or used elsewhere. In the "standard" scenario, where only one identity is present, we even hide any trace of "identity selection" within login dialogs etc.

I also agree that for now, this is how it should stay.
 
  • Like
Reactions: kalaspuffar
Jul 13, 2019
7
0
@kalaspuffar @Vela Nanashi @PHolder I was unaware that the protocol couldn't carry other information. I'm not trying to distract from bring this very cool technology to the world.

Using SQRL got me excited, I immediately realized that it could put the hurt on Amazon. Everyone shops on Amazon because its easy, they have everyone's information. If the SQRL client could gather (Name, Billing/Shipping address, credit card) shopping on a newly discovered small independent website would be as easy as shopping on Amazon.

There are Amazon sellers starting to get off the platform because of all the shenanigans. A "SRQL 2.0 protocol" would be appealing to them and their potential customers.
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
As it stands SQRL is designed to fix the password problem, in that it allows authentication, in a way, that does not leave any site you authenticate to with ANY secrets it has to keep, so database breaches will not leak anything important if the site used SQRL, or at least nothing related to SQRL is important in those cases.

So then having SQRL carry information that it can give to sites, that actually has value, feels very not SQRL. Of course maybe something like that could be tacked on by some program that implements SQRL and that sort of form auto filling feature, but if it were to ever be implemented in SQRL in the future it would have to not be automatic give everyone you talk to the information, but it would need to be something the user has to choose to do, like "fill in this form for me" type feature, that I think some password managers already have, so I think the best solution would be for said password managers to integrate SQRL, rather than for SQRL to implement form auto filling.

Of course maybe a safe transfer between client and server using cryptography properly could be done in a future version of SQRL, to augment the existing ask facility. Where whatever we call that program pops up "hey site X, wants to get your real name, shipping address and credit card, is it allowed to have those?" and checkbox (I am sure) and then greyed out until checkbox is checked button "yes" :) and never greyed out "no/cancel/abort" button.
 

shanedk

Well-known member
May 20, 2018
317
86
That is an advantage of password managers like LastPass: they can hold things like credit card info and autofill them on sites so you don't have to rely on the site saving them and keeping them secure. While SQRL itself doesn't provide for any such functionality, there's nothing whatsoever stopping SQRL from being incorporated into a password manager, and we've actually discussed several advantages of doing so over the years.
 
  • Like
Reactions: MrObvious