Authentication using Handshake name #6

Falci · 2020-10-26T10:09:43Z

This HIP describe how to authenticate a user using his/her Handshake name.

Falci · 2020-10-26T11:28:34Z

I'd like to request a special attention to the Exposing the public key section. It's totally arbitrary

zfogg · 2020-10-27T06:53:26Z

this is awesome. do none of the commonly used .well-known/ services work for this? i'm surprised there isn't an ietf rfc that implements something like this already

Falci · 2020-10-27T07:59:18Z

I checked the Wikipedia list and the IANA list but I didn't spot anything that could be used instead.

Falci · 2020-10-28T16:42:25Z

What would you prefer?

web+hns://authentication/?challenge=<CHALLENGE>&callback=<CALLBACK>
web+authentication://<CHALLENGE>@<CALLBACK>
web+auth://<CHALLENGE>@<CALLBACK>
Other?

zfogg · 2020-10-28T19:50:05Z

@Falci I suppose if there's nothing particularly Handshake specific about the implementation, then other projects could implement it or be compatible with it as well; no need to include "hns" in the spec unless hns is actually required for it to work and it won't work without hns, you know? so the second option looks the best to me, although the third option is most aesthetically pleasing.
i say number 2!

brandondees · 2020-10-30T18:50:50Z

@Falci I vote definitely not the prefix for 1, as this scheme is orthogonal to HNS. i think there is prior art that would collide with 2 and 3 so maybe some more homework is in order before committing to the protocol handler side of it. assuming there's no conflict or confusion with other schemes, web+authentication is less ambiguous. i'm not sure about the @ which already implies email addresses and could be confusing. the query string format seems like it would be conventional and flexible. again, i'd suggest digging through all the existing standards for this type of scheme first to avoid conflicting approaches or re-discovering issues that have already been figured out by other teams.

i understand that there may be nothing already on the .well-known lists, but there are definitely tons of existing auth protocols including ones with challenge-response modes, redirect callbacks, and special protocol handler schemes, many of which could probably be informative for these design choices.

Falci · 2021-02-08T19:10:27Z

Just to keep track: this should be merged as HIP-0003

Falci · 2021-06-11T08:36:11Z

Does this HIP still make sense after the handshake-org/hsd/pull/609 ?

pinheadmz · 2021-06-11T13:21:11Z

@Falci I think so, it's different things. Users will likely want to store names on hardware wallets and name authentication may be a situation where they want to use a different set of keys, or rotate the keys more frequently, etc.

NetOpWibby · 2021-11-22T01:54:33Z

Is there a(n optional) way to use a hardware wallet as part of the authentication scheme?

NetOpWibby

Some grammar updates and removing gender.

NetOpWibby · 2021-11-22T01:59:16Z

HIP-0003.md

+
+## Abstract
+
+This HIP describe how to authenticate a user using his/her Handshake name.


This HIP describes how to authenticate a user using their Handshake name.

NetOpWibby · 2021-11-22T02:01:41Z

HIP-0003.md

+
+## Motivation
+
+Many websites need to identify the user and proof he/she owns a Handshake name. Many other websites simply need to identify users, which forces them to go into a process to pick a unique username that most of the time can't be consistent across different apps. By using Handshake names as username it allows both: proof ownership of the name and consistent username across unrelated apps.


Many websites need to identify the user and prove they own a Handshake name. Other websites simply need to identify users, which forces the user to enter a process of picking a unique username that most of the time can't be consistent across different apps. Using Handshake names as usernames allows both to happen: prove ownership of a name and have a consistent username across unrelated apps.

NetOpWibby · 2021-11-22T02:03:30Z

HIP-0003.md

+
+The basics of this protocol consist of a public and private ECDSA key. The domain exposes the public key via HTTPS request.
+The Service that wants to authenticate the user should provide this user with a unique challenge.
+The User signs the challenge using his/her private key and returns it to the Service, among the public key and the domain name.


The User signs the challenge using their private key and returns it to the Service, along with the public key and domain name.

NetOpWibby · 2021-11-22T02:04:36Z

HIP-0003.md

+The basics of this protocol consist of a public and private ECDSA key. The domain exposes the public key via HTTPS request.
+The Service that wants to authenticate the user should provide this user with a unique challenge.
+The User signs the challenge using his/her private key and returns it to the Service, among the public key and the domain name.
+The Service then validates if the challenge is correct and was correct signed. The Service also validates if the domain name indeed exposes that public key.


The Service then confirms the challenge is correctly signed. The Service also validates if the domain name indeed exposes the public key.

NetOpWibby · 2021-11-22T02:05:40Z

HIP-0003.md

+
+### Provider
+
+The above-mentioned flow requires an extra piece of software: a user-trusted provider. This provider knows/holds the user's private key. It can run on the client-side, as a browser extension or an installed app; or it can run remotely as a regular web service.


