I'm unable to compile rebase because it requires some feature missing in SSI. I get the following error:

the package `rebase` depends on `ssi`, with features: `no-cc` but `ssi` does not have these features.

Should a use a specific branch of ssi or rebase?

The ergonomics and dev experience of using rebase-client could be greatly improved with generated type bindings using ts_rs.

This would allow the arguments into the client to be well specified (rather than as they are today, as stringified JSON) and the results to be well-typed as well (again, currently stringified JSON). A lot of work that was done in demo/dapp would also be covered by the use of ts_rs bindings. When starting new dapp projects that use rebase-client, I find I am copying a lot of the type definitions from demo/dapp, and I wish I were instead just using bindings provided from rebase-client.

My proposal would be working from the initial progress in the feat/ts-types-in-client branch which has added the TS as a trait for all public, serializable types, and the new work would be adding the ts(export, export_to = "../../js/rebase-client/bindings/..") in rust/rebase and rust/rebase_witness_sdk, and adding the binding generation step (cargo test) to the build process of rebase-client.

There would likely need to be some work to clean up the naming of some of the types and make sure the output file structure lines up, but from initial experiments, it seems like very little actually needs to be done. In a recent project, I generated the bindings, made some small edits (as a result of serde_json renaming rules that could probably be changed to support this build process), then just dropped them into the app consuming rebase-client and it worked great. I'd like that level of support to be available out of the box.

See error image attached below. Following exact instructions for Rebase demo app, wrangler expects some script file.

There is a flow that is currently supported by the Rebase witness library but is difficult to name. The claim and credentialing flow looks like this:

1. The user provides one key they want to link.
2. The user provides the other key they want to link.
3. Rebase provides a statement based on the two keys provided, unique to those two keys.
4. They user signs the statement with both keys.
5. Rebase validates the signatures and issues a witnessed credential.

There are several issues with the existing UI Flow and naming of this credential. An example of the credential:

{
  "header": {
    "alg": "EdDSA",
    "kid": "did:web:rebasedemokey.pages.dev#controller"
  },
  "payload": {
    "iss": "did:web:rebasedemokey.pages.dev",
    "nbf": 1656100726.405,
    "jti": "urn:uuid:5e16fd22-9271-428a-b4c4-b18ff8c5d433",
    "sub": "did:pkh:eip155:1:0xdA3176d77c04632F2862B14E35bc6B4717FB5016",
    "vc": {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        {
          "id": "https://example.com/id",
          "SelfSignedControl": "https://example.com/SelfSignedControl",
          "SelfSignedControlVerification": {
            "@context": {
              "@protected": true,
              "@version": 1.1,
              "signature_1": "https://example.com/signature_1",
              "signature_2": "https://example.com/signature_2",
              "statement": "https://example.com/statement"
            },
            "@id": "https://example.com/SelfSignedControlVerification"
          },
          "sameAs": "http://schema.org/sameAs"
        }
      ],
      "id": "urn:uuid:5e16fd22-9271-428a-b4c4-b18ff8c5d433",
      "type": [
        "VerifiableCredential",
        "SelfSignedControl"
      ],
      "credentialSubject": {
        "id": "did:pkh:eip155:1:0xdA3176d77c04632F2862B14E35bc6B4717FB5016",
        "sameAs": "did:pkh:eip155:1:0x2CfdC694c436BBb1a7f33db015d40C6AA418C3ff"
      },
      "issuer": "did:web:rebasedemokey.pages.dev",
      "issuanceDate": "2022-06-24T19:58:46.405Z",
      "evidence": {
        "type": [
          "SelfSignedControlVerification"
        ],
        "statement": "I am attesting that Ethereum Address 0xdA3176d77c04632F2862B14E35bc6B4717FB5016 is linked to Ethereum Address 0x2CfdC694c436BBb1a7f33db015d40C6AA418C3ff",
        "signature_1": "0x56e48e0dbca9eebd31b23a69d56be84e8fa359d27e70e62c3999fbe2f43659845cee0d976ff83ed576e556cd8fbc377eeb4a0cb38f6949f9ac8ff6f8794b869f1b",
        "signature_2": "0x4f5448421f13e597f20ccfbe31ba62ab16bacc6ec93654a1131f126005ffd4cc7688c9c74b492e91cb5c795f53351ee87a05dbe32b9e11dde9d6cf3771506a101c"
      }
    }
  },
  "signature": "9_mBsN3r70Ga1BokyCivp87erb86pMA9gprt4eO53WkeIOmoJ3aJZAVJMCP0pdMYLruXP_OWjQkzwoNrlZ2cDw"
}

From a naming perspective, several choices have to be made:

1. What should the credential be called in the UI (currently Self Signed)?
2. What should SelfSignedControl be called?
3. What should SelfSignedControlVerification be called?
4. What should id (the key that corresponds to signature_1) be called?
5. What should sameAs (the key that corresponds to signature_2) be called?
6. What should signature_1 (the signature that corresponds to id) be called?
7. What should signature_2 (the signature that corresponds to sameAs) be called?

The other thing is how should the UI flow work?
Should the user connect both keys before signing?
Should the UI only support the two keys coming from separate providers, and thus selected at the same time?
Or should the UI allow the user to connect 2 keys from the same provider, thus require them to attach them individually?

Ideally, the result of this issue would be a final list of names to apply to the credential (and UI) and a Figma of the ideal UX flow.