Change 'add wallet' form

[maaikevanleuken]

This should be renamed to 'Add digital wallet or agent'.

The form should include the following fields:

• Name (free text)
• Logo (free text, link to resource)
• Company (free text)
• Company URL (free text)
• Issuer / holder / verifier capabilities (multiple-choice)
• General-purpose (yes/no)
• If not general-purpose, scope (free text)
• Deployment (edge / cloud)
• Organisational wallet (yes / no)
• Open source (yes / no)
• License type (free format)
• Link to application(s): link to Apple Store, GooglePlay, website (3x free text)
• Link to API (free text)
• Support email (free text)
• Credential format (multiple choice from AnonCreds, LDP-VC, ...)
• Encoding scheme (multiple choice from JSON, JSON-LD, ...)
• Signature scheme (multiple choice from ECDSA, CL, BBS+, ...)
• Holder identifier (multiple choice from did+method, X509, ...)
• Issuer identifier (multiple choice from did+method, X509, ....)
• Revocation mechanism (multiple choice from 'not supported', Status list 20XX, ...)
• P2P protocol (multiple choice from DIDcomm, OIDC, OIDC+SIOP, ...)
• Cred exchange protocool (multiple choice from OIDC4VP, OIDC4CI, issue credential protocol, ...)
• Blockchain usage (yes/no)
• Blockchain type (free text)
• Blockchain purpose (free text)
• Connection (multiple choice from connection-based and direct communication)
• Deep-linking (yes/no)
• Offline friendly (yes/no)
• Key history holder (yes / no)
• Key history issuer (yes / no)
• Key rotation holder (yes / no)
• Key rotation issuer (yes / no)
• Portable (yes / no)
• Selective disclosure (yes / no)
• Predicates (yes / no)
• Verifier unlinkability (yes / no)
• Observability (yes / no)
• Crypto agility (yes / no)
• Quantum safe (yes / no)
• Connected to TNO EASSI (yes / no)
• Compliance to (multiple choice: ARF, EBSI, AIP, DIIP, ISO18013, ISO27001)

This should then be parsed to have the following format

{
        "aip": "-",
        "api": "-",
        "blockchainPurpose": "-",
        "blockchainType": "-",
        "blockchainUsed": "-",
        "company": "-",
        "connectionTypes": "-",
        "credExchangeProtocol": "-",
        "credentialFormat": "-",
        "cryptoAgility": "-",
        "ddip": "-",
        "deepLinking": "-",
        "deployment": "-",
        "downloadSource": "-",
        "eassi": "-",
        "ebsi": "-",
        "encodingScheme": "-",
        "hardwareSupport": "-",
        "holderCapability": "-",
        "identifierHolder": "-",
        "identifierIssuer": "-",
        "issuerCapability": "-",
        "keyHistoryHolder": "-",
        "keyHistoryIssuer": "-",
        "keyRotationHolder": "-",
        "keyRotationIssuer": "-",
        "logo": "-",
        "mdoc": "-",
        "name": "-",
        "observability": "-",
        "offlineFriendly": "-",
        "openSource": "-",
        "organisationalWallet": "-",
        "peer2PeerProtocols": "-",
        "portability": "-",
        "predicates": "-",
        "quantumSafe": "-",
        "revocationAlgorithm": "-",
        "scope": "-",
        "selectiveDisclosure": "-",
        "signatureAlgorithm": "-",
        "support": "-",
        "urlAppStore": "-",
        "urlGooglePlayStore": "-",
        "urlWebApp": "-",
        "urlWebsite": "-",
        "verifierCapability": "-",
        "verifierUnlinkability": "-"
    },

@cre8 is this workable?

[cre8]

I have some concerns with topics like "uses blockchain":
in case my wallet supports the profile "anoncreds with did:indy" and "haip with did:web", does my wallet have blockchain support or not?
Same for key rotation.

I think we can get filter information like "which wallets are using blockchain". To do it we analyse the key managements referenced in the background and filter them. This will reduce the risk of inconsistency.

E.g. A wallet supports the "anoncrdes with did:indy" profile
-> based on the profile, the filtering for did:indy will return a positive result
-> based on the did:indy method, we can filter for "is using blockchain"

I would like to go the "knowledge graph" instead of trying to stick with the old approach and just putting in the new stuff. It could increase the complexity a bit, but helps a lot with data consistency.

[maaikevanleuken]

If I understand correctly, you want to remove the direct input 'uses blockchain', but generate the answer to it based on the identifier method. In that case, I'd want to add that blockchain can be used for more purposes than just these two, namely also schema and credential definitions. I'm not sure if the case exists where wallets uses blockchain for schema/credential definitions, but not for public identifiers. But in that case, your approach would miss it.

[cre8]

There is no profile I am aware of with your described scenario. The schema part is covered by the credential format resource (JWT-VC, MDOC, etc). There we only added "rich schemas/semantic", but we are not defining how the schema is provided.
Same goes for revocation methods, because we thought that the provider of the resource is not relevant. But it's a good point I will discuss in the upcoming SIG meeting!

From a requirement point of view I don't see "use blockchain" as a good filter, because the value says nothing about "how is blockchain used". Is it used with a real benefit or just to get the checkmark? For the user it has also no impact since it is all handled by the wallet/agent in the background. This analysis looks more for a white paper with the subject "how are ssi wallets using blockchain"

[samuelmr]

There are some organizations who just want to avoid all technology related to blockchains.

Whether that's a reasonable approach or not could be discussed somewhere else, but I kind of understand the need to separate "blockchain-based wallets" and "non-blockchain wallets". Of course, "use blockchain" doesn't work even for this filtering, since there are wallets that optionally can use blockchain.

I think that whether a wallet uses (or can use) blockchains can often be deducted from the supported DID methods or credential profiles.

I'm in favor of removing "uses blockchain" and adding some filtering logic based on other characteristics later.

[samuelmr]

wallets-add.component.ts has a form component CompanyUrl capitalized. PR #61 will fix this.

The form component (.ts file) also has a property linkToApp instead of properties urlAppStore, urlGooglePlayStore, urlWebApp, urlWebsite. The .html file has none of these...

[cre8]

@samuelmr I think I missed some values when generating it, I will handle it in a separate issue and PR.

We should add this topic on the next call for better discussion