Websites using SQRL

[rxp]

How did you initially sign up? Did you associate your SQRL identity with your account?
View attachment 647

In the sign-up process, I did not know what an "associated account" was supposed to be. If I remember correctly, there was some mail address (that I did not know or recognize) shown under Associated Accounts in my newly created twit profile settings page (or something of a similar name - cannot check now, since I cannot log in). It was not an email address that I had entered, and I thought it was some dummy placeholder address, some possibly pre-populated data field, just like there was some dummy username pre-populated in the Create New Account form. So I think I deleted that "associated account" address from my profile, seems there is a trash can icon next to it. I did not know what business a strange email address had, being "associated" with my newly set-up twit account.

I am confused. I was under the impression that one of the main advantages of SQRL was supposed to be that a website could recognize an individual user without an email address.

 

[PHolder]

I am confused. I was under the impression that one of the main advantages of SQRL was supposed to be that a website could recognize an individual user without an email address.

SQRL is not a definition of how sites have to allow you to authenticate. It's a series of options that a site can choose to support. If you wish to join the TWiT site, it has requirements for its members, and one of them is a valid email address (I believe.) Another site might not require that. In any case, the TWiT site is not a pure implementation of SQRL, it is using a proxy. The SQRLOAuth site is that proxy (the one that Jose made.) That site doesn't require "real" information at all, but because it uses OAuth, it does require some information, and it will share that information with whatever site chooses to authenticate with it. The TWiT site uses Jose's OAuth site, so when you tie the two together, you are allowing the site to transmit information from the OAuth information on Jose's site to the TWiT Discourse site. (If it helps you understand any better, realize that OAuth is what Facebroke and Google use when you click the "signup/login with __x__" buttons on sites.)

 

[rxp]

SQRL is not a definition of how sites have to allow you to authenticate. It's a series of options that a site can choose to support. If you wish to join the TWiT site, it has requirements for its members, and one of them is a valid email address (I believe.) Another site might not require that. In any case, the TWiT site is not a pure implementation of SQRL, it is using a proxy. The SQRLOAuth site is that proxy (the one that Jose made.) That site doesn't require "real" information at all, but because it uses OAuth, it does require some information, and it will share that information with whatever site chooses to authenticate with it. The TWiT site uses Jose's OAuth site, so when you tie the two together, you are allowing the site to transmit information from the OAuth information on Jose's site to the TWiT Discourse site. (If it helps you understand any better, realize that OAuth is what Facebroke and Google use when you click the "signup/login with __x__" buttons on sites.)

Thanks for the explanation. Some of this is new to me. Having listened to @Steve talk about it occasionally over the years on Security Now, my expectation was (and my hope still IS) that SQRL made it possible to identify a user by his SQRL identity - and nothing else.

I have never used (for what I would say are good reasons) an "signup / login with x" before.

 

[josecgomez]

Thanks for the explanation. Some of this is new to me. Having listened to @Steve talk about it occasionally over the years on Security Now, my expectation was (and my hope still IS) that SQRL made it possible to identify a user by his SQRL identity - and nothing else.

I have never used (for what I would say are good reasons) an "signup / login with x" before.

So the issue you are running into was that the sqrl identity you have wasn’t correctly associated with the twit account you created (because your email address wasn’t verified at sqrloauth so twit did not consider it authenticated)
If you login to twit using your username and password (which proves authentication)
You can now successfully link that account with your sqrl account without issues

 

[josecgomez]

So the issue you are running into was that the sqrl identity you have wasn’t correctly associated with the twit account you created (because your email address wasn’t verified at sqrloauth so twit did not consider it authenticated)
If you login to twit using your username and password (which proves authentication)
You can now successfully link that account with your sqrl account without issues

The reason for that is security imagine you go to sqrloauth and create a sqrl account with an email address of leo@leoville.com which you can do and not verify it, then you go to twit and authenticate using that sqrl account.
SqrlOauth gives leo@leoville as your email and twit looks and says well we have a leo@leoville that matches so now you are authenticated against the Leo account and you take over twit.

As a security measure to prevent the above scenario twit only lets you associate sqrl logins to sqrloauth verified email addresses or if you are previously authenticated to twit and you create the association from within your twit account directly thus proving you are you

 

[Jeffa]

The IOS client doesn't yet support ask. @Jeffa will the new version?

Hi,

