suggestion - make `id` property optional in presentation_definition and input_descriptors

[Sakurann]

There are currently two id properties in PE

• id - The Presentation Definition MUST contain an id property.
• The Input Descriptor Object MUST contain an id property.

I am sure some use-cases require these ids, but not all: both ids are not required when there is only one presentation_definition or only one input_descriptor. Implementations should be able to decide when to include these ids, which has been a direction in OIDC4VP draft discussion.

cc: @alenhorvat

[csuwildcat]

The top-level IDs are debatable, but features within the spec are targeted/assessed by-reference to input descriptors, so the input descriptor IDs can't be removed. Also, it's generally a bad practice to create properties that are transient, if it can be avoided. (more code branching = more bugs)

[tplooker]

While I generally agree less optionality in a spec usually leads to more interoperable implementations. In this particular case it depends on the context in which a structure like an input descriptor is likely to be used and whether all applications would require an id property. With OpenID connect there are applications where the input descriptor object (or an array of these) is likely to be embedded as a new request parameter. Since OpenID already has mechanisms to uniquely identify the request to the parties involved in the protocol, having to stipulate an id at the input descriptor level would be surplus to requirements and likely create confusion in that application of the spec.

I would suggest relaxing the constraint around this field as being required is a good idea for structures like input descriptors. However, language should be added that says if you are using other P.E structures that rely on being able to address an input descriptor, then they should make use of the id property.

As an example of the sort of model I think we are heading towards, JWT's chose to make all claims optional (https://datatracker.ietf.org/doc/html/rfc7519#section-4.1) because their application as a token format is vast. However by at least having the claims registered and defined, they ensure there is an interoperable way in which common token functions can be performed, such as uniquely identifying tokens (https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.7).

In general I expect application protocols of P.E such as OpenID or DIDComm to profile their usage (e.g say things like the id property in input descriptors is required OR not used).

[csuwildcat]

@tplooker I'm frustrated this ticket has commingled two completely different types of IDs in the spec. I've taken time in my reply to distinguish between the two, so can we please do so going forward?

The top level IDs are certainly something that could be relaxed (I didn't push for those, just FYI), but the IDs in each Descriptor array member are not something we can remove, because the spec includes features that rely on referencing members (and would lead to needless hit test loops, vs O(1) direct evaluation). Can everyone here please acknowledge this disambiguation and that there's an understanding of what the per-member IDs are used for?

[tplooker]

@csuwildcat understand, I think we have agreement on the top level id's being optional it is the definition of the id property for input descriptors that we are discussing.

I understand that in certain contexts when an input descriptor is used in conjunction with other P.E defined structures that having all input descriptors uniquely identifiable via an id is a necessity. However, I dont think that means the id property in an input descriptor has to always be required. For instance would the following text suffice.

"When an input descriptor object is being used with a context that requires it to be uniquely identifiable the property of id SHOULD be used". Whereby the cases you speak of would meet that criteria.

[csuwildcat]

@tplooker on the top-level PE Definition ID, I think we can relax that. As for the PE Descriptor items, I am very weary of a change like the one you describe above because I personally feel it is an introduction of a line that basically says "You read the tea leaves and figure it out, and hopefully you include it when you need to", all for shaving a few bytes? Would it be so hard for the SIOP spec to just specify that those IDs be integer string values? I would like to hear what folks like @brentzundel @JaceHensley and @OR13 think about it.

[tplooker]

@tplooker on the top-level PE Definition ID, I think we can relax that.

Ok great.

As for the PE Descriptor items, I am very weary of a change like the one you describe above because I personally feel it is an introduction of a line that basically says "You read the tea leaves and figure it out, and hopefully you include it when you need to", all for shaving a few bytes

Ok what about making the language I suggested stricter, for instance when you are making use of the submission_requirements structure, you could say that all input descriptors MUST use the id property to uniquely identify which is the basis of how they are referenced?

[csuwildcat]

@tplooker there are other feature properties within the Descriptors themselves that require referential relationships (e.g. same_subject, wherein two input descriptors may be linked via the requirement that the subject of each is the same) , and I suspect they're will be more. For this reason, I'd really like to avoid adding the subjectivity + a one-off Note that says: "And you can branch your code here to create an uneven experience across transports, but if you need these 3 features, don't, and it's all defined somewhere else what of this will be observed". Also, does SIOP really want to process these submissions in hit test loops that burn needless CPU cycles O(n), and/or not support features like same_subject?

[tplooker]

@csuwildcat, ok I understand that there are other consumption patterns than the example I just gave, however I think the language remains true.

Also, does SIOP really want to process these submissions in hit test loops that burn needless CPU cycles O(n), and/or not support features like same_subject?

Im not saying that, I would say when it is beneficial to application protocols, they should normatively define use of the property in a way that leads to interoperable implementations and performant processing. However what I am arguing is not all consumptions of P.E need to or benefit from the id property in an input descriptor being mandatory.

R.e the particular application of the same_subject property in the context of OIDC, again i dont think there is an application for this particular property, because the protocol assumes that an OIDC request-response is always referring to one logical subject (the end-user) so the case will never arise to need to express this in a request (as there is no other option).

[brentzundel]

Relaxing the requirements for the input descriptor id property don't make sense to me, for all of the reasons already outlined by @csuwildcat .
The most the presentation definition id property should be relaxed is from MUST to SHOULD, imo.

[JaceHensley]

I agree that input descriptors need to have their id. At the very least they are required for identifying which VC in the Presentation Submission corresponds to which Input Descriptor in the PD. I'm not sure how else you could map the VC in the PS to the Input Descriptor in the PD

[tplooker]

Ok just to clarify, the ask was only to transition this property from a MUST to a SHOULD so that when using the input_descriptors object model in a context like OIDC, where there is zero need for the id property we wouldn't be having to generate a random id just to meet conformance to the spec. I'm not arguing the need for this field in other applications of P.E does not exist, just that the need is not universal.

[David-Chadwick]

@JaceHensley

At the very least they are required for identifying which VC in the Presentation Submission corresponds to which Input Descriptor in the PD. I'm not sure how else you could map the VC in the PS to the Input Descriptor in the PD

This mapping might be required in your policy matching algorithm, but we have our own way of matching the presented VCs against the RP's policy, and it does not require input descriptor IDs in order to do this. So the requirement is not universal

[JaceHensley]

How does that matching happen?

[csuwildcat]

How does that matching happen?

Yes, I am also super interested in how the Verifying server is ingesting N submitted things and verifying them against, for example the PE Definition filters that determine credential content validity. Are you honestly just looping each candidate input O(n) and seeing if a green check shakes out somewhere? While I suppose this is possible (if you aren't using features in the spec that absolutely require explicit references), why would you want to create a system of needless looping and blind hit testing, @David-Chadwick?

[David-Chadwick]

I am not going to tell your our algorithm. Sorry. That is our IPR.