Interop has simple credential issuance CLI Demo

[OR13]

Excluding Agents and Hubs, can we show credential signing and verifying using the unviersal resolver and https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/tree/master/packages/es256k-jws-ts

We already have a very similar demo here:

https://github.com/decentralized-identity/well-known/tree/master/did-configuration

The demo should include:

1. DID Creation of Issuer BTCR DID (partially complete and checked in)
2. DID Creation of a Subject (your pick!)
3. Credential creation and signing by issuer.
4. Credential verification using the universal resolver

All private keys used should be statically configured, and no existing keys should be used (for security reasons).

[coder5876]

@OR13 For number 4, this could be created easily using the universal resolver along with the secp256k1 library you mentioned?

For nr 3, the signature would be by a secp256k1 key?

[OR13]

@christianlundkvist yes, these signatures are tested against UPort and others: https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/tree/master/packages/es256k-jws-ts/src/__tests__/interop

Here is create: https://github.com/decentralized-identity/well-known/blob/master/did-configuration/demo/scripts/create_did_configuration.js

Here is verify: https://github.com/decentralized-identity/well-known/blob/master/did-configuration/demo/scripts/verify_did_configuration.js

There can be automatic key conversion from publicKeyHex to publicKeyJwk:

https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/blob/master/packages/es256k-jws-ts/src/keyUtils.spec.ts#L35

[OR13]

I've added a simple cli demo assuming you have already configured your DID with secp256k1 keypair: https://github.com/decentralized-identity/interop-project/tree/master/cli-demo

It is possible to automatically convert publicKeyHex to publicKeyPem, and this may be desirable to add.

The kid format is the JWS default per https://tools.ietf.org/html/rfc7638, however, it can be customized, it is up to the verifier to know how to handle matching the value of kid to a public key in the ddo.

It would be helpful to add scripts to create DIDs for the issuer and subject which would have the correct keys needed to complete this flow.

[awoie]

I support the idea and I think that is doable. I'm happy to contribute did:ethr interop and help with the JWT VCs. uPort already has implementations of the W3C VC spec in Kotlin and JS. We should align on a call.

[OR13]

I've added support for element, and tweaked the VC format, making it easier to drop in UPort's lib or others...

Hopefully the structure is now clearer, and its easier to see how to add your preferred DID Method.

[coder5876]

@OR13 I'm about to build a simple server endpoint for demo purposes, I was considering putting it under a server-demo folder parallel to the cli-demo folder in the interop repo, would that work?

[OR13]

@christianlundkvist yeah, that sounds great!

[coder5876]

@OR13 I noticed that in the CLI tool verified function it expects the key ID to have the format “DID#key-”, instead of just “” is that a bug?

[OR13]

@christianlundkvist

The header for the JWTs is:

{
  "alg": "ES256K",
  "typ": "JWT",
  "kid": "did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw#key-HgGnHUNTnIQ7mIfSlG4VhHsDGNvpoOCOrS9gdeHE4Us"
}

This is one of those things that is not really defined by JOSE / DID....

There is an RFC for JWK Thumbprints (kid) https://tools.ietf.org/html/rfc7638

However, there is no formal spec for how a JWS should reference kid that is managed by a DID and not a web server (to my knowledge).

For OpenID, the kid can be matched to the https://YOUR_DOMAIN/.well-known/jwks.json, where the iss matches YOUR_DOMAIN.

In my opinion, when creating a JWS with a key that is linked to a DID, the kid should be fully specified. In other words, I don't think this should be a bug, but I'm very open to be convinced.

Its worth noting that the kid field does not have to be a thumbprint, it can be whatever, its up to the verifier to know how to retrieve the public key from the JWS and use the retrieved public key to verify. Its for this reason that I think it makes sense to make the kid of this format: did:elem:eURSFEEv6J7s3TJ-jhT_ZS4uGRyCDbwc347EWlqpNgw#key-HgGnHUNTnIQ7mIfSlG4VhHsDGNvpoOCOrS9gdeHE4Us it makes it very clear, how to get the public key.

This is a really excellent question, If there is a standard for this, or you feel strongly that it should be another way, I'm very open to updating it.

[coder5876]

Ok those are good arguments. I’m ok with having the key ID be fully specified with the DID. But in that case this line needs to be updated regarding issuance (it uses the unspecified kid in the header):

https://github.com/decentralized-identity/interop-project/blob/92885b4a810b6f76bbc76d374e4c5d159a936008/cli-demo/src/index.js#L85

Or should the kid in the JWK reference the DID as well (it’s not right now)?

[OR13]

Great catch... next time I will leave the PR open for reviews like this... that is actually dead code, when I refactored I made a common function to be used by all DID methods: https://github.com/decentralized-identity/interop-project/blob/92885b4a810b6f76bbc76d374e4c5d159a936008/cli-demo/src/create-credential.js#L30

[OR13]

Opened https://github.com/decentralized-identity/interop-project/pull/20 to remove the dead code.

[coder5876]

@OR13 Ah gotcha! Ok that's good, I'll make sure to update my own server-side code to use

kid: issuerDid + "#key-" + privateKeyJwk.kid 

to make everything consistent.

[OR13]

I'm going to close this ticket for now.