W3C home > Mailing lists > Public > public-credentials@w3.org > June 2020

Re: DHS SVIP Blockchain/DLT/SSI Cohort - Multi-Product Phase 1 Interop Artifacts/ Scaffolding / Information

From: Orie Steele <orie@transmute.industries>
Date: Fri, 12 Jun 2020 12:00:19 -0500
Message-ID: <CAN8C-_+5Db=z6Cf1-hU7JYb=2kLNf4Em_dyodbcJiPLppK+v2g@mail.gmail.com>
To: Daniel Hardman <daniel.hardman@evernym.com>
Cc: Dan Bolser <dan@geromics.co.uk>, "John, Anil" <anil.john@hq.dhs.gov>, Credentials Community Group <public-credentials@w3.org>
Yes, in particular one of the most valuable reasons to leverage did:peer is
support for service endpoints, which allow for communication with over did
comm or connection to an encrypted data vault.

While did:key can be used with both didcomm and encrypted data vaults, the
service endpoint must be known, or supplied in post resolver middleware.

OS

On Fri, Jun 12, 2020 at 11:33 AM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> I'm just noting that did:peer was recently updated to provide an upgrade
> path from did:key that may be helpful in some cases. You can create a
> did:key and then begin using it as a did:peer when you need endpoints or
> additional key complexity (e.g., rotation, multiple key values, different
> key types). This allows you to preserve the "no blockchain or network
> required" characteristic longer than would be possible otherwise.
>
> On Fri, Jun 12, 2020 at 10:06 AM Orie Steele <orie@transmute.industries>
> wrote:
>
>> public key bytes are pulled from the did identifier... they are then
>> transformed into a did document.
>>
>> Additionally for ed25519 keys, a curve25519 transformation is applied to
>> support x25519 for encryption.
>>
>> You can see one implementation for ed25519 here:
>> https://github.com/digitalbazaar/did-method-key-js/blob/master/lib/driver.js#L43
>>
>> And another implementation (work in progress for secp256k1) here:
>> https://github.com/transmute-industries/did-key.js/blob/master/packages/did-key-secp256k1/src/driver.ts#L7
>>
>> This is possible due the did method definition of how fingerprints for
>> keys are calculated... it's not very well documented in the method spec...
>>
>> But here are 2 points to how it works:
>> -
>> https://github.com/digitalbazaar/crypto-ld/blob/master/lib/LDKeyPair.js#L128
>> -
>> https://github.com/transmute-industries/did-key.js/blob/master/packages/did-key-secp256k1/src/Secp256k1KeyPair.ts#L97
>>
>> Because of its simplicity, DID Key is ideal for representing keys where
>> the public key is extractable, but where the private key is hardware
>> isolated... in addition to being very friendly to offline use cases (no
>> blockchain or network required!).
>>
>> OS
>>
>>
>> On Fri, Jun 12, 2020 at 7:31 AM Dan Bolser <dan@geromics.co.uk> wrote:
>>
>>> Just reading this:
>>> https://w3c-ccg.github.io/did-method-key/
>>>
>>> Which looks nice, but I don't understand how resolution from DID to DID
>>> doc happens.
>>>
>>> The creation of a DID Document is also performed by taking the public
>>> key value and expanding it into DID Document
>>>
>>>
>>> Ah... is the DID doc just a version of the key in a different format?
>>>
>>> e.g. no other fields except those directly derived from the key are
>>> allowed?
>>>
>>> Sorry if that's obvious (sorry if this is a dumb question).
>>>
>>> In this sense it's essentially a 'mock' or 'placeholder' DID document?
>>>
>>>
>>>
>>>
>>> On Fri, 12 Jun 2020 at 01:19, John, Anil <anil.john@hq.dhs.gov> wrote:
>>>
>>>> After the successful multi-platform interoperability plug-fest (7
>>>> independent platforms // 7 independent vendors) conducted last month across
>>>> both multi-hop supply chain asset tracking and high value identity
>>>> credential issuance and verification operational scenarios, there are two
>>>> questions I am getting on a regular basis:
>>>>
>>>>
>>>>
>>>>    1. How can we apply to join the DHS/SVIP to work on these types of
>>>>    problem sets?
>>>>    Answer >>
>>>>    https://www.linkedin.com/posts/aniljohn_blockchain-dlt-startups-activity-6676477317646180352-YCci
>>>>    2. Where can we find the REAL information on what was actually
>>>>    done, including test suites, artifacts, standards/specification, APIs and
>>>>    more?
>>>>    Answer >> See attached and see below.
>>>>
>>>>
>>>>
>>>> Automated Test Suites and Related Artifacts Developed, Utilized and
>>>> Available to the Community
>>>>
>>>>    - Phase 1 Plug-Fest Interop Test Suite
>>>>    https://github.com/w3c-ccg/vc-examples/tree/master/plugfest-2020
>>>>    - Phase 1 Plug-Fest Test Report
>>>>    https://w3c-ccg.github.io/vc-examples/plugfest-2020.html
>>>>    - Digital Permanent Resident Card VC
>>>>    https://digitalbazaar.github.io/citizenship-vocab/#exampl
>>>>    - Digital Certified Steel Mill Test Report
>>>>
>>>>    https://w3c-ccg.github.io/vc-examples/#hypothetical-certified-mill-test-report
>>>>    - Digital Crude Oil Verifiable Credentials
>>>>
>>>>    https://w3c-ccg.github.io/vc-examples/#hypothetical-crude-verifiable-credentials
>>>>
>>>>
>>>>
>>>> ---
>>>>
>>>> APIs Developed & Utilized and Available to the Community
>>>>
>>>>    - Verifiable Credential Issuer API
>>>>    https://w3c-ccg.github.io/vc-issuer-http-api/index.html
>>>>    - Verifiable Credential Verifier HTTP API
>>>>
>>>> https://w3c-ccg.github.io/vc-verifier-http-api/index.html
>>>>
>>>>
>>>>
>>>> ---
>>>>
>>>> W3C Standards or Standards Track Specifications Used
>>>>
>>>>    - W3C Verifiable Credentials Data Model
>>>>    https://www.w3.org/TR/vc-data-model/
>>>>    - W3C Decentralized Identifiers
>>>>    https://w3c.github.io/did-core/
>>>>    - W3C JSON-LD
>>>>    https://www.w3.org/TR/json-ld11/
>>>>
>>>>
>>>>
>>>> ---
>>>>
>>>> Emerging Specifications Used
>>>>
>>>>    - The did:key Method
>>>>    https://w3c-ccg.github.io/did-method-key/
>>>>    - Verifiable Credential Issuer API
>>>>    https://w3c-ccg.github.io/vc-issuer-http-api/index.html
>>>>    - Verifiable Credential HTTP Verifier API
>>>>    https://w3c-ccg.github.io/vc-verifier-http-api/index.html
>>>>    - Secure Data Store (Encrypted Data Vaults)
>>>>    https://identity.foundation/secure-data-store/
>>>>    - WebKMS
>>>>    https://w3c-ccg.github.io/webkms/
>>>>    - Universal Resolver
>>>>
>>>>    https://github.com/decentralized-identity/universal-resolver/blob/master/README.md
>>>>
>>>>    - Linked Data Proofs
>>>>    https://w3c-ccg.github.io/ld-proofs/
>>>>    - Linked Data Signatures for JWS
>>>>    https://github.com/w3c-ccg/lds-jws2020
>>>>    - Ed25519 Crypto Suite
>>>>    https://w3c-ccg.github.io/lds-ed25519-2018/
>>>>    - HTTP Signatures
>>>>    https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I hope this is useful.
>>>>
>>>> This is only a start.
>>>>
>>>> Much work remains, and we intend to continue working in public while
>>>> contributing to the community and incorporating your input and feedback.
>>>>
>>>> We hope you will contribute and add to the work so that it benefits and
>>>> moves the ecosystem as a whole forward.
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>>
>>>> Anil
>>>>
>>>>
>>>>
>>>> Anil John
>>>>
>>>> Technical Director, Silicon Valley Innovation Program
>>>>
>>>> Science and Technology Directorate
>>>>
>>>> US Department of Homeland Security
>>>>
>>>> Washington, DC, USA
>>>>
>>>>
>>>>
>>>> Email Response Time – 24 Hours
>>>>
>>>>
>>>>
>>>> [image: https://www.dhs.gov/science-and-technology/svip]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>

image002.png
(image/png attachment: image002.png)

Received on Friday, 12 June 2020 17:00:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 12 June 2020 17:00:45 UTC