TalaoDAO
CRITICAL: Filter and propose (and accept) wrong account ownership card!
Problem
- connected #2680
- Reset altme wallet
- initialize wallet
- switch to Ghostnet
- Add a DEMIM member account with private key, switch to that account
- Log into DEMIM with member account (already registered)
- Click download credential
- on download: altme says "you are missing the account ownership card - do you want to add it?"
- click "yes"
- Select card and present -> message "FAILED"
- Select card again and present -> Successfull
- import Demim user account which belongs to the member account above
- switch to account
- Log into DEMIM as selected user
- download crendential (same steps), not asking anymore because other ownership card is there -> I can get the card even if the account ownership is NOT the one of the credential subject
- result: this new credential is associated with the first (wrong) account
resolution
- Altme SHALL check the credentialSubject DID (Tezos address) and ask for THIS exact account ownership card
- ALTME SHALL filter credentials according to the selected account top right and only allow to select/present credentials that have this account == credentialSubject
Even worse
It get's even worse. When I scan the qr code to present the credential in the OIDC bridge I get the request for either a member credential or a user credential. Both are as stated above in my wallet. I select the user credential (which was added previously with the wrong account ownership card) and click "present". Apart from the one time error of authorization I get when trying to present and having to do it twice the WRONG crendential is handed out to the server:
0|oidc-server | Presentation:
0|oidc-server | {
0|oidc-server | '@context': [ '[https://www.w3.org/2018/credentials/v1](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2Fcredentials%2Fv1&data=05%7C02%7CCarlo.van-Driesten%40bmw.de%7C2f920d103a7649277e2608dcfdaf3eb3%7Cce849babcc1c465bb62e18f07c9ac198%7C0%7C0%7C638664178622734143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3xMXfQFucY4HUJFplOgPGnTVmOBsO%2FkZnj2o8rnOOx0%3D&reserved=0)' ],
0|oidc-server | id: 'urn:uuid:e3eedea2-3a70-4df9-b187-1526a2addbe3',
0|oidc-server | type: [ 'VerifiablePresentation' ],
0|oidc-server | verifiableCredential: {
0|oidc-server | '@context': [ '[https://www.w3.org/2018/credentials/v1](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2Fcredentials%2Fv1&data=05%7C02%7CCarlo.van-Driesten%40bmw.de%7C2f920d103a7649277e2608dcfdaf3eb3%7Cce849babcc1c465bb62e18f07c9ac198%7C0%7C0%7C638664178622772701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=boyVmYHtY6c0P9fbw%2BODt%2FtHc6J%2FJAgUD7sL%2F%2BV%2F%2B%2FM%3D&reserved=0)', [Object] ],
0|oidc-server | id: 'urn:uuid:a5edf624-1808-47ed-9b1a-bd04ba42f02d',
0|oidc-server | type: [ 'VerifiableCredential', 'AscsMemberCredential' ],
0|oidc-server | credentialSubject: {
0|oidc-server | id: 'did:pkh:tz:tz1Kj1XAEhrcuPS3rvZ8BGsUGDjv78ykEkEi',
0|oidc-server | vatID: 'DE322014796',
0|oidc-server | isEnvitedMember: true,
0|oidc-server | articlesOfAssociation: '[https://asc-s.de/media/files/ascs_articles_of_association_2021-09-17.pdf](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fasc-s.de%2Fmedia%2Ffiles%2Fascs_articles_of_association_2021-09-17.pdf&data=05%7C02%7CCarlo.van-Driesten%40bmw.de%7C2f920d103a7649277e2608dcfdaf3eb3%7Cce849babcc1c465bb62e18f07c9ac198%7C0%7C0%7C638664178622799357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bzQIX4pLaFyaORpPSfYvgfZVpo5%2BowTkAXEPO8DWb08%3D&reserved=0)',
0|oidc-server | type: 'AscsMember',
0|oidc-server | name: 'vDL Digital Ventures GmbH',
0|oidc-server | privacyPolicy: '[https://asc-s.de/datenschutz](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fasc-s.de%2Fdatenschutz&data=05%7C02%7CCarlo.van-Driesten%40bmw.de%7C2f920d103a7649277e2608dcfdaf3eb3%7Cce849babcc1c465bb62e18f07c9ac198%7C0%7C0%7C638664178622825906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ca%2FK%2BQhB8IGB3Eo3OWnAA8wQuEZgV1NxxI1hT3K9fG8%3D&reserved=0)',
0|oidc-server | url: '[https://vdl.digital/](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvdl.digital%2F&data=05%7C02%7CCarlo.van-Driesten%40bmw.de%7C2f920d103a7649277e2608dcfdaf3eb3%7Cce849babcc1c465bb62e18f07c9ac198%7C0%7C0%7C638664178622852203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FkayJs6MChjzfTrO%2BcSPLmBP15E96RALsFELXm8tf%2Bw%3D&reserved=0)',
0|oidc-server | address: [Object],
0|oidc-server | isAscsMember: true,
0|oidc-server | contributionRules: '[https://asc-s.de/media/files/ascs_Contribution_Rules_as_of_2020-07-08_YNCA2wi.pdf](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fasc-s.de%2Fmedia%2Ffiles%2Fascs_Contribution_Rules_as_of_2020-07-08_YNCA2wi.pdf&data=05%7C02%7CCarlo.van-Driesten%40bmw.de%7C2f920d103a7649277e2608dcfdaf3eb3%7Cce849babcc1c465bb62e18f07c9ac198%7C0%7C0%7C638664178622879866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZpfvH7OcaoAgHCypYWhU2pfU7xoE0reAP0G7L1ZzM6M%3D&reserved=0)'
0|oidc-server | },
0|oidc-server | issuer: 'did:pkh:tz:tz1ZBYB7Lwmoc7xbwq59mHK4GbiPhfPaEo2g',
0|oidc-server | issuanceDate: '2024-10-30T12:20:55.134Z',
0|oidc-server | proof: {
0|oidc-server | '@context': [Object],
0|oidc-server | type: 'TezosSignature2021',
0|oidc-server | proofPurpose: 'assertionMethod',
0|oidc-server | proofValue: 'edsigtzevcJza3fCTZpraJZaqmeN641T6Sce8uCe7F63q43TdChp93NAffEbieNnNRQXHk4i1ChgYAjAcYyDLHGSWRYMhvkSexP',
0|oidc-server | verificationMethod: 'did:pkh:tz:tz1ZBYB7Lwmoc7xbwq59mHK4GbiPhfPaEo2g#TezosMethod2021',
0|oidc-server | created: '2024-10-30T12:20:55.138Z',
0|oidc-server | publicKeyJwk: [Object]
0|oidc-server | },
0|oidc-server | expirationDate: '2102-09-15T17:14:33Z'
0|oidc-server | },
0|oidc-server | proof: {
0|oidc-server | type: 'Ed25519Signature2018',
0|oidc-server | proofPurpose: 'authentication',
0|oidc-server | challenge: '9ec1c59d-3df1-4aba-abe6-d6a3a8952e28',
0|oidc-server | verificationMethod: 'did:key:z6MkuqsN6PEYMJ95QgFYaQbZjF52qCFqoLgzkjTbf4VT8aFy#z6MkuqsN6PEYMJ95QgFYaQbZjF52qCFqoLgzkjTbf4VT8aFy',
0|oidc-server | created: '2024-11-05T15:26:26.803663Z',
0|oidc-server | domain: 'did:key:z6MknCGsUC4cU9V1GLCpnhwzpJd78Brc3YsYyeobTBxQXa9Y',
0|oidc-server | jws: 'eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..XdKC75lprMhYhuPQ6jEhdxKnEgJYCz8ZQ47_NI9BnhSnSLhCBiK0nkaDncpckQwYRzut8fqGU3n8uNyLMsFLCg'
0|oidc-server | },
0|oidc-server | holder: 'did:key:z6MkuqsN6PEYMJ95QgFYaQbZjF52qCFqoLgzkjTbf4VT8aFy'
0|oidc-server | }
BUT you can see in the screenshot of the app that it pretends that the user credential was handed out:
Confirmation
- I delete the User credential on altme
- I add the account ownership card for the user myself
- I login to DEMIM with the user
- I download the credential again
- I can now select between two ownership cards
- I select the RIGHT ONE from the user
- I login to a webiste by presenting the user credential
- The CORRECT one is used!
@jdsika The problem of the VC above is that the credentialSubject.id should be the holder (did:key) The issuer is ok (did:pkh) but the subject should be the wallet identifier.
What is critical is to store company VCs and natural person VCs in the same wallet.
The wallet could be considered as a personal wallet and to act on behalf of a company the user could present a VC issued by the company like an Employee Badge or a mandate for a legal representative.
Only in testing a wallet stores multiple credentials (mixed company and user). This edge case revealed the bad behavior.
We should consider the organizational wallet and the personal as different wallets if the two types of VCs are needed.
@jdsika I'm not able to reproduce the fail on card acquisition with imported crypto account.
When changing account dapp is often freezing: After QR code I see responses from beacon but nothing is happening on the dapp => Opening a new incognito window solve the issue.
Where can I present MEMBER and USER credentials ?
When the user is getting his MEMBER card we know the expected account number... How about adding an input descriptor on $..associatedAddress with the account id in the pattern ?
After MEMBER approved a USER and the crypto transaction is a success I'm asked again to sign with beacon. Did you encounter this behaviour?
NB: Currently we create an associated address account card for the active crypto account. When presenting we don't have a restriction depending on the active account because it's impeding other usecases.
Here you can present the credentials: https://d2fsmzaw73zi95.cloudfront.net/