Move PE Definition to correct property location

[Daniel Buchner]

The PE Definition is currently placed under the verifiable_presentations property, which is a deviation from the spec. Can this be relocated under a presentation_definition property, to retain interop with other implementations? We might be able to advocate for a change in the PE spec that special cases it under this OIDC SIOP property, but devs would probably prefer to have it always appear under the same property, for consistency sake.

‌

[Anthony Nadalin]

I don’t understand the request as this specification is not a duplicate of the PE specification, changing the parent would not make it compatible

[Daniel Buchner]

The goal is to enable spec-compliant PE use across all credential exchange envelope protocols, including the OIDC SIOP envelope. PE unifies credential requirement evaluation and submission across all envelope protocols, eliminating the vast majority of needlessly duplicative rework devs and implementers have to undertake across the ecosystem. To do that, the properties should match the PE spec as they are defined.

[Torsten Lodderstedt]

The structure of the element is the same, my aim would be to even use the PE JSON Schema to validate our examples. We just gave the element a different name to better fit its surroundings so developers are not confused by an element that somehow looks unusual.

[David W Chadwick]

Its not clear to me that wallet providers are going to support a whole host of different transport protocols. For example, as Kaliya pointed out recently, the DIDcomm world uses a peer-to-peer protocol model whereas OIDC uses a client-server model. Wont wallet providers chose their preferred protocol and stick with that?

[Daniel Buchner]

@David - I definitely believe providers will support at least OIDC + whatever async message based protocol rises to greatest prominence (along with possibly a browser/OS native one in the future). The async message option will become a more and more obvious necessity, given how many credential/data exchange processes will extend outside the bounds of any session, frame lifetime, or even same-device interaction assumption. When things like DID-relative endpoints are in play, it will provide for async flows where fulfillment is not a linear activity bound to the session/account on a website - the Issuer may drop off your issued cred to your DID-relative datastore days later, which you can access/interact/facilitate on any device you own.

[David W Chadwick]

@Daniel. I am really glad to know that you think wallets will support OIDC as this has seemed to me to be the natural choice all along. We already have one eSSIF project that does this (admittedly using ad-hoc mechanisms until SIOP v2 is published). I am less convinced about what the future will hold, and therefore I dont think it is sensible now to guestimate what async protocol will dominate, or even if one will be needed. Therefore we should build in support now for some future possibility that may or may not transpire. Standardised in the future what is needed in the future.

[Daniel Buchner]

@David this isn’t about what happens in the future - 50 organizations have implemented at least one other envelope in addition to OIDC SIOP, so this is a present issue, not a future one. Additionally, there is no compelling reason to deviate from being spec-compliant, as there is no issue created from simply being spec-compliant.

[Jeremie Miller]

During the discussion on the most recent SIOP call, I suggested a simple way to support both needs here by simply using the presentation_definition property within the verifiable_presentations claim request.

This preserves the claim name in both the request and response as well as meets the expectation of the PE draft to have a consistent property name.

Torsten also noted that this works well for the vp_token request syntax by also having a consistent presentation_definition within it.

[Torsten Lodderstedt]

here is the respective PR https://bitbucket.org/openid/connect/pull-requests/23/introduce-presentation_definition-element

Please review and comment/approve.

[Kristina Yasuda]

This can be closed as has been resolved by the merge of PR #23