- From: Kim Hamilton Duffy <kim@learningmachine.com>
- Date: Sun, 10 Dec 2017 04:04:17 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAB=TY87TQoFZiKJ6C0uAB0Y8cWRS=4t2YsvMW1vmL2v=kQdccw@mail.gmail.com>
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
Received on Sunday, 10 December 2017 04:04:58 UTC