Certificate of membership in RChain coop

[dckc]

idea: I write "I, the owner of ethereum account 123, am a member of the RChain coop and my github handle is XYZ" and sign it and publish it on the blockchain. Then a (delegate of) an officer of RChain counter-signs my transaction. Now we have published a certificate of membership.

@kennyrowe do you have experience with that sort of thing? Does the coop have keys / accounts that it uses for such purposes?

I can then use this to authenticate members in apps such as the one in #260 , by using github's OAuth service. If discord has an app to get the member badge, we could use that analagously. Or techniques like keybase.

This of course overlaps with blockchain identity efforts (#254), about which I am woefully ignorant. @jimscarver , @kitblake , @9rb how would you address my "authenticate members from php /js for budget / payment voting" use case with any of the identity technologies you're working with?

[dckc]

@Viraculous why add the M> prefix? Is there some automated process that consumes it?

[lapin7]

A cell calcs M> to Marketing And it's used for bookaccounting purpose

-- Cheers, HJ

On Fri, Feb 2, 2018 at 6:11 PM, Dan Connolly notifications@github.com wrote:

@Viraculous https://github.com/viraculous why add the M> prefix? Is there some automated process that consumes it?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rchain/Members/issues/279#issuecomment-362619930, or mute the thread https://github.com/notifications/unsubscribe-auth/AB0x96CFP7DAzhMBTfLbi-c29dr4jKxaks5tQyu1gaJpZM4R2b9F .

[jimscarver]

This came up in the BYOID identity meeting today with Ed. We prototyped a use case on ethereum that recorded proofs of claims verified by rchain. This stalled with changing users stories and indecision in verifiable claims format and lack of people interested in attending the work study.

It was basically as follows.

1. userid created containing hash of original application data plus random string
2. members email sent to user containing hash.
3. member registers initial eth address by sending hash to contract. register
4. rchain attributes or revokes claims mapped to eth address.

We considered creating or using an existing uPort identity for members and a uPort identity for the coop containing the membership. Lately we have been considering enabling a self-sovereign identity using an rfc725/735 interface.

[dckc]

@jimscarver I recognize some of those words as English, but I don't understand well enough to see how it connects to my PHP app. Care to explain a bit more thoroughly?

[jimscarver]

I don't know what php script you are referring to @dckc Sorry for thew confusion. I was recounting the progress and status of a related effort #16 which I should have mentioned developing MemberIdentity.sol which associated an eth address with members. Proof of membership is one instance of a verifiable claim being addressed by a cooperation on rchain identity #41 in the identity project I'd be happy to meet in zoom to unravel the confusion as needed.

[jimscarver]

Okay, I see I failed to read the issue fully and missed #254 and the auth issue @dckc

We have two logins, the member site and discord for each member. You can use Oauth2 to use discord as an identity provider and insure they are members there. @drbloom may know about using the member site login as an identity provider.

Is there a reason for the user to use ethereum in your script?

[dckc]

Thanks for confirming that discord does OAuth2. That's a pragmatic short-term solution.

But yes, there's a reason to use ethereum or RChain: discord is part of the Social Media Strangle Hold:

There's a strangle-hold on social media today; people don't get a chance to participate in the economic proposition in an equitable way. -- Greg Meredith, Jan 2017

[dckc]

I just (re-) discovered https://github.com/Jake-Gillberg/git-vote ; cool! @Jake-Gillberg any thoughts on this certificate issue?

[ghost]

@dckc That is awesome! But then.... does one need ETH to vote?

[dckc]

We could require RHOC, I suppose.

I'm not sure which situations that tool would apply to, but it demonstrates some very interesting integration between chrome and the blockchain and such.

[ghost]

@dckc I don't think paying to vote is a good idea.

MetaMask is awesome in that I guess.

[Jake-Gillberg]

I agree that we should have some sort of member registry. My current extension allows anyone with RHOCs to vote, regardless of member status. (I would like to modify this extension to use a member registry where each member gets a total weight of 100 to vote with, that they can distribute [and redistribute] among github issues).

In terms of payment, it seems to make sense to me that the member fee would be used to insert a member into this registry.

It might also make sense to replicate this registry on well known ethereum testnet(s) that we could use for non mission-critical-apps (possibly like the github voting extension) that could be used for free.

The member registry could be as simple as a solidity contract that holds an array of verified member addresses (controlled by some group), or much, much more complex. Here is a good blog post about different identity approaches (written by uPort): https://medium.com/uport/different-approaches-to-ethereum-identity-standards-a09488347c87

[dckc]

I think I have fallen into the NBAC mindset here. A ZBAC (capability security) approach is really what I want.

• From ABAC to ZBAC: The Evolution of Access Control Models
  Alan H. Karp, Harry Haury, Michael H. Davis
  HP Laboratories HPL-2009-30
• https://github.com/dckc/awesome-ocap

[dckc]

just re-discovered:

We're migrating to RocketChat, we  foss & they're integrating w @TokenlyInc for token-controlled access, join us! https://chat.alexandria.io -- https://twitter.com/alexandria/status/922559749282865152

[Jake-Gillberg]

Well, I guess I'll jot some stuff down since I am assigned.

As I understand it, there are currently two ways to identify a member:

1. The "Official" discord channel, where a user has a ":" following their name and the "member:" (distinct from "member") tag. (it sounds like there may be a way to extract that info to a more traditional OAuth2 scenario, via discord-reading-bot and discords oauth service.)
2. The RChain Coop Member database, uncertain about the format of this info @drbloom, what info is stored here?

Potential Requirements:

• On-Chain Member Verification:

Today I talked with @kdvalentine about the need for member verification on the blockchain. Coop partners may wish (or be required) to offer their tokens to RChain cooperative members first. With low overhead, a smart contract could automatically open up the sale of a token to cooperative members. Our partners (according to Kevin) may also be able to take advantage of the fact that RChain members have gone through a KYC process.

On-chain member verification would also facilitate the emergence of coop organization tools. For instance: https://github.com/Jake-Gillberg/git-vote could be modified for a fairer voting mechanism (each member gets equal voting weight). This could also be a tie-in for methods of member-to-board communication that require X% or X# of members to sign a document.

• Differentiation between "Active" and non-active member

[dckc]

Further to ...

A ZBAC (capability security) approach is really what I want.

Perhaps Proof of Purchase is the relevant capability pattern. Unfortunately, I don't see code to implement it there. But code is given for related patterns such as claim check and Notary/Inspector.

[dckc]

More on capability security in rchain:

• Simple purse in Rholang #357
• Secure design patterns section* of the rholang tutorial

*grr... whose idea was it to use some funky javascript thing that isn't bookmarkable to navigate sections?

[dckc]

progress: https://gist.github.com/dckc/2cbeb9397f1284105ff2dd8691ae0d5d

Thanks, @Jake-Gillberg

[Jake-Gillberg]

Not sure that the pattern proposed by @dckc above is the right one: Copy paste from discord discussion with Dan:

It doesn't seem to allow the coop to revoke membership..

"just compose with revokable forwarder (aka caretaker) then?"

Hmm. where does the revokable forwarder go? My impression is that the pattern was: people with "certificate creation" access to the "certificate authority" object can create a new "certificate" object, which can be verified to to be issued by the "certificate authority" via a publicly available "check certificate" object of the "certificate authority" In order for the "check certificate" object to be able to revoke a once-valid "certificate", it needs to retain a memory of issued (still valid) certificates(edited) which then, why are the certificates separate objects to begin with?

[dckc]

While discussing with @JoshOrndorff about a process for allocating repositories under https://github.com/rchain/ , it occurred to me that with RSign (#956) mostly working, I could combine that with earlier discord integration work (#413 ) to connect discord identities to on-chain public keys.

It's going reasonably well:

2018-09-28 11:19 PM rchain-dbr 22c6c95 o2r: Membership Certificate request: front end 2018-09-28 09:23 PM rchain-dbr 34a5c9b o2r: more RChain-API catch-up 2018-09-28 12:58 PM rchain-dbr 8588f69 o2r: Discord role check 2018-09-28 02:11 AM rchain-dbr 6349caa o2r: discord role check (WIP) 2018-09-27 06:11 PM rchain-dbr abddb9f o2r: fix discord scope: identify, not identity 2018-09-27 11:24 AM rchain-dbr 0dac66f o2r: catch up with RChain-API, aided by flowtype 2018-09-27 11:22 AM rchain-dbr 55bc3d2 o2r: rholang / RHOCore string interpolation support 2018-09-27 11:22 AM rchain-dbr a7b7986 o2r: static types for express, from flow-type install 2018-09-26 09:47 PM rchain-dbr 7d14103 o2r: airbnb lint style 2018-09-26 08:58 PM rchain-dbr 7211301 Merge branch 'viz_flow'

https://github.com/dckc/rchain-dbr/tree/oauth_gateway

[dckc]

Hmm... I wonder about interop with uPort.

Oh... and lifeID, of course.

[dckc]

recent work... perhaps not self-explanatory...

2018-10-21      09:56 PM        RChain-API      74b6c1d signing: type annotations (for strict)
2018-10-20      08:13 PM        RChain-API      464009f liveRHOCoreTests: check toByteArray() using rnode

2018-10-20      10:29 PM        RSign   45a9971 v0.7.1 to sync with rnode release

2018-10-21      10:37 PM        rchain-dbr      b260568 o2r: good sig for membership.rho testing
2018-10-21      10:36 PM        rchain-dbr      1a33f16 On oauth_gateway: good sig
2018-10-21      10:23 PM        rchain-dbr      cfd79cd o2r: look up discord server, role names