kord-network / kord-guardian-examples Goto Github PK

Using the Keybase API sig/post_auth method.

How can the process of developing a KORD Guardian micro-service be simplified for identity providers that may not have existing infrastructure to verify claims, or the resource to build it?

With this in mind, we should explore available tools and projects that assist the creation of OAuth2 servers and whether a lightweight solution can be provided in the above scenario:

• https://github.com/ory/hydra
• https://github.com/oauthjs/node-oauth2-server
• https://godoc.org/golang.org/x/oauth2

• Clone MICS template
• claim: pplId
• Mock verification of provided pplId

• Twitter OAuth
• Optional: Use the Keybase strategy of tweeting your META-ID
• Maybe try out TLS Notary

• Clone MICS template
• claim: twitterid
• extraData: { accessToken: String }
• Verify accessToken by attempting GET account/verify_credentials request
• Verify provided twitterScreenName matches returned screen_name

Change claims => identity claims everywhere (docs, code, repo, package.json etc)

Once library is published to NPM

• verifyIdentityClaim => https://github.com/meta-network/meta-claims-service/blob/master/index.js#L33-L53
• createMetaIdentityClaimObject => https://github.com/meta-network/meta-claims-service/blob/master/index.js#L70-L95

https://github.com/meta-network/meta.js

• Architecture (with diagram)
• How to write a META Identity Claims Service:
  • Start with template
  • Customise with verification
  • Deploy (plus .env config)

• Outline a proposal for a META Identity Claims Service marketplace

Problem
Currently, the META Identity Claims Services that are available to participants in the META Network are maintained at application level ie. the place where they are consumed. For example, the META ID dapp provides an interface to all of the current claims services by maintaining a list of services, some data about each service and the URL to send a verification request to. If another dapp wants to offer a similar interface, it too will have to maintain a similar list. Additionally, whenever new claims services are created they must ask the developers of those dapps to add their service.

Solution
The problems of registering new claims services and maintaining an accurate record of the available services can be solved by introducing a 'marketplace' for claims services to the META network. This marketplace would have an API that allows clients to write and read to the underlying dataset. The API would need to have access control rules, particularly around writes. It could be accessed via an ENS record that points to the latest hash available eg. marketplace.id.meta.

• Should return appropriate error object

• Clone MICS template
• claim: dpid
• Convert companies.xml to JSON
• Lookup claimed dpid in registry

Example:

<DpidOwner SequenceNumber="3028">
  <DPID>PADPIDA20170807093</DPID>
  <CompanyName>JAAK Music LTD</CompanyName>
  <Address>41 Corsham Street, London, N1 6DR, United Kingdom</Address>
</DpidOwner>

• Add micro-devdependency
• Remove nodemon dependency
• Update start script for template and examples

From:

"start": "nodemon --exec micro -p 7000",

to:

"start": "micro-dev -p 7000",