Relying on mandatory DelegatedRole.name attribute when TAP 15 describes it as optional

Description of issue or feature request: We are working to implement TAP 15 (see #1909). There it’s said that:

If the succinct_hash_delegations field is present in a delegation, the name field will not be used as a rolename, and so is not required.

meaning that the DelegatedRole.name attribute is not required. That seems to be a problem for us as until now we are relying on its existence to uniquely identify roles: (see Delegations.from_dict() implementation) https://github.com/theupdateframework/python-tuf/blob/10f9feaead407cf65b7b29ecc4d28b0e2190cb45/tuf/api/metadata.py#L1472

One solution to this problem could be providing an additional ID number that will serve as a unique identifier for roles. This approach is widely used by databases.

But then we have the next question what to do about DelegatedRole.to_dict() where we currently provide name: https://github.com/theupdateframework/python-tuf/blob/10f9feaead407cf65b7b29ecc4d28b0e2190cb45/tuf/api/metadata.py#L1359

In summary what we should do is:

• decide what unique identifier to use for delegated roles inside Delegations
• decide what to do with DelegatedRole.to_dict

[lukpueh]

I think the problem is that DelegatedRole so far was used for exactly one delegated role, but with TAP 15 there would only be one DelegatedRole object for all bin-n roles.

[jku]

This is always already a risk with accepting and ignoring unknown fields (except only to check if any signatures cover them), correct?

I don’t think so. In this case we are changing the way delegations are supposed to be understood, while leaving the format seemingly compatible. The old client will think it has understood the delegation correctly when it has only understood a part of it.

It’s possible that there are no security issues here but I don’t like the ambiguity: I would rather choose a design where old client fails to process the whole delegations object if the delegations object contains a delegation client does not understand.