zoblazo

@TimoGlastra The credential is issued in unqualified form.

@TimoGlastra if it is indeed a backward compatibility of unqualified identifiers in Credo, can you think of any work around that we could try while sticking with unqualified did:sov ?...

Here is the DEBUG log of the issuer agent when posting a schema with scenario similar to the one described above (different did since different agent in different environment but...

@ff137 400: Error creating schema. Failed to register schema. Exception when building get-schema request. Validation error: SchemaId validation failed: "did:sov:QvZ4hHw63DNrgdf6azXnUj:2:**test_fqdid**:1.0", doesn't match pattern. And on the other hand, using unqualified...

Worth noting here that the issuer (author) is behind an endorser. So options `create_transaction_for_endorser": true,` and `endorser_connection_id` are passed in any related call, including the POST to `/anoncreds/schema`. Also worth...

Here is how we create and provision the qualified did:sov : 1) POST /wallet/did/create ``` { "method": "sov", "options": { "did": "did:sov:QvZ4hHw63DNrgdf6azXnUj", "key_type": "ed25519" }, "seed": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } ``` (seed...

No, wallet-type has been askar-anoncreds from inception. No upgrade involved. On a not-so-related note, we did update aca-py from 1.0.0 to 1.2.0 a few weeks ago but I was able...

Thus I am able to create a schema with a qualified did:sov with latest nightly build (and no endorser) BUT the resulting schema id is did:sov:... So problem still (differently)...

Exactly. Schema is created with a schema_id perfixed did:sov in acapy but the schema id on blockchain is stripped of that did:sov prefix. Then when I get to create a...

**DID** * decentralized identifier, made to be resolvable into a DID Document (DIDDoc) **DIDDoc** * must contains (among other things) cryptographic public keys owned by the controller of the DID...