DID Hardening: Keys

There is currently a proposal on the table to change the
"authenticationCredential/authenticationMaterial" field, which contains
keys and other biometric information used for the purposes of
authentication to "keys". The arguments for/against were documented
during the last call here:

https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit#

After exploring the discussion we had during last weeks DID Hardening
call, Dave and I think we've identified the crux of the issue:

There is an expectation that key type, or key type and purpose, are
sufficient for describing what a key can be used for. This is a false
expectation, and here is why:

At present, key type looks like this:

   type: "RsaCryptographicKey"

There has been a suggestion to add a "purpose" field, like so:

   cryptographicPurpose: "Signing"

So, given those two values in a key description:

{
   type: "RsaCryptographicKey"
   cryptographicPurpose: "Signing"
   ...
}

Do you know that a user can authenticate with that key? I assert that
you don't. So, we need to change the key to be for authentication:

{
   type: "RsaCryptographicKey"
   cryptographicPurpose: "Authentication"
   ...
}

... but this is strange. All you can really do with keys are "sign" and
"encrypt". Even biometric material can only be used to "verify". We can
say "authentication", but that's just signing or verifying when you get
down to the cryptographic operation.

Even if we say "Authentication", you have no idea in what application
domain you can use that key for authentication. Do we mean website
authentication, restricted physical area authentication, or "launch the
nukes" authentication? We're concerned about a developer messing that up.

So, even if we do this:

"keys": [{
  type: "RsaCryptographicKey"
  cryptographicPurpose: "Signing"
  cryptographicApplication: "DIDAuthentication"
  ...
}, {
  type: "RsaCryptographicKey"
  cryptographicPurpose: "Signing"
  cryptographicApplication: "VerifiableCredentialIssuing"
  ...
}, ...]

There is a non-trivial risk that a developer will not fully understand
the spec and use a key for issuing to authenticate a user and use a key
for authentication to verify a signature.

Proposals should take these three things into consideration, and it
seems like the "keys" proposal only takes two of them into account, at
most. Thus, we'd prefer to see something that makes the key type,
purpose, and application clear AND something that makes it much harder
for developers to screw up an implementation to use the wrong key for
the wrong purpose. Thus:

"authenticationMaterial": [{
  type: "RsaCryptographicKey"
  cryptographicPurpose: "Signing"
  ...
}, ...],
"issuingMaterial": {
  type: "RsaCryptographicKey"
  cryptographicPurpose: "Signing"
  ...
}, ...]

The structure above is much harder to screw up and addresses all four of
our concerns.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The State of W3C Web Payments in 2017
http://manu.sporny.org/2017/w3c-web-payments/

Received on Saturday, 9 December 2017 17:08:17 UTC