Yeah it will have “ask”

Jeff

 

[rxp]

So the issue you are running into was that the sqrl identity you have wasn’t correctly associated with the twit account you created (because your email address wasn’t verified at sqrloauth so twit did not consider it authenticated)
If you login to twit using your username and password (which proves authentication)
You can now successfully link that account with your sqrl account without issues

What password?

I happen to remember the username I used to sign up with SQRL at twit.community. But unless I completely misunderstood what @Steve talked about over the years when explaining SQRL on Security Now, even the username should not have to be remembered by the user who uses his SQRL identity to come back to a website where he had previously signed up at using that same SQRL identity. Once I authenticate with my SQRL identity (e.g. by scanning, with my SQRL-ID-phone , the QR code that the site shows me), the website should actually tell me the username I chose when I signed up. And that is the way it does work here on this forum - which is why I am here and loving the idea of SQRL.

So, when I signed up at twit.community, I surely did not set up, create or use a password.

To me, getting rid of having to deal with, remember etc., username and password for every single site you sign up for, is the main advantage of SQRL.

 

[rxp]

How did you initially sign up? Did you associate your SQRL identity with your account?
View attachment 647

By "associate your SQRL identity with your account," I suppose you meant
associate my SQRL sqrloauth.com identity with my account at twit.community?

I believe your screenshot is from your profile settings page at twit.community, and in it the red arrow points to an email address field named "OAuth 2" , under the heading "Associated Accounts". Is it correct to say that the twit.community server / forum software is unaware of anything directly SQRL, such as my SQRL identity?

With you guys' help, I may be starting to understand what happened. And learn about OAuth in the process.

 

[PHolder]

Well Jose could better explain how his SQRL OAuth site works, but in essence what it seems you did is simultaneously create an account on it and an account TWiT Community. Your SQRL identity is associated with the SQRL OAuth site. So to unwind this, I would suggest you start by getting the account on the OAuth site settled first. You could theoretically use your OAuth identity with another site in the future, if it were to be configured in a manner similar to TWiT Community. Based on that, presumably you want the email address it has on file to represent something you can control.

Once you have that sorted, you'll probably need admin help (aka Leo) to recover the account on TWiT community. I would be happy to facilitate that, if you want me to, PM me here with the necessary details, and I will forward them to Leo with an explanation. Otherwise, create a dummy account there and message Leo from it.

 

[josecgomez]

By "associate your SQRL identity with your account," I suppose you meant
associate my SQRL sqrloauth.com identity with my account at twit.community?

I believe your screenshot is from your profile settings page at twit.community, and in it the red arrow points to an email address field named "OAuth 2" , under the heading "Associated Accounts". Is it correct to say that the twit.community server / forum software is unaware of anything directly SQRL, such as my SQRL identity?

With you guys' help, I may be starting to understand what happened. And learn about OAuth in the process.

Correct,

Twit.Community is a Discourse Forum Software that knows nothing about SQRL... frankly there are like 10 sites anywhere in the entire internet that know anything about SQRL. That's why I made sqrloauth.com

It uses the well known and well supported OAuth 2.0 protocol which is supporter by millions nay billions? of sites... IDK anyways the sqrloauth site that I made uses SQRL itself (it is SQRL Aware fully) it allows anonymous accounts and dummy records etc... then IT is used as the Authentication (Authority) to authenticate against for sites like TWIT who do not yet understad SQRL. (think of it as the Login with Facebook or Login with Google button of SQRL)

Now this does run into a bit of an issue, sqrloauth.com doesn't care about your email or username or password it doesn't even need them, but most other sites on the internet do.... so as a compromise when a sqrloauth account is created I give you a dummy username and email that it is then passed onto TWIT or other sites to satisfy their requirements.

This however can pose a security issue for those sites, because anyone could go to sqrloauth.com and create an account with specific@specificdomain.tld account at will without verification then try to associate that account with TWIT (or other sites that support OAuth 2.0) and if sqrloauth.com was to be taken at it's word then anyone could overtake anyone's account. IE ... Imagine that twit has an existing account with an email address of specific@specificdomain.tld and now SQRLOAuth.com comes in and says hey I got that email address too, we must be besties! If TWIT were to believe SQRLOAuth then anyone could take over that account.

To prevent this issue we implemented a verification mechanism (verify you own your email) at sqrloauth and that information is then passed onto TWIT (or others) when we give them the email address and username at authentication time.

