Is there a way to make this code less error-prone for consumers?

[woody-apple]

The consumer doesn't need to know the exact OID value.

---

connectedhomeip/src/controller/ExampleOperationalCredentialsIssuer.cpp

Lines 99 to 104 in 20c1f60

	// TODO: Is there a way to make this code less error-prone for consumers?
	// The consumer doesn't need to know the exact OID value.
	noc_dn.AddAttribute(chip::ASN1::kOID_AttributeType_ChipFabricId, fabricId);
	noc_dn.AddAttribute(chip::ASN1::kOID_AttributeType_ChipNodeId, nodeId);
	// TODO: Add support for the CASE Authenticated Tags attributes
	ChipDN icac_dn;

---

This issue was generated by todo-issue based on a TODO comment in 20c1f60. It's been assigned to @emargolis because they committed the code.

[andy31415]

@emargolis - is this a blocker for V1? it sounds like just nicer API may be a refactor so a maintanability thing rather than release blocking.

[woody-apple]

Agree, let's move that out.

[emargolis]

This was partially addressed in #17190

There still TODO comment from @bzbarsky-apple that should be addressed:

So... This is fine as far as it goes, but the actual TODO was about seeing whether here was a way to make the "link up the NOC and ICA cert and RCA cert just right" code that's more or less duplicated across all the credential providers harder to mess up.

For example, maybe we should have a utility for "create an operational root cert" that takes the validity start, validity end, issuer id, fabric id, and key and does the setup of the DN, the listing of the DN twice in the X509CertRequestParams, etc. And then returns some piece of data that we can pass to the "create an ICA cert" or "create a NOC" bits that will automatically set the right "parent" DN, etc....

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[bzbarsky-apple]

This was fixed in #13737