Modularization of PE (for OIDC and more)

[kimdhamilton]

The changes requested for OIDC seem better suited for a PE v2 revision with goals of:

1. using PE objects in a more fine-grained way
   • one use case pointed to by this proposal is incremental exchange of VPs, spread across different phases of the protocol flow
2. simplifications based on assumptions that are possible in a fixed context
   • much of the complexity of PE is needing to enable variation across multiple protocols/transports, which, within the context of a single approach, may seem heavy-handed.
   • e.g., OIDC for VPs is proposing standard terms like "presentation", reducing the need for some levels of indirection provided by PE
3. Support by-reference in addition to id lookups (big question is how this layering happens)
   • i.e., in these use cases, don't need "id" fields because all the information is expressed at the time is needed
   • possibly an emergent description of this more state-/context-aware use of PE objects, i.e. which is another framing of 2), i.e.: some levels of indirection in PE aren't needed because issuer should know based on context

Exactly how this happens is up to the authors of PE v2, where "OIDC for VPs" serves as valuable input. Given the scope of changes requested, PE authors need to think about:

• How this could improve use of PE objects in other contexts besides OIDC
• Layering, i.e. is the base spec a set of useful objects like input descriptors that will appear in higher-level specs
• Framing, i.e. are these different PE profiles?

[OR13]

Regarding 2... I think the point about constraints is not being interpreted correctly...

The verifier says : "I want X,Y and Z".
The prover says: "X is here, Y is over here, and Z is here"...

In the case that X, Y and Z are all different kinds of VC or vanilla JWTs... you can see why the prover needs to explain how they are satisfying the request...

If they don't, the verifier needs to do a full search on all presentation content to match claims across, VC, VPs, JWTs and bananaOctopuses <- daniels preferred assertion format....

This whole thing would be massively simpler, if PE ONLY applied to W3C VC Data Model... but it doesn't... it applies to anything.

[kimdhamilton]

agreed, and that's something that's hard to remember about this spec (i.e., Daniel's preference for banana0ctopus assertions and the like)

It would be nice if we could simplify in cases where the context is clear. In OIDC4VPs for example, they are introducing a field that will contain VPs.

[JaceHensley]

For 3 is this the top-level id in the Presentation Definition or the id of the Input Descriptors?

I do like the layering idea, allowing someone to use just Input Descriptors without having to use the full PE spec for processing (from my POV that's what OIDC wants). But that might also cause fragmentation and confusion

[kimdhamilton]

actually both