[TC-IDM-1.2]-SDK support required for test step 4 and 5 in Invoke Response Action from DUT to TH test case.

[Rajashreekalmane]

Test Case ID
[TC-IDM-1.2] Invoke Response Action from DUT to TH

Problem

As per Test-Plan, test step 4 is expecting to "Setup the TH such that it should not have the privilege for the cluster"
in the path , and test step 5 is expecting to "Setup the TH such that there is no accessing fabric "
was out of scope for TE-8 and doesn't had the verification steps. Do we have the SDK developed to support these steps?
If it is, please share the verification steps for the same.

Test-Plan reference:-
https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/interactiondatamodel.adoc#tc-idm-1-2-invoke-response-action-from-dut-to-th

Spec Reference:-
https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/data_model/Interaction-Model.adoc#invoke-response-action

[Rajashreekalmane]

Same issue facing [TC-IDM-2.2] Report Data Action from DUT to TH test case.

As per Test-Plan The test-step 21 is expecting "TH sends the Read Request Message to
the DUT to read an attribute in the path that requires a privilege that is not granted for the cluster in the path"
and test step 22 is expecting "TH sends the Read Request Message to the DUT to read an
attribute in the path that is fabric scoped, and the associated fabric does not match the accessing fabric"
Do we have the SDK developed to support these steps?
If it is, please share the verification steps for the same.

PFA Test-Plan screenshot :-

[vivien-apple]

@mrjerryjohns Can you provide what is the device configuration that should be used for such test cases ? It is unclear to me that this is an issue requesting code changes instead of the steps missing informations.

[vivien-apple]

Per my understanding of the step a simple trick once #17280 and #17309 have landed is to use the --commissioner-nodeid option and the --commissioner-fabricid option.

Those would override either the nodeid or the fabricid used when a message is sent, which should prevent access to the target resources because there is no ACL rules for them.

For example:
./out/debug/standalone/chip-tool basic read-event start-up 0x12344321 0 should work
./out/debug/standalone/chip-tool basic read-event start-up 0x12344321 0 --commissioner-nodeid 332211should returns UNSUPPORTED_ACCESS
./out/debug/standalone/chip-tool basic read-event start-up 0x12344321 0 --commissioner-fabricid 332211should returns UNSUPPORTED_ACCESS

[Rajashreekalmane]

@vivien-apple This command is not working, I am getting

Steps to reproduce:- ./chip-tool basic read-event start-up 0x12344321 0 --commissioner-fabricid 332211

[vivien-apple]

It is unclear to me that the test case is correct. (CC'ing @mrjerryjohns / @bzbarsky-apple)

Do we have support for "Fabric Scoped" attribute ? My understanding is that we have support for "Fabric Scoped" attribute fields, not for the whole attribute.

[bzbarsky-apple]

There are "Fabric scoped" attributes, but there is no concept of "associated fabric" for a whole attribute; that's attached to individual structs in the list.

The test plan language around "TH sends the Read Request Message to the DUT to read an
attribute in the path that is fabric scoped, and the associated fabric does not match the accessing fabric" is based on some bad spec language that has since been removed from the spec. So this test plan needs to be fixed to test something sane that matches the spec....

As for "read an attribute in the path that requires a privilege that is not granted for the cluster in the path" that should be doable in YAML:

1. Write the ACLs to make them not be "allow everything".
2. Do whatever attribute read we want that should now be blocked by the lack of ACLs.

[mlepage-google]

Yes, Boris' comment (3 days ago) is correct. Only administrators can change ACLs, and they can completely change ACLs. They can make it such that they lose their own access completely, if they wish.

So if TH wants to test access denied, it can:

• TH commission DUT
• TD change admin ACL so TH can only access Access Control Cluster on EP0
• TH will have no access to anything except Access Control Cluster on EP0; every other operation will be denied
• TH still has access to Access Control Cluster on EP0, so TH can reverse this by again changing the admin ACL
• TH can add another ACL which provides access to another subject (not TH) and that subject will be able to perform actions that will be denied to TH
• TH can change or remove admin ACL, and either another node will have admin access, or none (in which case, DUT will work fine but no more ACL changes will be possible on that fabric)
• other fabrics operate independently; ACLs don't mingle

This all works now in the SDK.

To be clear, you don't need to have TH pretend to be different node ID (subjects), as described by Vivien, to test access denied (although you can, if that's preferred). TH can limit its own access, as I described above.