Loading a credential-definition by id returns a credential-definition with schema transaction id instead of schema id

[ArPhil]

After storing a credential-definition on the GreenLight Dev Ledger provided by British Columbia (http://dev.greenlight.bcovrin.vonx.io/) by using the aries-cloudagent-python, I would like to fetch the credential-definition data from the ledger again. Therefore I use the /credential-definitions/{id} API Endpoint with a valid credential-definition ID. E.g.:

http://localhost:10010/credential-definitions/CV1ARDUhZVZ4jygj6vYV3L%3A3%3ACL%3A2211%3Adefault

(Aries-Cloudagent-Python is running locally on port 10010)

By doing so, you get the following result from the agent:

{ "credential_definition": { "ver": "1.0", "id": "CV1ARDUhZVZ4jygj6vYV3L:3:CL:2211:default", "schemaId": "2211", "type": "CL", "tag": "default", "value": { "primary": { "n": "119824417132340183460807084909577952223846671671952437869777857788525811206761153602824079131753912500895330421080968800961626271630568868520166723660057513305077777402490565386941151346446447269708979685540617282523737902145790297677876662965761941158238845935702011508531939445068630389900667087494911637734872675969635067969923703791874810148941575912712780092834232652861200775467915335255385129415921590573360626391157603957090808036689573970451148155475925033387355599939708740855170573146228433230227326018240693703981536441578709528754601787648912589988071007834024689981073662428252698336891012641130949634693", "s": "7097946165275291378905410539890715872332473128204050134233743249633279768228707245065615978883290420301994967109931392752044223062320269966526894243129186067788411570047295637943783624403908182476581246515253399742490015923998441432818828979253633544770791998212165087459336929821022505845795500908395157583008783582641014913592876710032781681704078609838363851299487283139439213471023500144946259389586373940899470591168520479826103269914619615731652075388808886581668711501370310291035309481027449885178854566437451445755487509069026740780838673916052374284822736183814133739662853744715436468555402133869772813999", "r": { "firstnameap": "118935781031145296175096331863084711742075754763801004047442062559685562314981777161172782323262067541315000067773644072456399530029909229796106418042878288442863282656195858322948996311513150968054468629265009515258388544569060379471956896958866177828174372202071856789732648307674772219500130935716054775604327062778394770590060831396686743765693564327633343782919175142443474821074326151795651656372344252102878235134006271474633150449688828645253000868120683982021814312241384735177572883404134803316216259124429606088047130823026973906850083010419181538481192754729539776785059851633066868937692980178404639315261", "lastnameap": "119371451594094775988635669702083191610199430301653943019733477908578412343417376522438599981411221127801121093422532421844770979398928376417629339704132216092399447998799847423500379335251884606374799330136200948651098579100473302326225968564118985639051619726830126321994407048711769580255238364833979073630809212609866618030875180792758538045400878551817036027072875261516723521709891688530699482048186831326667481527987019738527710572157382172682409279736104644402884077886763476583904221678756922000296296805104063012733020825506247339631710991899211819329001344980385684612897259569081971613197221542487637066828", "master_secret": "90283953633610839497895769455990474552066538081183750982316928932597636802194384909607781640580126151348875966347084334760308935423771664705079109202298308298871738533305751352807549566253882462224544082478969882032227358269538262425438840381316852746826090390864935082746632832786761789141178902559743876959361732529353336469305551799753365890663099060934713464629111659205935825911288578218398998118958501168371101576836001935897709730426822339439054439726661394964911500754086558521899227366616606197576051410913108600628842966022633419759325265658763932242542424469918672592221657088642216897478500114051785890276" }, "rctxt": "107399151653216253009564600619392284506300547091101136440855348370509818411397609170594527610343559505185720777024465908818392289077036349035789624042861919413713363158546035296310379416582158482289950465413146168439350540317413437332951350331544008910313487293133786691054764456698194721814579294007283718754319462955432974531844425348709863075351951845904306813361891069641737533250797673327999459977065219011185972111246092259377901979573095331736468183198583928924966092399360133339760417103697562169674108447898807516267504777253749726850293834655823479265505569359137000911252739655543279576323940986488121473331", "z": "71100501285595415517129679502718362234015819090634925363878246156175883876828646651660466187349211319669176194942940499174947525947186165013675119138440146590972903234347340810260077946578819922900044408078194126542206771458269107133141986586278708202081744291143934979535534428044815927188738570846816923449894087162939551336954934418446226369656488775329582499582772086946602583926817324955725347537452751130548739857596105267663079828585502495495006309375834390314036133192256585170167072086637045688950582368402231639723616674837494691432283532270151962501531846149222174192406526181576173234733712165569409274915" } } } }

The attribute "schemaId" contains the internal transaction number 2211, which is used internally by the ledger instead the "true" schema id CV1ARDUhZVZ4jygj6vYV3L:2:MySchemaAP03:0.0.1.

(see http://dev.greenlight.bcovrin.vonx.io/browse/domain?page=1&query=2211&txn_type= and http://dev.greenlight.bcovrin.vonx.io/browse/domain?page=1&query=CV1ARDUhZVZ4jygj6vYV3L%3A2%3AMySchemaAP03%3A0.0.1&txn_type=)

Is this the intended behaviour? I rather think, that the true schema id has to be returned here as attribute rather than die transaction number.

[swcurran]

@andrewwhitehead - can you review and respond to this? @sklump - do you have any opinion on this?

[sklump]

This is the intended behaviour.

There are two acceptable forms of cred def id: long and short.

The long form arises if the issuer writes the cred def id to the ledger before retrieving the corresponding schema id (i.e., create schema, create cred def id, write both). If the issuer writes the schema to the ledger before storing the cred def in its wallet, the cred def id will always have its seq number instead of the schema id. Once a cred def has an id, though, it is set in stone everywhere, long or short.

Here is where the rubber meets the road: https://github.com/hyperledger/indy-sdk/blob/da4da126c5fb81fa2bb2d6b8215374a8e53ce73a/libindy/src/commands/anoncreds/issuer.rs#L353

Aries always writes the schema to the ledger first, and so cred def id is always short form with Aries code.

This idiosyncracy arose about a year ago and raises occasional flares of confusion.

[swcurran]

Thanks, Stephen. Hopefully that addresses the issue for now.

Not sure where this should be added to the code/docs to prevent the issue from coming up again. Suggestions welcome.

Closing the issue.

[ArPhil]

First of all: Thank you very much for the fast reply! :-)

Regarding your answer:

I am not sure, If you got my point here. The issue is not the credential-definition id. Since I create a schema and write it to the ledger first (checked it by using http://dev.greenlight.bcovrin.vonx.io/), the credential-definition id is always in the long format.

However, the schema id which is referenced within a credential-definition loaded by using the /credential-definitions/{id}API endpoint of the aries-cloudagent-python seems to be always the sequence number. The format (short sequence number or long id) does not matter to me. But when the credential-definition references a schema by using the short sequence number, there is no way to get the schema on which the credential-definition is based on, since the aries-cloudagent-python does not provide an API endpoint for fetching the schema by short sequence number.

As far as I understand, this could be fixed by either providing an additional API endpoint for fetching schemas by short sequence number oder enhance the existing endpoint (/credential-definitions/{id}) by the possibility to fetch the schema by the short sequence number as well.

Or is there a misconception on my side?

[swcurran]

Thanks for the follow up and that makes sense. @sklump has stepped forward to take a look at this.

[sklump]

Track #223 for progress of this update.

To get schema by sequence number, just use the (stringified) sequence number in place of the schema id in /schemas/{id} off the admin API. I've also allowed cred def id tagging as per Mr. Qeli's request; the default cred def id tag is still default.

[andrewwhitehead]

Closed via #223

[quinndevos-anonyome]

I've read the above, and I don't understand the implemented solution...
What is the reason why ACApy returns schemaSeqNo in place of schemaId on a credential definition?

Currently, in order to fetch the schemaId for a credential definition, I have to first fetch the credential definition, then use the schemaSeqNo to fetch the schema and read its id. If I fetch multiple credential definitions from ACApy, then this operation must be repeated for every credential definition.