Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section discussing interface grouping #70

Open
kimdhamilton opened this issue Mar 19, 2021 · 6 comments
Open

Add section discussing interface grouping #70

kimdhamilton opened this issue Mar 19, 2021 · 6 comments

Comments

@kimdhamilton
Copy link
Collaborator

Per discussion after #46 (comment), we decided we wanted to call out interface grouping (VC vs Currency, etc), while leaving the current spec interface structure alone (i.e. this is more of an implementation concern)

I can't remember where we decided this discussion belongs -- a new section to the spec, or in a (new) design doc that's more code focused?

Either way, we should preserve @sudeshrshetty's diagram somewhere; I think it will help implementors better understand the connection between spec and code

@OR13
Copy link
Collaborator

OR13 commented Mar 19, 2021

I think we decided to add some informative text about interface groups for now, something like:

Wallets for Verifiable Credentials... these interfaces may be useful.

Wallets for Crypto Currency... these interfaces may be useful.

@OR13
Copy link
Collaborator

OR13 commented Mar 19, 2021

It feels like we may be dancing around concepts covered by app manifest / chrome extension requirements...

essentially, a concrete way to describe the capabilities of progressive web applications...

I think informatively, it's fine to say crypto currency wallets use interfaces A, and B... but ultimately we need these interfaces to be machine readable.

Similar to how chrome extensions declare their abilities.

For example: https://developer.chrome.com/docs/extensions/mv3/manifest/

consider the requirements section: https://developer.chrome.com/docs/extensions/mv3/manifest/requirements/

@sudeshrshetty
Copy link
Contributor

@OR13 so you are suggesting to introduce a new data model called manifest to show supported interfaces & data models of a wallet implementation?

@OR13
Copy link
Collaborator

OR13 commented Mar 25, 2021

@sudeshrshetty I'm proposing we consider how applications in say an app store or browser extension registry might expose the data models and interfaces they support, lets look at metamask as a concrete example:

Clearly MetaMask in all locations supports the following wallet data models and interfaces:

  1. Mnemonic
  2. Currency
  3. wallet.transferCurrency

MetaMask does not use the universal wallet data model or interfaces internally, but its external interfaces are compatible...

I can load a mnemonic from a universal wallet into meta mask.... I can use meta mask for find related currencies.... I can use my meta mask wallet to transfer currencies.

And I can do this in ANY of the apps listed above... but imagine that for some reason I could not transfer certain currencies on iOS or Android.... How might we express the feature difference between an iOS wallet and an Android wallet?

@TomCJones
Copy link

In Kantara we are taking the position that app metadata needs to be collected as signed by some agency that validates the app. This structure has has several names over the years. It was a software statement introduced by TonyNad some years back. In Kantara we call it the Mobile Authentication Assurance Statement. We would like to see what other data fields are appropriate for a signed statement. You can see our current draft here. https://kantarainitiative.org/download/kantara-mobile-assurance-statement/

Besides that the PWA has a evolving Manifest which is created by the app developer. I am not sure if that should extend to more web sites or native apps. I am tracking the evolution of the PWA manifest here: https://tcwiki.azurewebsites.net/index.php?title=PWA_initiators

@OR13
Copy link
Collaborator

OR13 commented Mar 29, 2021

@TomCJones yes, there is some overlap with other initiatives like https://www.apple.com/privacy/labels/

Once you know what a software CAN do, you might rightly ask, what kind of consent should be retained from the user, another infamous example from semi recent history: https://en.wikipedia.org/wiki/Facebook%E2%80%93Cambridge_Analytica_data_scandal

It may be the case that certain interfaces pose a greater risk to user security / privacy, for example transferring crypto currency with on a public ledger, with the ability to include a memo...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants