500 Error on identifiers.get(alias) for AIDs created with algo: extern

[yeomjaeseung]

Version

main, GLEIF-IT/v0.3.0

After successfully creating an AID with algo: extern and confirming that the inception is correctly recorded on the witness network via its prefix, I call client.identifiers().get(alias) to retrieve the identifier's metadata. However, instead of receiving the expected metadata, the call returns a 500 Internal Server Error. This error occurs even though the witness KEL is valid and the prefix lookup works perfectly,

[TEST 1] Lookup by ALIAS: "testV1"
❌ Alias Lookup Failed:
Status: undefined, Message: "HTTP GET /identifiers/testV1 - 500 Internal Server Error - {"title": "500 Internal Server Error"}"

[TEST 2] Lookup by PREFIX: "EHJrAyxB4iQylScLdBJR1LntkbzbbeQgc20zqtKoYlqj"
✅ Prefix Lookup Success!
Sequence Number: 0
Current Key : DHHHdqqTEP5aQpmeQ3okXnpV4TYavA89IQh43HphRwTy

Steps to reproduce

1. Initialize a SignifyClient and inject a custom external module for Ed25519 signing (e.g., using AWS HSM).

2. Create a new AID on the GLEIF Testnet using identifiers().create() with algo: "extern" and a custom extern_type.

3. Verify that the inception event is successfully recorded on the GLEIF Testnet witnesses by querying with the AID prefix.

4. Call client.identifiers().get(alias) using the alias assigned during the creation step.

5. Observe that the agent returns a 500 Internal Server Error instead of the identifier metadata.

[iFergal]

@yeomjaeseung Can you also include the KERIA logs for this 500 in this ticket?

[yeomjaeseung]

@iFergal Here are the logs . I am currently running KERIA v0.2.0-rc2.

It appears that the Alias (testV1) is mapped to a Prefix, but the underlying Keeper state for that Prefix is missing from the database ,causing rm.get(pre=hab.pre) to fail.

[FALCON] [ERROR] GET /identifiers/testV1 => Traceback (most recent call last):
File "falcon/app.py", line 440, in falcon.app.App.call
File "/keria/src/keria/app/aiding.py", line 687, in on_get
data = info(hab, agent.mgr, full=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/keria/src/keria/app/aiding.py", line 1000, in info
keeper = rm.get(pre=hab.pre)
^^^^^^^^^^^^^^^^^^^
File "/keria/src/keria/core/keeping.py", line 148, in get
raise ValueError("Attempt to load nonexistent pre={}.".format(pre))
ValueError: Attempt to load nonexistent pre=ENQJYgWtxa5EIOoY_140waClDVYhFsqGvdAFggJ4IK4O.

[iFergal]

Yeah, after incepting a salty/randy/group identifier, some parameters are stored in the database, such as the derivation path for salty. At this point, rb.pres is populated with the prefix.

For external modules, nothing is stored so rb.pres never gets populated, and there is also no params function.

The easiest solution I think would be to populate rb.pres and add a params function which returns an empty dict or something. Though I presume it might be useful to also store extern_type.

[yeomjaeseung]

@iFergal Thanks for the quick analysis. While I understand the DB logic is missing, I’d like to know if this is a minor bug or if extern AIDs are intentionally designed to bypass KERIA's Alias-based management features. Since the standard client rotate() method internally relies on get(alias) to fetch the current key state, the 500 error effectively paralyzes standard agent-based rotation. Given this dependency, does this mean extern users are currently forced to abandon the Agent's high-level features and use Direct Mode to manually submit events for operations like rotation?

[iFergal]

@yeomjaeseung It's a bug from missing implementation. We could stop trying to load params for AIDs from external modules, but if the RemoteManager in KERIA isn't tracking this already it won't know the AID you're trying to load is external. (which is the error you are hitting)

I would suggest opening a PR to store something in rb.pres and have params return {} - this should resolve your issue with minimal changes. I can't see any reason not to store the AID in rb.pres. cc @kentbull @lenkan

[kentbull]

I agree, the AID should be stored in rb.pres, though we should think through what else we might want to store for any rotation parameters or other parameters for extern keys.

@yeomjaeseung I suggest you look into this.

I’d like to know if this is a minor bug or if extern AIDs are intentionally designed to bypass KERIA's Alias-based management features.

No, extern AIDs are not intentionally designed to bypass KERIA's alias based management. Instead, extern is supposed to integrate directly with alias-based management by storing key parameters in the KERIA database. You are just one of the first to use externally managed keys, so this part of KERIA is somewhat unfinished.

We'd be more than happy to review your PRs and suggestions to move this forward and complete the implementation of extern to act similarly to the Salty and Randy alternatives.

[yeomjaeseung]

@kentbull Understood. I'll look into the implementation and submit a PR to align extern with the existing management features.