Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blockstack auth hard to find #148

Open
larrysalibra opened this issue Sep 3, 2019 · 9 comments

Comments

@larrysalibra
Copy link
Member

commented Sep 3, 2019

As I wrote in my post on the death of Jabber, it is critical to our success that users form a strong mental model of Blockstack ID & Blockstack Auth. In our current app mining set, every app uses a different method of presenting Sign in with Blockstack. Some apps use a branded button that mentions Blockstack. Other apps use language such as "get started." This lack of consistency doesn't help us in building this mental model. In the current state, users can't have some basic expectation of what to look for if they want the benefits of a Blockstack app.

Proposal: We develop a set of branding, button placement and language requirements so that Sign in with Blockstack is presented consistently across apps and incorporate this into the review process.

@friedger

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2019

The guidelines should distinguish between landing/product page and first page of the app.

See also #100

@Walterion1

This comment has been minimized.

Copy link

commented Sep 3, 2019

@jeffdomke As we worked on apps and heard their voice about how they want such a thing. If you like, we will be happy to make a design proposal as a concept for this issue.

@dantrevino

This comment has been minimized.

Copy link

commented Sep 3, 2019

Jasper has already made some signin buttons: https://www.dropbox.com/sh/5uyhon1dxax4t6t/AABnh34kFRzD2TSck1wE9fmqa?dl=0

We would likely just need to supplement these with Android and iOS variants.

@friedger

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2019

Reading through the post, I understand that this issue is about raising awareness for the concept of decentralized identity and authentication and storage. Shouldn't we promote the concept of DIDs in general instead of the specific ID provided through Blockstack?

We should make the branding such that users that visited e.g. https://www.microsoft.com/ownyouridentity don't need any more explanation when visiting a Blockstack app.

@kkomaz

This comment has been minimized.

Copy link

commented Sep 9, 2019

Shouldn't we promote the concept of DIDs in general instead of the specific ID provided through Blockstack?

To echo what @friedger is saying... What are we trying to accomplish with this proposal?

As an independent reviewer shouldn't the criteria be focused on making sure apps are utilizing gaia in a meaningful way and creating a decentralized identity?

This seems more like a branding of Blockstack identity vs. decentralized identity debate. It would be great to clarify what the actual issue is and what we're trying to accomplish.

To me, as long as user creates a DID in any form possible, we satisfy the NIL requirement. If you're requiring we need to say "Blockstack" in our authentication process flow, a better explanation on what those benefits are would be greatly appreciated. There are apps that currently exist that have multiple authentication flows so to label as "Blockstack Apps" wouldn't be fair.

@larrysalibra

This comment has been minimized.

Copy link
Member Author

commented Sep 10, 2019

I understand that this issue is about raising awareness for the concept of decentralized identity and authentication and storage

No, the goal is raising awareness for Blockstack ID - a specific decentralized identity standard and Gaia, a specific storage standard.

Shouldn't we promote the concept of DIDs in general instead of the specific ID provided through Blockstack?

as long as user creates a DID in any form possible

You don't build interoperable networks and systems based on general concepts - constraints define a system.

A user or app developer given an arbitrary DID can't do anything unless a bunch of other components exist. A user given a Blockstack ID can sign into an app that supports Blockstack Auth.

@friedger

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

You don't build interoperable networks and systems based on general concepts - constraints define a system.

@larrysalibra To make it more concrete, are you saying we shouldn't teach users about DIDs (=email), but only about Blockstack (=Gmail)?

I would like to teach users that if they sign up for blockstack they create an identity that they can use for encrypting and storing their data. And this will also hold for other DID providers that connect to identity hubs.

@jcnelson

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

No, the goal is raising awareness for Blockstack ID - a specific decentralized identity standard and Gaia, a specific storage standard.

I second this.

@larrysalibra To make it more concrete, are you saying we shouldn't teach users about DIDs (=email), but only about Blockstack (=Gmail)?

It's the DIF's responsibility to raise awareness of DIDs, not ours. However, Blockstack helps the DIF in this manner. Blockstack sits on the DIF steering committee and supplies a standards-compliant DID specification and implementation to the DIF (and now the W3C). The folks who maintain Blockstack Core will continue to support the Blockstack DID specification for the foreseeable future, and will do their best to comply with the standards as they evolve.

I would like to teach users that if they sign up for blockstack they create an identity that they can use for encrypting and storing their data. And this will also hold for other DID providers that connect to identity hubs.

This is not true for all DID methods. The DID spec does not require that the DDO or any associated user data be encrypted at all, nor stored on user-controlled hosts. In fact, the DID spec paradoxically does not require the DID to be maintained on a decentralized public ledger (it may be maintained on a "permissioned" ledger, and may even be maintained via DNS or some other centralized issuer), nor does the DID spec describe how or even if the DID's history is made available.

The Blockstack auth protocol and reference implementation go above and beyond what is mandated by the DID specification -- both by mandating at the protocol level that users choose where the authoritative replicas of their data (i.e. DDO and such) are stored, and by providing straightforward APIs to encrypt and decrypt data end-to-end.

@friedger

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

From the above discussion it becomes clear that this issue is about "Branding with Blockstack".

If you're requiring we need to say "Blockstack" in our authentication process flow, a better explanation on what those benefits are would be greatly appreciated.

DID auth is not well defined and the current understanding is that it is a challenge-response protocol, i.e. uses a server. Hence, the main benefit in using Blockstack auth is that the authentication flow works offline (once you have the app code) and that the result of the auth flow is the user profile and a private key that only this user can generate.

Some ideas to clarify/simplify the review:

  • parts of the application that do not require authentication are not reviewed
  • the app shall have a button with the blockstack icon and label "Choose Blockstack ID". The design of the button shall follow the design given in https://www.dropbox.com/sh/5uyhon1dxax4t6t/AABnh34kFRzD2TSck1wE9fmqa?dl=0
  • from start url (as defined in the web manifest) the button shall be reached in at most two clicks/touchs
  • the app shall have a button with label "Forget Blockstack ID"
  • if the landing page (as defined for product hand) is different to the start url the landing page shall have a button "Start with Blockstack"

Notes:
A button can also be a menu or clickable text.
Localization of labels are supported and encouraged.

The reviewer will give different score for

  • fully compliant apps
  • compliant apps with minor issues
  • compliant apps with major issues

Non-compliant apps are not eligible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.