The BPA has a generic UI that adjusts itself to the keys that are configured with a schema. Therefore the BPA always needs a schema configured to be able to display the data correctly. This is no issue for indy schemas as the matching schema can always be looked up on a ledger, on top of that indy schemas are flat key lists and hence very easy to display. Json-ld schemas can be very complex though, to get started the BPA assumed that ld verifiable credentials are also simple flat structures, but of course this is not always the case. Also the indy logic that always auto imports a schema in the case an exchange with an unknown schema is received does not work very well in this case. Therefore it makes sense to separate the information that the BPA needs to know to issue a credential or ask for a presentation from the actual data display. A good starting point to look at is probably the public profile as it already deals with VC's and VP's.
The BPA has a generic UI that adjusts itself to the keys that are configured with a schema. Therefore the BPA always needs a schema configured to be able to display the data correctly. This is no issue for indy schemas as the matching schema can always be looked up on a ledger, on top of that indy schemas are flat key lists and hence very easy to display. Json-ld schemas can be very complex though, to get started the BPA assumed that ld verifiable credentials are also simple flat structures, but of course this is not always the case. Also the indy logic that always auto imports a schema in the case an exchange with an unknown schema is received does not work very well in this case. Therefore it makes sense to separate the information that the BPA needs to know to issue a credential or ask for a presentation from the actual data display. A good starting point to look at is probably the public profile as it already deals with VC's and VP's.