Not able to connect with the new 3.7.0 and .btc username

[pradel]

With the new Hiro wallet version 3.7.0, I am not able to connect to websites anymore for account that owns a .btc username. Connecting with an account that does not own an username is working fine.

This is the error I am seeing in the console:

The ones I tried:

• Arkadiko
• Frens
• Alex

[markmhendrickson]

I just tried with my mark.btc name and authenticated to Arkadiko fine. I wonder if it's a particular type of .btc name 🤔

Screen.Recording.2022-04-07.at.16.29.59.mov

[markmhendrickson]

@pradel Do you have another .btc you can try to see if you get the same result?

[pradel]

I tried with 2 different ones and got the same issue

[markmhendrickson]

@janniks and I are thinking that this issue may get resolved by the work being done to remove BNS checking from authentication entirely here: #2333

He's going to prepare a test build and let you know here when it's ready for you to try with these .btc names that are failing for you.

[janniks]

This is a strange one, and really two issues...

• It seems for some accounts the username is NOT passed into the authResponse payload. These will succeed, because they essentially skip the username matching check. I couldn't figure out when it's passed and when it isn't — might need some help from the wallet team on this if we want to figure this out.
• The username matching uses the iss/did part of the payload. This currently uses the btc-addr version of the address of the dataPrivateKey. BUT the registrar/API response's address (aka owner) includes the public address (the same address as shown in the wallet UI). So matching will fail even when it shouldn't, as it's comparing two different addresses of the same owner.

At first glance, it "looks" like the username matching check should have never worked. It's hard to track down the history of when API+stacks.js would have had matching addresses at the same time, if that was ever the case...

[markmhendrickson]

I'm closing this out since I believe it'll be resolved on the app's side with a Stacks.js upgrade to include hirosystems/stacks.js#1230. cc @janniks