Leverage existing RFC7517 to specify cryptographic key

[AxelNennker]

Why not use RFC7517 in the DID spec when cryptographic keys are described as authorizationCapability?

So instead of

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authorizationCapability": [{
    // this entity may update any field in this DID Document using any
    // authentication mechanism understood by the ledger
    "permission": "UpdateDidDocument",
    "entity": "did:example:123456789abcdefghi"
  }],
  "exampleService": "https://example.com/messages/8377464",
  "authenticationCredential": [{
    // this key can be used to authenticate as DID ...9938
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }]
}

write something like

```json
{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authorizationCapability": [{
    // this entity may update any field in this DID Document using any
    // authentication mechanism understood by the ledger
    "permission": "UpdateDidDocument",
    "entity": "did:example:123456789abcdefghi"
  }],
  "exampleService": "https://example.com/messages/8377464",
  "authenticationCredential": [{
    // this key can be used to authenticate as DID ...9938
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:123456789abcdefghi",
    "key": {"kty":"RSA",
          "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
          "e":"AQAB",
          "alg":"RS256",
          "kid":"2011-04-29"
     }
  }]
}

Or extend jwk to include owner as id might equal kid and type equals kty...

You probably already considered this... 
Maybe you could use this issue to document the reasoning?

[msporny]

We should talk about general usage of JOSE, JWS, and JWK in the DID specs at RWoT6. We do use JWS for signatures and leave the option open to use JWK for key descriptions (although, know of no implementations that do this in practice).

[msporny]

We discussed this with the only implementer that is currently using JWK and they plan to move away from using JWK. This leaves zero implementers that are using JWK to describe keys (preferirng to use base58 encoding or standard PEM encoding over JWK). The spec doesn't forbid the use of JWK and all that is needed is for an implementer to come along and write up a spec for doing so in the DID spec.

To resolve this issue, we will submit a PR for the spec stating this as the current state of affairs and the reasons that developers decided to not use JWK for their implementations.

[msporny]

Update on this. A few of us got together at IIW26 and the uPort developers might use JWK to describe their keys. They will need to push a few specs/registrations through IETF, but once they get those through, I think they're going to try to express Ethereum keys using JWK. At present, I don't know of any other implementation that plans to do that.

[msporny]

@talltree to assign @ChristianLundkvist to this issue.

[csuwildcat]

Hey guys, this would really help us out - can we use the existing JW_ related stuff wherever possible?

[msporny]

can we use the existing JW_ related stuff wherever possible?

We are already using JWS for the signatures where we can. uPort took an action item to get the IETF stuff done for secp256k1 (which I think is going to be painful, but Mike Jones seems to think that it won't be)... which will allow them to use JWK for key description formats. They're also going to be experimenting w/ using JWTs... there are serious technical issues wrt. a variety of the Verifiable Credential use cases that we've identified over the years, but we've let them know and it's up to them to figure out if there is a way around those.

this would really help us out

Can you elaborate in what way it would help you out?

[jandrieu]

Closing as we have adopted this issue in the new DIDWG repo.