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

Re: New Work Item Proposal: Universal Wallet 2020

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Thu, 25 Jun 2020 11:18:46 -0500
Message-ID: <CACvcBVrDAB8nzSkAouJn0WB=C82U-AcVX1MuPjp1gOZDQM=48w@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
I'm working with, or at least spending a lot of time with, Dr. Ryan
Wisnesky and Dr. Marko Rodriguez. They are seasoned in the art and have
been pioneers in their industry. Kim, Wayne, and the list know about such
things among: category theory, group theory, abstract algebra, computation,
functorial data migration, etc (not an endorsement).
https://markorodriguez.com/articles/ , categoricaldata.net/papers .
Henry Story, who is working with Ryan, posted in a thread about CT and RDF.

I am intending on pulling in credentials into a personal project and tying
into their work.

My gut feeling is to work hard to conquer the dev time and learning curve
and see how it goes. You and I will be somewhere in a few months.

On Thu, Jun 25, 2020 at 8:55 AM Orie Steele <orie@transmute.industries>

> Yes the did document caching is very early. Our intention with it is to
> support offline verification from cache when in internet denied
> environments.
> We have similar goals for credentials schemas for JSON-LD and hyperledger
> Indy schemas which live on ledger.
> OS
> On Thu, Jun 25, 2020, 8:25 AM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>> On Wed, 24 Jun 2020 at 21:33, Orie Steele <orie@transmute.industries>
>> wrote:
>>> 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
>>> Spec: https://transmute-industries.github.io/universal-wallet/
>>> 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.
>> Interesting work, thanks for sharing!
>> I'm glad you are separating data from meta data, and looking at caching
>> Looking at example 3:
>> didDocument seems to be undefined in the context document
>> The sense I am getting from the example is that the did is both the
>> subject and the object, both the cached document and the DID subject
>> the did: appears in two places in the example, is that allowed?
>> would it not mean that all the fields that apply to the cached document
>> apply to the did subject, and maybe also the did document?
>>> Regards,
>>> OS
>>> --
>>> Chief Technical Officer
>>> www.transmute.industries
>>> <https://www.transmute.industries>
Received on Thursday, 25 June 2020 16:19:11 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 25 June 2020 16:19:12 UTC