Add section discussing interface grouping

[kimdhamilton]

Per discussion after https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/46#issuecomment-777852919, 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]

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]

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]

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

[OR13]

@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:

• Google Chrome Extension
• Mozilla Firefox Add On
• Google PlayStore Android App
• Apple App Store

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]

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]

@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...