Login with OAuth provider

[erlend-sh]

I understand that Chatter Net’s DID-based accounts is a key part of its offering as a user-owned platform. I truly believe it has the potential potential to be my default online identity provider in the future.

However, the bulk of my online identity is currently tied up with the likes of Google and GitHub. For many of my friends it’s things like Facebook and Instagram.

I’m not gonna be able to onboard regular internet users to join me on Conversely/CN unless there’s a simple migration path from the status quo of the dominant Web 2.0 platforms.

Matrix recognized this as well, resulting in a major transition towards OIDC support: https://areweoidcyet.com/

..incidentally, they also have an example of how to log in with Mastodon OAuth: https://matrix-org.github.io/synapse/latest/openid.html#mastodon

I propose a completely optional login path for users who wanna start off on Conversely by authenticating with their favorite ‘social login’ provider.

For example via:

https://github.com/ory/kratos https://github.com/ory/kratos-client-rust

https://github.com/zitadel/zitadel https://github.com/smartive/zitadel-rust

[gmcgoldr]

I did a round trip trying to figure out which repository this belongs to.

I would write the expected outcome as follows: a user can log into Conversely using OAuth 2.0 credentials. At first I thought this is a Chatter Net wide issue, but now I think this is a choice apps on Chatter Net can make for themselves.

I can see two needs that this can address. If you can think of others please let me know:

1. A new user comes to Conversely, they get a default account, want to secure the account, so they must make a password. They are now managing one extra password. This could turn people off of the platform.
2. A new user comes to Conversely, they are seeing accounts they recognize, but don't know if they can trust them. If those accounts were linked with some external ID, it would make it easier to search and discover contact.

These two points will require different solutions.

Private key store

This would require a server which stores user's private keys, and sends it to them if they can prove their identity using OIDC. The tech to build this in rust is mature and accessible, so I think an implementation could be reached relatively quickly. Handling secrets for a user does come with a very high bar though, so maintaining this server could be a bit of a burden (it would be an appealing target for hackers).

Platforms which use such a private key store and don't allow the user to see their private key are effectively bypassing the decentralized identity mechanism of Chatter Net. It's basically DID over OAuth at this point. However, this could be an effective tool to onboard new users. So I think it's an appealing project.

Associating external credentials to a DID

This would require a server which would accept a request for verification from a user with a DID. The user would authenticate with the server using OIDC. The server would then send challenge data to the user and the user would have to sign that data. Once the server sees the DID has been used to sign the data, it knows that the person controlling the DID is the same one who authenticated using OIDC. The server can then sign a message (lets call it an attestation) links some information about the external account (e.g. email address) to the DID.

The reason this needs to happen on a server is that users will need to trust the server to know that the attestations aren't just generated without doing any OIDC verification. This has the unfortunate consequence that whoever controls the server can emit false information, and can restrict the service. However, there is nothing stopping many such services from existing, so none can monopolize a user's identity.

[erlend-sh]

At first I thought this is a Chatter Net wide issue, but now I think this is a choice apps on Chatter Net can make for themselves.

That’s right. I see this as an entirely opt-in convenience feature that is up to each individual CN instance to provide as an option for users.

Handling secrets for a user does come with a very high bar though, so maintaining this server could be a bit of a burden (it would be an appealing target for hackers).

That’s why the recommended approach to offer this kind of utility add-on should IMO be to outsource it entirely to a trusted 3rd party like the Ory Network.

I don’t need the DID to be an identity-container that only I and I alone control. The power of the DID for me is identity-portability, I.e. credible exit.

Platforms which use such a private key store and don't allow the user to see their private key are effectively bypassing the decentralized identity mechanism of Chatter Net.

Why wouldn’t the platform allow the user to see their private key though? I would not use a platform that kept my private key from me. I just want them to have a copy of it in their vault as a redundancy measure.

It's basically DID over OAuth at this point. However, this could be an effective tool to onboard new users. So I think it's an appealing project.

Exactly. The thing is, my self-sovereign DID-based identity is kinda worthless until it’s been in active use for a while, with an increasing amount of content and relationships tied to it. Once it has become valuable to me, I may opt to decouple it from the 3rd party safe-keeping service and start managing it completely independently.

That said, I think I would personally always want some sort of backup-service involved, for the same reason I’m in no hurry to move my money from my local, highly regulated bank to a USB drive in drawer somewhere.