whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.11k stars 2.67k forks source link

[PROPOSAL] Private Key Authorization System Built in Browser #3337

Open xialvjun opened 6 years ago

xialvjun commented 6 years ago

Nowadays, we have two ways for authorization on web browser:

  1. username and password;
  2. OAuth( I think email + verification code, phone number + sms code are just another appearance of OAuth);

we have some extra things in authorization on web browser, but normally, they are auth twice.

  1. username and password is good, but the users need to register, login and remember the password, that's tedious.
  2. OAuth is good, but the websites need to apply for an APPID and it may lead to a monopoly. That's not that open.

So, What can we do ?

We can make a private key authorization system built in browser.

Here repeat it:

username and password is good, but it's hard for the users to remember their passwords.

Oauth is good, but it's not really open. Monopoly may happen. In fact, it has happened in China. All people use Tencent Account to log into websites, but apply for an appid is not that easy.

So, why not a new authorization system grabbed the users' hands.

When the people open the browser at first time, the browser will ask people to create or import a private key. Then websites will call a javascript api to use this private key and it's own things(like origin or some static string) to generate a string which can be used as an user_id.

People can export the private key at any time.

With this, people needn't to remember their passwords, needn't to register an account in a website, just click the confirm button. Websites needn't apply for an appid...

The web is totally open now.
domenic commented 6 years ago

Hey, welcome! Please check out https://whatwg.org/faq#adding-new-features. Per that, let's ignore the solution you proposed about private keys, and focus on the problem you're trying to solve.

From what I can tell, the problem you're trying to solve is that registering, logging in, and remembering passwords is tedious, and OAuth as an alternative is centralized. Is that correct?

If so, I suggest you check out https://w3c.github.io/webappsec-credential-management/, which is geared toward solving this problem by making the browser automatically help you register, log in, and automatically remember passwords. It sounds somewhat similar to your proposal, but using usernames and passwords instead of private keys.

xialvjun commented 6 years ago

Then can I export the credentials saved in the browser? Well, it should can, whatever.

Another use case, can the credentials be synced automatically in different device?

With private key, it can cause it just store ononly one private key for all the websites.

Yay295 commented 6 years ago

And how are you planning on getting every website with a login to support private key sign-in?

xialvjun commented 6 years ago

@Yay295 It's not a force. It's just a recommend. Then website follow this recommend will benefit from it.

Just like CDN supplying the javascript libraries.

xialvjun commented 6 years ago

We can treat the private key as the identity of the user on the whole web

annevk commented 6 years ago

That sounds really bad for privacy.

xialvjun commented 6 years ago

what does it have anything to do with privacy? websites can not track the user without user's permission.

annevk commented 6 years ago

I don't think we should have a model where two websites that are otherwise independent can end up with the same key, whether permission was given or not.

xialvjun commented 6 years ago

The private key is always grabbed in the user's hands.

JS API can not get the private key, it can only use the key to generate an identify of their websites...

Different websites have different identities on one person.