[Feat]: Unique identifier for an agent in Agent Card

[kthota-g]

Is your feature request related to a problem? Please describe.

Currently Agent Card does not have a unique identifier attribute for an agent. agent_card.name is not guaranteed unique and is prone to branding changes.

Describe the solution you'd like

• Add a newid attribute to the agent card which must be a randomly generated UUID.
• This id must remain same for all versions of an agent.
• Mark the id as optional for backward compatibility.
• Clients can reliably use id as the identifier if set in the agent card.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[darrelmiller]

Can we identify what scenarios this new identifier will enable? Is it for defining relationships between agents? Why is the Agent URL not a sufficient identifier?

[kthota-g]

There can be scenarios where multiple versions of an agent need to be run concurrently and allow clients to migrate over to newer versions. e.g. https://example.com/agent/v1 and https://example.com/agent/v2. In such scenarios, there is no identifier apart from the name that allows identifying that these are multiple versions of the same agent.

The id attribute will enable clearly defining a discriminator for identifying a specific agent and the version attribute allows identifying specific version of an agent.

[mikeas1]

I've already discussed this with @kthota-g and I agree that this field is useful, but putting some of the points I raised in this issue for posterity:

Could a system that cares about continuity for versions just use a compound identifier of {AgentCard.provider.url} + '/' + {AgentCard.name}? That should be sufficiently unique. Noted drawback: this makes it harder to change name and provider.url fields. Given name is the only display name for the agent, if you put, e.g., branding in the agent name and wanted to change that it'll break the identifier.

Alternatively, we just indicate that the name field should be unique and repurpose that field. One pattern we use in aip.dev is that name is the unique identifier, and display_name is for people. Display names should probably be able to be localized, too (i.e. repeated with a lang string attached). Noted drawback: we've already established that the name field contains display name-like strings, so changing it now could be disruptive.

One concern I have with using identifiers for tracking versions of an agent over time is that it requires you strongly trust the content of the AgentCard. If I were able to get an AgentCard into such a system that points to a malicious agent, but has the same id and a high version value as another agent, the system would group them together and claim my malicious agent is the most recent version. And if the system uses other heuristics to detect if agents should be grouped (served on the same domain, have the same provider, etc.), is the identifier still needed?

AgentCard signatures can help with this, but you'd need some means of binding the signing key on the signature to the id field. A super cheap version of this that is kinda nice is to make the agent identifier a JWK thumbprint of the public key (or just the public key bytes, I suppose) used for a signature. The identifier isn't super readable at that point, but it's definitely possible to tie to a signature.

[darrelmiller]

@kthota-g Thank you. Connecting versions of an agent together makes a whole lot of sense. This is going to be important for agent metrics tracking. (Apparently I need to do a better job of reading the original issue proposal :-) )

it requires you strongly trust the content of the AgentCard

@mikeas1 Isn't this kind of essential anyway, Id or no Id? And also, if someone advertises a new version on a completely different domain that would be a easily detectable red flag.

I think as an optional field this is low risk and high enough value to warrant adding to the spec.

[kthota-g]

@mikeas1 The proposed id field only acts as a unique identifier instead of just relying on name for an agent. As @darrelmiller mentioned, any system that groups the agents or interacts with these agents should anyway be able to identify trusted vs. malicious agents relying on agent signature or any other mechanisms whether an id is specified or not specified.

Since id is an attribute of agent card and is included part of the serialized agent card to generate the signature, the signature does validate the id as well.

[mikeas1]

@mikeas1 Isn't this kind of essential anyway, Id or no Id? And also, if someone advertises a new version on a completely different domain that would be a easily detectable red flag.

Yeah, fair. I think the specific task of "group things by ID and present them as versions of a single entity" induces some additional trust requirements than just "accumulate stuff into one place". But point taken, trust is already a major point that consumers need to address.

Since id is an attribute of agent card and is included part of the serialized agent card to generate the signature, the signature does validate the id as well.

True, if you have some means of tying the signing key to the ID then bam, you've got verification of ID ownership. In fact, you could just make the public key your ID.

Anyway, I'll use my powerless vote to say that I'm onboard for this change.

[ThierryThevenet]

Hi
New in A2A but involved in self sovereign identity and identity trust framework for years. My first impression is that it would be great to use the general term of "uri" (rfc 3986) for the specs as it opens door to a wide range of identifier. One of them is the decentralized identifiers defined by the w3c. The main avantage of DID is that it allows to be resolved to a document which exposes a bunch of pub keys, services, versions etc. So key rotation, revocation etc are simple. other advantages are

• many ecosystems now use DIDs and so it would be easier for interop
• DIDs are efficient as identifiers for verifiable credentials integration.

[ThierryThevenet]

I don't believe that it would be a good idea to limit to DID or a specific namespace as uuid. The reason is that in some regulated framework (eIDAS v2 in EU) they force us to use an urn registered in a centralized trusted registry. It is likely that AI Agent will need to be registered and certified in EU soon and in that case the namespace will be predefined.