Always store qualified identifiers for AnonCreds objects, still supporting legacy indy identifiers in exchange

[TimoGlastra]

To make the transition to qualified identifiers as easy as possible, I think from now on we should start storing the anoncreds credential records with qualified identifiers. This means we know which network it is associated with. We should add tags that allow us to query it based on the legacy/unqualified identifiers (only if the qualified identifiers are did:indy identifiers).

• Add the following tags to the records if the identifiers for the object are did:indy identifiers
  • Credential: legacySchemaIssuerId, legacyIssuerId, legacyCredentialDefinitionId, legacyRevocationRegistryId, legacySchemaId
  • Schema: legacySchemaId, legacyIssuerId
  • Credential Definition: legacyIssuerId, legacySchemaId, legacyCredentialDefinitionId
  • This allows us to query the records using legacy identifiers
• In the AnonCredsRsHolderService store the credential with qualified schema and credential definition id. We may have to tweaks the interfaces a bit to know the qualified identifiers, or we just always require it to be passed with qualified identifiers (and do the transformation in the credential/proof format as we've fetched the objects from the registry there).
• When using did:indy identifiers for schemas and credential definitions, we should also store the unqualified/legacy tags.
• In the AnonCredsRsHolder service when querying credentials using legacy identifiers, make sure to query using the legacyXXX tags instead of the normal tags.
  • e.g. getCredential, getCredentials, getCredentialsForProofRequest
  • Should we also return the credentials using the legacy identifiers? probably yes
• In the AnonCredsRS services when creating proofs, creating credentials, creating requests, creating offers, etc.. make sure to correctly handle the legacy vs qualified identifiers taking into account input could be qualified / unqualified, but the storage is always qualified (need to query using the legacy tags), transform identifiers before returning etc...

We could also say the AnonCreds RS services only support qualified identifiers, and the mapping needs to be done on a higher level, but that increases complexity I think.

Currently issuing using unqualified identifiers is broken using AnonCreds RS and Aries Askar because we store the schema and credential definition using qualified identifiers.

Unresolved questions

• Indy SDK will still store all credentials still using unqualified identifiers. For schemas and credential definitions we can use our custom schema / credential definition records, but we don't have the qualified identifiers for the credentials stored using indy-sdk.
  • we could add a mapping in the indy-sdk to store at least the namespace identifier for all credentials issued after this issue is implemented so when we migrate we know it for at least a subset of the credentials
  • in the indy to askar migration script we could resolve all identifiers and make them qualified. I think it's not ideal as you could have a lot of credentials, but most wallets won't have a lot of credentials and it's a fair tradeoff for migrating from indy-sdk to askar. Wallets starting with Aries Askar won't have this issue.
• We could also support did:indy identifiers using the Indy SDK and transform everything before sending it to the indy-sdk, but I'm not sure if it's worth the effort, and focusing on AnonCreds RS / Aries Askar going forward means people will start migrating sooner.

[berendsliedrecht]

Nice writeup @TimoGlastra! I have two points:

1. I think we shouldn't store the legacyXXX tags, mainly because I think we can avoid it and its legacy from the start. We might be able to use the LIKE operator provided by the WQL, https://www.sqlitetutorial.net/sqlite-like/. With this, we could query qualified identifiers with an unqualified string, or vice versa. This would enable us to store only qualified identifiers and everything will still work (always nice to omit legacy stuff)
2. I do have a preference for the script, update unqualified to qualified, to be separated from the other update scripts. I think we can integrate it, maybe have like an update({migateFromIndySdkToAkar: true, currentVersion: '0.3.x', newVersion: '0.4.x', updateToQualifiedIdentifiers: true}) function. This would need a lot of tweaking as the API might be a bit too verbose now. My point is that if we keep it as a separate script, maintainability is a lot easier, but the API would likely need a slight rework.

[TimoGlastra]

Makes sense @blu3beri. The like statement is only supported for unencrypted tags, not encrypted tags, so we'll have to store all these tags unencrypted in the database.

[TimoGlastra]

So for now:

• We do not support qualified and unqualified interchangeably
• At a later stage (not for 0.4.0 release), we'll provide an unqualified to qualified migration script
• indy-sdk will never support qualified identifiers
  • [ ] Throw error when non legacy identifier are paased to the indy sdk anoncreds services (We have regexes for this)
• When using Askar, you can use unqualified credentials with unqualified exchange, and qualified credentials with qualified exchange.
  • No change needed
• When issuing using new shared components (so schema and credential definition record). I need to be able to use unqualified identifiers, even though the schema and cred def are always stored using qualified identifiers.
  • Need to add legacySchemaId and legacyCredentialDefinitionId tags and store those when a schema / cred def is created using indy method / identifiers.
    - could also go more generic than using legacy
  • In anoncreds issuer service when creating offer of credential / processing object from holder if the identifier is legacy, we need to query using the legacyXXX tags instead of by id.
• tests

Later:

• create unqualified to qualified migration script
• support querying for records that are stored with qualified identifiers using unqualified identifiers

[TimoGlastra]

how do we want to call it? legacyXXX? legacyIndyXXX? unqualifiedXXX? unqualifiedIndyXXX? Something else? Is it deprecated / legacy already?

@blu3beri prefers unqualifiedXXX

[swcurran]

FYI — a similar discussion is going on in the Aries Working Group for the last few weeks. The leaning right now is to convert unqualified DIDs into a variation on did:peer:2 — where a short version of the DID identifier is derived from the DIDDoc conveyed in the initial DID transmission (which has the DID in the identifier and so is very long).