So the workflow goes like this
a) Create an account in SQRLOAuth.com
b) If you want your account to be "legit" then you update your email address and verify it at SQRLOauth.com
c) Create an account at Twit and Link it to SQRLOAuth at which point SQRLOauth will let TWIT know your email address has been verified and everything is wonderful and you can login with SQRL At TWIT.

OR
c) Create an account manually at TWIT
d) Do not bother to verify your email at SQRLOAuth.com
e) Login to twit using your username and password
f) Now associate your TWIT account with the SQRLOauth account which hasn't been verified however TWIT doesn't care at this point because you've verified via password that you are you and thus you are establishing authentication. Your SQRL ID is linked to the TWIT ID and at that point you can log in with SQRL at TWIT.

In Either case SQRLOauth gives TWIT your name, email, username and email verification status (because that's what TWIT requires)

Hope this helps.

 

[rxp]

Correct,

Twit.Community is a Discourse Forum Software that knows nothing about SQRL... frankly there are like 10 sites anywhere in the entire internet that know anything about SQRL. That's why I made sqrloauth.com

It uses the well known and well supported OAuth 2.0 protocol which is supporter by millions nay billions? of sites... IDK anyways the sqrloauth site that I made uses SQRL itself (it is SQRL Aware fully) it allows anonymous accounts and dummy records etc... then IT is used as the Authentication (Authority) to authenticate against for sites like TWIT who do not yet understad SQRL. (think of it as the Login with Facebook or Login with Google button of SQRL)

Now this does run into a bit of an issue, sqrloauth.com doesn't care about your email or username or password it doesn't even need them, but most other sites on the internet do.... so as a compromise when a sqrloauth account is created I give you a dummy username and email that it is then passed onto TWIT or other sites to satisfy their requirements.

This however can pose a security issue for those sites, because anyone could go to sqrloauth.com and create an account with specific@specificdomain.tld account at will without verification then try to associate that account with TWIT (or other sites that support OAuth 2.0) and if sqrloauth.com was to be taken at it's word then anyone could overtake anyone's account. IE ... Imagine that twit has an existing account with an email address of specific@specificdomain.tld and now SQRLOAuth.com comes in and says hey I got that email address too, we must be besties! If TWIT were to believe SQRLOAuth then anyone could take over that account.

To prevent this issue we implemented a verification mechanism (verify you own your email) at sqrloauth and that information is then passed onto TWIT (or others) when we give them the email address and username at authentication time.

So the workflow goes like this
a) Create an account in SQRLOAuth.com
b) If you want your account to be "legit" then you update your email address and verify it at SQRLOauth.com
c) Create an account at Twit and Link it to SQRLOAuth at which point SQRLOauth will let TWIT know your email address has been verified and everything is wonderful and you can login with SQRL At TWIT.

OR
c) Create an account manually at TWIT
d) Do not bother to verify your email at SQRLOAuth.com
e) Login to twit using your username and password
f) Now associate your TWIT account with the SQRLOauth account which hasn't been verified however TWIT doesn't care at this point because you've verified via password that you are you and thus you are establishing authentication. Your SQRL ID is linked to the TWIT ID and at that point you can log in with SQRL at TWIT.

