[IDA] Does the same rule apply to other properties of array type?

[Takahiko Kawasaki]

The evidence property in a request has the following rule (from the “Requesting Verification Data” section):

A single entry in the evidence array represents a filter over elements of a certain evidence type. The RP therefore MUST specify this type by including the type field including a suitable value sub-element value. The values sub-element MUST NOT be used for the evidence/type field.

If multiple entries are present in evidence, these filters are linked by a logical OR.

Does the same rule apply to other properties of array type? To be concrete, to the following?

• assurance_details
• check_details

I know verified_claims has a different rule (which is described in the “Requesting Claims sets with different verification requirements” section) although its type can be an array.

If the same rule applies, it is better to mention it explicitly in the specification. On the other hand, if the same rule does not apply, implementers would be confused by the inconsistency and want detailed description about how to handle them.

[Julian White]

Looking at how it is used I’m not sure if assurance_deatils would follow quite the same rules.

assurance_details is supposed to be used to demonstrate how the evidence meets the requirements of the assurance_process, the RP can’t really influence that in any way because its the rules of the trust_framework that defines them. I think its more likely that it would be used when the RP wants to know what the values are of the sub-elements rather than filtering on them. For example the RP should include assurance_details/assurance_type:null where they want the OP to return just the assurance_type; the RP can’t say which assurance_type it is interested it, it gets all the ones the OP has. However if an RP wanted all the assurance_details should they

1. enumerate all the sub-elements, or
2. simply ask for assurance_details:null and the OP return every sub-element it can?

For check_details the RP could provide a check_method that would effectively act as a filter for that evidence type.

‌

[Julian White]

Included in PR#113

[Julian White]

Resolved by PR113