Identify a user with Github

[LaurenceGA]

Github provides a way to identify developers.
Github already supports hosting public keys (V3 endpoint)

Advantages

Simple easy identity names

Users can be identified by short, simple, human-readable usernames.
Note: they are not stable so the actual stable Github account ID must be resolved.

It's nice to be able to say like gocrev id trust @LaurenceGA.

This can lower the barrier to entry for potential members of the community.

Most developers have a Github identity

Again, quickly lowers a barrier to entry for potential members of the community.
You can even trust someone before they create a CrevID, in case they do later.

Single key and identity dissociation

Github supports multiple keys. So I can sign proofs from multiple different devices with different keys, as long as they're both linked to my Github account. This saves me from having to share these keys across devices. Furthermore, if I lose a key, I can easily transition to a new one without people having to trust my new key, because they already trust my identity.

Easy setup

You can just type gocrev id set-current @me
and we can auto-fetch your keys. You don't have to set a password. People don't always like creating new accounts and having to come up with a new password with produce some deterrent effect.

Easy repository discovery

We can just have a look at the user's repositories and look for a /crev-proofs.
Not fool proof of course, but might help a bit.

Disadvantages

More power to monopoly

Ties many identities to Github, and already huge monopoly. People should have the choice not to have to use a single provider.

Verification more complicated

We have to check all of a user's public keys. This means an API call for each unique user across all proofs.

CrevID is fine

This does require more work to implement. But, cargo-crev is already looking at more type of identity and since go-crev is a new implementation, it's a good opportunity to re-think.

[LaurenceGA]

@dpc so do you think this is a bad idea or....?

From floating the idea in the matrix channel the response seemed generally not-so-keen.

I still think it's a good idea though, so I've tried to write down my thoughts here 🤷

[dpc]

I think @kornelski is already working on being able to do "trust ". However under the hood, everyone gets a crevid.

I think this is a sweet compromise for making life easier for majority of users, while not breaking anything for users of other services.

In cargo-crev, the user will be able to just cargo crev create id <gihtubusername> and get everything set up (including self-generated crevid), and then cargo crev id trust <githubusername> or cargo crev id trust <giturl> for other people. So for most users crevids are just a technicality.

Also, I'd like to point our that the meaning of url: in the id is "here is an url where you should look for updates from me". There shouldn't be too many assumption made about it. Some important things about it:

• url does not have to belong to the person putting it in their proofs; it could be shared / cache aggregator
• url does not have to be a github repo; in the future these could be bittorrent/ipfs etc; it's just right now, in our day and time, it makes sense to make these git repo links to get free hosting and integrate better with something most people have anyway (a public git repo)

[dpc]

BTW. I'm super happy to see go implementation being worked on!

[kornelski]

I've implemented something that is technically GitHub-independent: proving that user owns the URL, and the URL may be a GitHub repo.

1. Whenever a Crev Id signs a proof with their URL we note that we have cryptographic proof for Id->URL relationship.

2. We fetch that URL and look what Crev Ids are there. This verifies URL->Id relationship.

3. When both URL->Id and Id->URL are true, we know this CrevId owns this URL.

This works for any URL, so it works with GitLab, corporate git repos, self-hosted domains, etc.

It doesn't require any other keys, so there's no extra crypto work.

I've also implemented cargo crev trust <URL>, which:

1. Fetches the repo
2. Searches the repo for Crev Ids that claim to have the same URL as the repo
3. Trusts these Ids

To use GitHub-published SSH keys you'd have to require user to prove they have the corresponding private key. SSH supports tons of algorithms, so it'd require crev clients to support tons of algorithms.

So I think establishing ownership of a github URL with existing Crev Id signatures is a simpler solution.

[kornelski]

There are still interesting things that can be done with GitHub API. In my GUI I plan to use GitHub's API to see who user follows on GitHub, check for https://github.com/$followedUser/crev-proofs repos, and suggest to trust them in crev.

