Reconcile the mapping/processing between input descriptors and submitted inputs
There is currently a mapping from PE Descriptors to submitted creds/items in the PE Submission objects that is used in deterministic processing steps within PE. If this mapping is not present, the steps 1) can’t be performed as specified (moves from direct O(1) to loop test O(n) for each item), and 2) doesn’t retain the nested compat ability to drill through tiered items. I would love to find a way to use PE or somehow compose the objects such that they can adhere to the processing rules and retain the features, so perhaps we can talk this part through on a call?
Comments (6)
-
-
- changed component to Verifiable Presentation
-
- changed status to open
Kristina to post an DIF-OIDF MOU document.
-
Hi Stephane, please find attached Liaison agreement between OIDF and DIF (only .jpg files were allowed in the comment, but I can also send you a pdf). It is quite general, and the current main scope of collaboration has been OIDC4SSI specs (mainly SIOP V2 and OIDC4VP)
-
Regarding the two approaches brought up in this issue, on 07-13-2021 SIOP call, it was discussed that returned result being returned as an array is sufficient and having an object being returned would make loop up unnecessarily difficult.
-
- changed status to resolved
The comments to this issue has gone beyond the initial scope. Stephane agreed to resolve this issue in 07-22-2021 SIOP call.
The initial content of this issue is now covered by issue
#1264. - Log in to comment
This mapping approach was actually what got me the most concerned when I went through PE and I’d welcome clarifications on what it is meant to achieve.
Overall, I found the Presentation Definitions quite prescriptive in the sense that they state quite precisely what they want and with a granularity that seems not so fine. This may not necessarily be the case, but the supplied examples didn’t help dispel the feeling (it shows requests with list of specific id documents, inputs following specified schemas).
Another way to look at it is to consider the semantic that’s used: a PD comes with an “input_descriptors” list, as opposed to an “output_descriptors”, which would clarify what the verifier needs to fulfil its objectives, rather than also carrying an assumption on how the objectives will be fulfilled.
To illustrate it with an example, a verifier needs to know the address of the holder (and that address is receivable in a certain trust framework XYZ). Let’s consider the two alternatives to see how it translates throughout the sharing process:
The verifier prepares the request:
Looking at how the verifier is served:
Then, 2 has the advantage that if the request is served, there’s less room for interpretation when determining if has been appropriately served (issuers asked for (A, B or C, D and E) and got something that can be evaluating as following the grammar or not, as opposed to issuer asked for something that does X, Y, Z and got G, H, I, which is deemed by the holder to fit the bill). If there is a compensation associated to serving the request, that is quite desirable because it will, on the technical plane, simplify dispute resolutions.
The verifier processes the response
I’d say that on the complexity of mapping the verifier requirements to a list of id attributes / documents at the issuer, the net comparison gives an even score (it does the difficult part first or it does it last, but its does it anyway and about the same difficulty).
Then, the respective benefit
I described my concern using a semantic opposition between “input_descriptors” and “output_descriptors” because it felt easier this way, but my interpretation of the “mapping” this issue is about is that it is fully supporting and even enforcing even more tightly the “input_descriptors” vision.
Looking at IODC4VP, the
id
property of the PE Definition had been specified optional and therefore allows to vacant the coupling with the PE Submission through thedefinition_id
property (which should then also have been specified optional for consistency’s sake), and I was rather relieved in thinking that OIDC was not going to be as prescriptive as DIF seems to be on this aspect.There’s indeed a “bug” in the way that respective
Definition.id
andSubmission.definition_id
presence requirements are not overloaded consistently but the way to fix it depends on whether OIDC wants to support ‘prescriptive’ requests only or also allow 'descriptive' ones.Since I jumped rather recently in PE / OIDC, I do lack some context on how this cooperation is built and how the respective visions support each others. I couldn’t but notice that the visions where not converging on all aspects (maybe there’s also personal opinions involved).
As I understand PE aims at defining how request and associated responses can be structured, and a most likely application field is to implement libraries that could be reused independently on the transport layer. In that case, I think there’s a tricky balance to achieve to provide on one hand a support as complete and coherent so a library implemented on PE spec is as useful and relevant possible and on the other hand enough flexibility so it doesn’t exclude / conflict with uses cases / application cases. (by all mean feel free to correct if I misunderstood things).
I see a clear benefit in leveraging on the effort DIF put into describing a definition and a submission, but I also see that not everything from PE may fit nicely with OIDC (there’s some talks about format, this one about mapping enforcement) and such points of divergences are rather raised bottom-up from the spec details to the spec objectives (they are generally not difficult to address as long as the objectives are clear, so it may be easier to clarify the objectives first).
Is there something like a MoU / common statement somewhere that would help me understanding what is vision agreement between the two foundations on the objectives and how things are expected to stack in a practical implementation.