Re: New Work Item Proposal: Universal Wallet 2020

Briefly, to reply to Manu's comment about "reference implementations", my
hope would be to see at least 1 implementation per popular language... and
not "one reference implementation", but there is always 1 of something
before there are more than one of something... and while there is only one,
it is "the"... hopefully that will change quickly :)

To address Anil's questions,

If PKI credentials can be represented as JSON / Binary Data Model, and we
can model the process of "Deriving Credentials by Proof of Possession" as
an abstract process whereby the the Data Model components are used to
produce a "Derived PIV Credential", the answer is yes.

The spec in its current form allows for the modeling of a cryptographic
key, that might be hardware, software isolated or remote in the case of web
kms, it's perfectly capable of modeling the signing of a newly generated
key, by a hardware isolated one (I believe this is approximately what is
happening with derived PIV credentials).

The PIV Card may need to be present later on down the line (say after the
user has transferred wallet contents 2 or 3 times). As long as the current
wallet provider supports the PIV Card interface (over NFC or via a card
reader), the portability of wallet contents is achieved, and its possible
to use the PIV Card, as you would any other WebAuthN Authenticator, to
maintain presentation capabilities associated with wallet contents.

A similar example in the crypto currency world is with hardware isolated
key in the form of ledgers or trezors.... the wallet representation of
these simple stored metadata about them, and as long as they have not been
hit with a hammer, they can be connected to wallet software that supports
the "wallet spec" and used to transfer currency, even if the wallet content
had been transferred a few times since they were first registered.... this
is because the data model described them in an abstract form which is
relatively safe to export and import, because the hardware device is still
required to leverage the associated capabilities.

OS



On Wed, Jun 24, 2020 at 3:26 PM John, Anil <anil.john@hq.dhs.gov> wrote:

> Orie,
>
>
>
> Would you envision this being able to support PKI based credentials?
>
>
>
> With the heavy use of mobile devices a reality, the USG some time ago
> implemented something that is termed a “Derived Personal Identity
> Verification (PIV) Credential” (
> https://csrc.nist.gov/publications/detail/sp/800-157/final ) which is a
> PKI credential that is “derived” from our existing Smart Card (PIV Card).
>
>
>
> “Derived PIV Credentials … leverages identity proofing and vetting results
> of current and valid credentials. When applied to PIV, identity proofing
> and vetting processes do not have to be repeated to issue a Derived PIV
> Credential. Instead, the user proves possession of a valid PIV Card to
> receive a Derived PIV Credential”
>
>
>
> As an FYI, the Technical Topic Area #3 of our current open solicitation
> (which also existed in our prior Release 1) envisioned a unified wallet
> infrastructure that could support DIDs/VCs as well as Derived Credentials,
> while also implementing fully documented, open, royalty free, free to
> implement and fully interoperable interfaces to the Issuer, Verifier and
> any type of a Resilient Registry Infrastructure.
>
>
>
> To date, the vision and reality of this particular TTA have only had a
> passing acquaintance with each other : -)
>
>
>
> 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]
>
>
>
> *From:* Orie Steele <orie@transmute.industries>
> *Sent:* Wednesday, June 24, 2020 3:31 PM
> *To:* W3C Credentials CG (Public List) <public-credentials@w3.org>
> *Subject:* New Work Item Proposal: Universal Wallet 2020
>
>
>
> Hi All,
>
> I'm writing this list to propose a new W3C CCG Work Item
> "universal-wallet-2020":
>
> Repo: https://github.com/transmute-industries/universal-wallet
> <https://urldefense.us/v3/__https:/github.com/transmute-industries/universal-wallet__;!!BClRuOV5cvtbuNI!S4BxVQn949xifVocIoP6XNV9Dvimv8hbHVFYvZfzbWnZbhdyj2CeDpGkbtPCNbbje3ux$>
> Spec: https://transmute-industries.github.io/universal-wallet/
> <https://urldefense.us/v3/__https:/transmute-industries.github.io/universal-wallet/__;!!BClRuOV5cvtbuNI!S4BxVQn949xifVocIoP6XNV9Dvimv8hbHVFYvZfzbWnZbhdyj2CeDpGkbtPCNRzsU4h2$>
>
> The proposed specification will define a data model and
> abstract interfaces for digital wallets that store currency, credentials,
> key material or references to key material, meta data, and cards... The
> goal being to help unify DIDs, VCs,  and cryptocurrency wallet data models,
> by defining missing vocabulary or defining relationships between existing
> vocabulary, reusing existing specifications as much as possible without
> modification.... Including DIDs, DID Key, VCs, VC HTTP APIs, WebKMS, VP
> Request Spec, Presentation Exchange, etc...
>
> We're not proposing anyone change any of their existing wallets. We're
> proposing a specification describing a way for them to import and export
> wallet contents according to a data model, and to disclose support for a
> set of abstract interfaces, as a way of enabling users to tell what
> features a given wallet supports (currency, identity, and/or credentials).
> We cannot move, what we don't understand, or that has no common
> portability format.
>
> We've presented this work to the CCG, DIF and Aries WG, and gotten
> positive feedback, but also some concern about scope / informative vs
> normative statements for interfaces. We're also tracking compatibility with
> Indy Wallets and Secure Data Stores... and we're working to understand how
> to represent data structures like connections or indy credential schemas in
> ways that support portability and interoperability.
>
> We'd like to continue this discussion and modify the spec in the W3C CCG
> with participation from the community.
>
> We'd like to move the current reference implementation to the DIF at the
> same time, but we're open to keeping them co-located if thats desired, we
> want to be sensitive to companies that cannot (or don't desire to) commit
> to the reference implementation but wish to develop the spec.
>
> Happy to answer any questions!
>
> We're looking for additional organizations to co-edit / sponsor the
> development of the specification in the W3C CCG.
>
> Regards,
>
> OS
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
> <https://urldefense.us/v3/__http:/www.transmute.industries__;!!BClRuOV5cvtbuNI!S4BxVQn949xifVocIoP6XNV9Dvimv8hbHVFYvZfzbWnZbhdyj2CeDpGkbtPCNYITSnRX$>
>
>
>
> [image: Image removed by sender.]
> <https://urldefense.us/v3/__https:/www.transmute.industries__;!!BClRuOV5cvtbuNI!S4BxVQn949xifVocIoP6XNV9Dvimv8hbHVFYvZfzbWnZbhdyj2CeDpGkbtPCNeLeWU4S$>
>


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

<https://www.transmute.industries>