[LaurenceGA]

@dpc

In cargo-crev, the user will be able to just cargo crev create id and get everything set up (including self-generated crevid), and then cargo crev id trust or cargo crev id trust for other people. So for most users crevids are just a technicality.

Sounds cool 👍

I think this is a sweet compromise for making life easier for majority of users, while not breaking anything for users of other services.

Right. I think that makes sense for cargo-crev. With go-crev there's nothing much to break right now, so I might forge ahead with Github users as a first-class identity type, but I'll mull it over and experiment a bit.
Cargo-crev will ignore proofs with unknown id-types, right?
I think things will becomes more clear as we go, so I'll try leave it room to evolve when needed.

Also, I'd like to point our that the meaning of url...

Got it. That was my understanding of it too, but good to align 😁

url does not have to be a github repo

Yup, so far I've been building the implementation with this in mind.

[LaurenceGA]

@kornelski

Thanks for the details!

One thing I'm not clear on about proving ownership of a URL:
As @dpc says:

url does not have to belong to the person putting it in their proofs

So does that mean that this is not considering situations where we have aggregators or caches or whatever? Maybe this isn't a problem now...

We fetch that URL and look what Crev Ids are there. This verifies URL->Id relationship.

So we look at whether the URL contains proofs created and signed by the user?
I thought the idea was that proof stores could contain proofs from other IDs in order to promote them or something. Or they could be aggregator stores.

If an aggregator has one of my proofs, then if I put that aggregator's URL in the url field of my ID, would that show as me owning the URL? 🤔

To use GitHub-published SSH keys you'd have to require user to prove they have the corresponding private key.

How so? I thought the point of asymmetric keys is that I can prove the user has the private one by validating one of their signatures using the public one. Or am I missing something? I does mean the user has to point to the key we have to use to sign things and we have to figure that out.

SSH supports tons of algorithms, so it'd require crev clients to support tons of algorithms.

Noted, will think about this 🤔
Go does have a pretty snazzy pure go implementation off SSH

There are still interesting things that can be done with GitHub API. In my GUI I plan to use GitHub's API to see who user follows on GitHub, check for https://github.com/$followedUser/crev-proofs repos, and suggest to trust them in crev.

Cool idea 👏
I might note it down for later 😆

[kornelski]

When you make a review, always include your own URL. Never sign someone else's URL.

Aggregators copy proofs unchanged. They can't change the URL in the proof file, because the URL is signed.

So you know which proofs are aggregated, because URL in the proof does not match the URL you've fetched the proof from.

You can know URL ownership only when the URL you've fetched matches the URL signed inside the proofs you've fetched.

If you fetch example.com/foo and it contains:

crevid1 = evil.com/bar
crevid2 = example.com/foo
crevid3 = example.net/foo

then you know that crevid2 owns example.com/foo, and others are copied/aggregated, and you do not know if they contol these other URLs, or are total fakes.

[dpc]

When you make a review, always include your own URL. Never sign someone else's URL.

I guess that makes sense and most users would do so anyway, but does it restrict signing an aggregator?

Let's say there's team of researchers and they all put their ids into the same repo. Or a a team inside a company. Does everything still holds?

Another one problem that I haven't considered - anyone that is able to get their proofs into an aggregator, will be able to pretend to be the "owner" of that aggregator? Are there any problems lurking there?

[kornelski]

Good point. I suppose currently an aggregator can monitor what it aggregates, and don't take unauthorized proofs claiming its URL.

Should we have something explicit for aggregators that clearly says "I'm an aggregator, these identities are not mine"?

Or a unique location in the repo for the "own" identity?

[dpc]

@kornelski Maybe. I guess aggregators will not really have their own ID anyway, so is there even a point trying to pretend to be them?

I guess we can worry about it once there are actually some aggregators around. :D

[kornelski]

I think we'll need to hash it out eventually. I've created an issue for this: https://github.com/crev-dev/crev/issues/7