In Either case SQRLOauth gives TWIT your name, email, username and email verification status (because that's what TWIT requires)

Hope this helps.

Thanks for the explanation.

So, there is quite a difference between

(1) SQRL "direct" sign-up and login process, as it is implemented here on sqrl.grc.com, with only an SQRL-ID, and without (mandatory) email or other "verification of identity"; and

(2)"SQRL via Oauth", such as you have implemented with the Oauth Provider sqrloauth.com, where the Oauth provider will authenticate the user vis-a-vis the site where the user actually wants to sign up, and where your SQRL-ID may not be enough to sign-up, i.e. where email verification, usernames etc. may still be required (for whatever reason - which is another discussion).

Ideally, this difference should be made clear from the start, e.g. in any list of "websites using SQRL," it should be made clear whether a website belongs to type (1) or (2).

Also, when a "SQRL Login" (and/or sign-up) button is shown on a website (e.g. twit.community), it should be made clear to the user (especially the first time user, when signing up / creating an account "with SQRL") if he is not actually doing that, but rather about to create an account at an OAuth intermediary, i.e. case (2).

 

[Dave]

Thanks for the explanation.

So, there is quite a difference between

(1) SQRL "direct" sign-up and login process, as it is implemented here on sqrl.grc.com, with only an SQRL-ID, and without (mandatory) email or other "verification of identity"; and

(2)"SQRL via Oauth", such as you have implemented with the Oauth Provider sqrloauth.com, where the Oauth provider will authenticate the user vis-a-vis the site where the user actually wants to sign up, and where your SQRL-ID may not be enough to sign-up, i.e. where email verification, usernames etc. may still be required (for whatever reason - which is another discussion).

Ideally, this difference should be made clear from the start, e.g. in any list of "websites using SQRL," it should be made clear whether a website belongs to type (1) or (2).

Also, when a "SQRL Login" (and/or sign-up) button is shown on a website (e.g. twit.community), it should be made clear to the user (especially the first time user, when signing up / creating an account "with SQRL") if he is not actually doing that, but rather about to create an account at an OAuth intermediary, i.e. case (2).

This also sounds like a FAQ candidate!

 

[diabolic]

lol. The fact that we had to have a multi-post explainer and "workflow" is evidence that SQRL needs to specify EXACTLY how sites should merge accounts with incoming SQRL logins. Otherwise each site is going to do their own thing and it's waaaaaaaaaaay too confusing for normal people, and doesn't really work that well for advanced people. As soon as a regular joe shmo runs into this, they'll just delete SQRL and walk away.

Seriously, simplify. This is unnecessarily complicated.

 

[Sithmagic]

Two issues here:

1. Sqrl as direct auth implemented on website. "Standard implementation" as defined in SQRL documents.
2. Sqrl as indirect auth via OAuth provider. Provides a hook for those websites that already use OAuth for Google etc as a "trusted" third party.

What has been described here is the second, where the SQRL user wasn't aware that the second option existed. Currently there is only one OAuth site providing SQRL, but there is nothing (except time/resources/testing) preventing Google etc doing the same.
The second option provides an easy to implement (for the website) option, but it does need to be shown in the same light as "logon with Google" etc. The problem is you can't say login with SQRL as that would be confused (see above) with option 1.
Perhaps twit.community could change it from "login with SQRL" to "SQRL via OAUTH", or "login via trusted site" - which could include Google etc or not.
Perhaps SQRL ON A Hoauth - icon with sqrl on a horse? Or not.
Perhaps extract FAQ info, and start a new thread or two.

 

[mikethebee]

Thank you for that explanation, I had the same confusion about Twit.community. I have created a normal account but don't get the expected response from SQRLOAuth.com when trying to link to OAuth, the SQRL box comes up and then says cannot connect to site. I am assuming is just offline, or maybe it's me? Is there anyway to check or somewhere to ask the admins? - Thx Mike

 

[josecgomez]

Thank you for that explanation, I had the same confusion about Twit.community. I have created a normal account but don't get the expected response from SQRLOAuth.com when trying to link to OAuth, the SQRL box comes up and then says cannot connect to site. I am assuming is just offline, or maybe it's me? Is there anyway to check or somewhere to ask the admins? - Thx Mike

It is definately not offline I just tested it and double checked and it is working right.

You need to sign up to twit normally
LogIn
Then Go to your Account


Preferences

Scroll down to Associated Accounts and click Connect next to OAuth2 .

Then login with SQRL in SQRLOAuth and click Connect

 

[mikethebee]

Thanks for the help. I got through the stages you show ok. then the following screens appear, 1 appears on clicking "connect", Then I click the sqrl logo (and tried qr) I get 2, and then the error 3. -Mike

 

[josecgomez]

Thanks for the help. I got through the stages you show ok. then the following screens appear, 1 appears on clicking "connect", Then I click the sqrl logo (and tried qr) I get 2, and then the error 3. -Mike

Looks like you are having an issue with Steve's client communicating or trying t open twice. What browser are you using?

 

[Jeffa]

Looks like you are having an issue with Steve's client communicating or trying t open twice. What browser are you using?

I have not seen this exact problem, but I have certainly seen chrome continue to sqrl before the “this site is trying to open” dialog has been satisfied.

 

[mikethebee]

I tried ChEdge and Chrome, and my Android client on the QR. I don't recall the browsers pausing on the 'this site ... " at all. I will try on FireFox, and another machine.