Realistically the wallet (=holder's mobile application) scenario will be very fragmented, with some wallet vendors having an unfair competitive advantage (e.g. Intrasoft's EUDI-ARF reference implementation). Therefore we need to deal with a scenario where multiple 3rd party wallets must be able to request a credential to our back-end (and vice-versa, although the opposite case is probably negligible).
Therefore, in order for a 3rd party mobile wallet to be able to receive a credential from our back-end, where the credential requires data validation, a protocol is needed to allow the wallet to request the issuer "what data do you need, to issue this credential?".
If the mobile wallet requesting is ONLY EUDI-ARF compatible, it may not support W3C-DID. This implies that our credential issueing must accomodate non W3C-DID based identities.
andrea-dintino
commented
2 months ago
Realistically the wallet (=holder's mobile application) scenario will be very fragmented, with some wallet vendors having an unfair competitive advantage (e.g. Intrasoft's EUDI-ARF reference implementation). Therefore we need to deal with a scenario where multiple 3rd party wallets must be able to request a credential to our back-end (and vice-versa, although the opposite case is probably negligible).
Therefore, in order for a 3rd party mobile wallet to be able to receive a credential from our back-end, where the credential requires data validation, a protocol is needed to allow the wallet to request the issuer "what data do you need, to issue this credential?".
It appears that OpenID is working on a standard there: https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedDiscovery
If the mobile wallet requesting is ONLY EUDI-ARF compatible, it may not support W3C-DID. This implies that our credential issueing must accomodate non W3C-DID based identities.