Layering proposal for v3

[kimdhamilton]

Context

Currently, the PE spec is complex for at least 3 reasons:

1. It's hard to detangle which objects are needed for simple vs advanced use cases. An example of an advanced use case is submission requirements
2. Elements such as subject_is_holder, subject_is_issuer, same_subject, and statuses risk fragmentation. They are left up to implementors, and currently lack sufficient examples needed to determine fitness and adequacy for interoperability. We also don't have example implementations for these.
3. In attempting to be format-agnostic, it loses opportunities for clarity (potentially risking interoperability).

2 and 3 overlap -- in the context of a particular format, it's possible to be more precise about how the subject, holder, and issuer entities are determined.

These problems (and more) are what's leading to (what is now) a trend of creation of PE profiles, in which implementers define a PE subset that is implementable/testable. However, some of these profiles (targeted at the simple/80% use cases) look very much the same. David Chadwick's PE profile for OIDC is very close to the subset I have implemented, and (from what I understand) others have too.

This presents an opportunity to simplify the spec and improve interoperability. (Continuing to define profiles that intersect heavily, but differ slightly -- without work to unify the common intersection -- will result in fragmentation.) In v3 we should invert the approach, applying these simplifications to the spec itself and clarifying the role profiles will take

Proposed Presentation Exchange v3 Layers / Features

• Base layer = scaled-down version of Input Descriptors (see next section)
  • In this layer, the only constraints are field constraints (in fact, note that it's collapsed in the diagram)
• Submission requirements
• Collection of layers/features to address everything not included above -- additional constraints, predicates, etc
  • everything in this category needs to be revised for the reasons described in "context"
  • subject_is_issuer, etc may make sense to add in the context of format-specific considerations

TBD:

• terminology ("layer" vs "feature")
• spec structure (separate docs vs 1)

Draft (WIP)

See hackmd draft (WIP)

Additional Details

Diagram of resulting base layer

Note: only a few differences from David's profile:

• added format to input_descriptor per #279
• moved limit_disclosure out of this layer

Claim: this corresponds to an implementable base layer that we can immediately add a reference implementation and test vectors for. Exciting!

Proposed approaches to "everything else"

Break up constraints object

The current constraints object is especially confusing. It contains a mix of constraint types, some of which apply to an entire input, some of which apply to fields, and one which appears to apply across inputs (therefore possibly not belonging here -- see same_subject).

We can consider breaking this up (as I've done above with field_contraints) to make this more precise.

Add back remaining properties prioritized by ability to define in a testable manner

We can proceed by working through properties where we have specific examples and interoperability requirements. subject_is_issuer is a good example:

• OIDC has a special reserved issuer value for this, and an implementor would check something like issuer = self-issued.me
• A VC-driven approach might prefer to check that the issuer (id) field equals the credential subject (id) field

We can define a way that allows PE or PE profiles to define how these are checked.

[David-Chadwick]

@kimdhamilton I am fully supportive of standardising a minimum subset that everyone can agree on, and then having some way of indicating which additional layers/featurs any given implementation supports.

[Sakurann]

I agree with the direction. Would it make sense to have a spec, or its official profile that has only the base layer, without any "layers"? and probably, that one should not be called v3...

A quick comment on iss = self-issued.me. The fact that SIOP ID Token is signed by the user's private key does not change. but in the latest version of SIOP v2 that is going to the Implementer's draft, iss can be when the verifier knows SIOP identifier beforehand. See Dynamic Self-Issued OpenID Provider Discovery Metadata

[kimdhamilton]

Jan 13 Discussion

Proposals:

• Restructure -- not separate -- spec in this version (v2). I.e., no v3
• Initial pass is purely editorial
• Next pass, consider layering modifications (current discussion below)
  • critical flag on additional layers, meaning wallet can ignore if false (default) or (if true) must understand the layer or reject the request
  • This will likely need to be refined with further discussion
  • Some may have to have critical true
  • Discussed that some aspects are a concern of protocol, not data model

We think that we don't need an OIDC profile after this; OIDC can just refer to Presentation Definition section/component.

[Sakurann]

I am starting to think we don’t necessarily need to define minimum profile of PE - we can rather invest in defining a common metadata structure how OP advertises which aspects of PE it does or does not support.

For example,

OP metadata “presentation_exchange“: [“format“, “input_descriptors.id“]

or even provide a ready PE syntax to use in OP metadata

OpenID Connect Advanced Syntax for Claims has a similar approach: 21:15 of https://www.youtube.com/watch?v=DQqsuJwYXmc