Re: DID Hardening: Keys

These same factors may also lead to a different conclusion: that, for at
least this iteration of the DID specification, keys remain purposeless, and
purpose/application are defined at the method spec level or elsewhere.

It seems that introducing either purpose (authorization, issuing) or
application is treading into capabilities, which we've decided we're not
yet ready to include at the DID spec level. So at minimum, we'd have to
ensure we're not carving up the space in ways we'll regret (because they
are harder to maintain, compose, etc.)

To argue with myself, I agree with your points about confusion to
implementors. And perhaps this makes the DID spec pretty useless on its own
(without method specs). However, a counter-argument might be that that
introducing an incomplete concept of purpose confuses things even more for
implementors.

Perhaps that's too extreme -- should the DID spec, at minimum, allow a way
to describe operations on the DID / DID document itself?

Kim

On Sat, Dec 9, 2017 at 9:10 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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/
>
> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group
400 Main Street Building E19-732, Cambridge, MA 02139

kim@learningmachine.com | kimhd@mit.edu
425-652-0150 | LearningMachine.com