The above-mentioned flow requires an extra piece of software: a user-trusted provider. This provider knows/holds the user's private key. It can run client-side, as a browser extension, as an installed app, or run remotely as a regular web service.

NetOpWibby · 2021-11-22T02:12:04Z

HIP-0003.md

+When the Service is called via its callback URL, it should do the following verifications:
+
+-   Check if the domain exposes a public key.
+-   Check if the challenge is the same challenge from the request.


Verify the challenge is identical from the request.

NetOpWibby · 2021-11-22T02:12:49Z

HIP-0003.md

+
+When the Service is called via its callback URL, it should do the following verifications:
+
+-   Check if the domain exposes a public key.


Verify the domain exposes a public key.

NetOpWibby · 2021-11-22T02:13:28Z

HIP-0003.md

+
+-   Check if the domain exposes a public key.
+-   Check if the challenge is the same challenge from the request.
+-   Verify if the signature is valid (using the already retrieved public key).


Verify the signature is valid (using the already retrieved public key).

NetOpWibby · 2021-11-22T02:14:07Z

HIP-0003.md

+
+Note: there's no point in adding the public key in the response from the Provider to the Service since it won't be trusted.
+
+Once all verifications are complete, the Service can use the `domain` to identify the current user.


Once all verifications are complete, the Service can use the domain to identify the current User.

NetOpWibby · 2021-11-22T02:14:49Z

HIP-0003.md

+This proposal does not force the domain name to be a TLD. Users could authenticate themselves with `support.example` for instance.
+
+There's no need to be strict with a Handshake domain name. Users could authenticate themselves with `example.com` for instance.
+


Additionally, there's no need to be strict with a Handshake domain name. Users could authenticate themselves with example.com.

Falci and others added 2 commits October 26, 2020 11:07

Authentication using Handshake name

6d218db

Grammar check

e55062c

Falci marked this pull request as draft January 21, 2021 15:22

Assign HIP number

92aff84

handshake-org deleted a comment from Abhishek5772705 Jun 5, 2021

NetOpWibby suggested changes Nov 22, 2021

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Authentication using Handshake name #6

Authentication using Handshake name #6

Falci commented Oct 26, 2020 •

edited

Loading

Falci commented Oct 26, 2020

zfogg commented Oct 27, 2020 •

edited

Loading

Falci commented Oct 27, 2020 •

edited

Loading

Falci commented Oct 28, 2020 •

edited

Loading

zfogg commented Oct 28, 2020

brandondees commented Oct 30, 2020

Falci commented Feb 8, 2021

Falci commented Jun 11, 2021

pinheadmz commented Jun 11, 2021

NetOpWibby commented Nov 22, 2021 •

edited

Loading

NetOpWibby left a comment

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021

NetOpWibby Nov 22, 2021


		## Abstract

		This HIP describe how to authenticate a user using his/her Handshake name.


		## Motivation

		Many websites need to identify the user and proof he/she owns a Handshake name. Many other websites simply need to identify users, which forces them to go into a process to pick a unique username that most of the time can't be consistent across different apps. By using Handshake names as username it allows both: proof ownership of the name and consistent username across unrelated apps.


		### Provider

		The above-mentioned flow requires an extra piece of software: a user-trusted provider. This provider knows/holds the user's private key. It can run on the client-side, as a browser extension or an installed app; or it can run remotely as a regular web service.


		When the Service is called via its callback URL, it should do the following verifications:

		- Check if the domain exposes a public key.


		Note: there's no point in adding the public key in the response from the Provider to the Service since it won't be trusted.

		Once all verifications are complete, the Service can use the `domain` to identify the current user.

		This proposal does not force the domain name to be a TLD. Users could authenticate themselves with `support.example` for instance.

		There's no need to be strict with a Handshake domain name. Users could authenticate themselves with `example.com` for instance.

Authentication using Handshake name #6

Are you sure you want to change the base?

Authentication using Handshake name #6

Conversation

Falci commented Oct 26, 2020 • edited Loading

Falci commented Oct 26, 2020

zfogg commented Oct 27, 2020 • edited Loading

Falci commented Oct 27, 2020 • edited Loading

Falci commented Oct 28, 2020 • edited Loading

zfogg commented Oct 28, 2020

brandondees commented Oct 30, 2020

Falci commented Feb 8, 2021

Falci commented Jun 11, 2021

pinheadmz commented Jun 11, 2021

NetOpWibby commented Nov 22, 2021 • edited Loading

NetOpWibby left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Falci commented Oct 26, 2020 •

edited

Loading

zfogg commented Oct 27, 2020 •

edited

Loading

Falci commented Oct 27, 2020 •

edited

Loading

Falci commented Oct 28, 2020 •

edited

Loading

NetOpWibby commented Nov 22, 2021 •

edited

Loading