[pending-close] Make requesting verifiable presentations extensible

[David W Chadwick]

The current specification of verifiable presentation selection (section 8 ) is fixed to one edition of the presentation exchange specification (v1) which makes the protocol inflexible, fixed in time, and incapable of adapting to new ways of requesting verifiable presentations. For example, v2 of PE is currently being specified, as is a simple profile of PE but neither of these are catered for.

The proposal is to replace the current fixed format with a type and value, where the type defines the contents of the value. The various types can be specified in the standard or in an IANA registry.

This means replacing the following data structure from the first non-normative example from section 8

{
"id_token": {
"acr": null,
"verifiable_presentations": {
"presentation_definition": {
"input_descriptors": [
{
"schema": [
{
"uri":
"https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"
}
]
}
]
}
}
}
}

‌

with

{
"id_token": {
"acr": null,
"verifiable_presentations": {
"type": "<choice between pev1, pev2, pescp, any other registered type. pev1 is chosen here>",
"value": {
"presentation_definition": {
"input_descriptors": [{
"schema": [{
"uri": "https://www.w3.org/2018/credentials/examples/v1/IDCardCredential"
}]
}]
}
}
}
}
}

[David W Chadwick]

Similar in Section 8.2 the specification of vp_token should be changed from

"vp_token": {
"presentation_definition": {

to include a type and value i.e.

"vp_token": {
”request_type”: “<choice between pev1, pev2, pescp, any other registered type. pev1 is chosen here>",
"value": { "presentation_definition": {

[Michael Jones]

I believe we should move to PE v2.

[Torsten Lodderstedt]

I think we should move towards PE v2. This is a normative dependency, so we need to make sure that PE v2 is published before we publish OIDC4VP. We did that for other specs before.

[Kristina Yasuda]

At 2021-12-09 SIOP call, we agreed to move to PE v2 in Implementer’s draft review - examples updated in PR #85. We will continue discussing the issue in the PR whether we want to allow choices of the PE version.

[David W Chadwick]

@Torsten Lodderstedt We need to break this hardcoded dependency on any version of PE, and make the choice of PE one of several available options. PEv1 and v2 in all their glory are far too complex for most use cases, so implementors will not implement either in full. Keep it simple for success. So there needs to be a dynamic way for the RP and SIOP to determine which presentation requirements format they will use, whether it will be a simple profile of PE, or a particular format that a trust federation has specified for itself.

[Torsten Lodderstedt]

If you think PE is too complex. Let’s make it simpler.

A different topic is support of PE subsets. I agree, most applications won’t fully use it. If that means, wallets should not forced to support the full syntax, defining profiles makes sense.

1. If there is a need for profiles, I would expect DIF to define those.
2. The Wallet then can expose in its metadata what profiles it supports.
3. The Verifier then can check whether the profile it needs is support.
4. If the verifier sends a request with elements not supported under the particular profile supported by the wallet, the wallet should refuse and respond with an error.

‌

[David W Chadwick]

I have already written a simple profile for PE which we have discussed in DIF and this has already caused a simplification to PEv2 (which is good). We could indeed write a series of profiles. The one I have created I anticipate will cover 80% of the use cases for 20% of the effort (Simple conjunctive profile). We could write a simple disjunctive profile as well. And more complex ones as the need arises.

But I also want federations to be able to define their own presentation request formats if they want to by registering their own presentation policy formats. We do not know how many uses of SIOP there will be - but if SIOP is successful I am sure there will be uses of it that we have not yet thought of. So keep it simple, with a minimum implementable subset for global interworking, but extensible to allow federations to do their own thing as they see fit. Our aim should be to maximise adoption of SIOP OIDC4VPs, not restrict it by putting up very high barriers to adoption (which full PE is).

[Kristina Yasuda]

I don’t think anything in OIDC4VP implies that the implementors need to implement full VP. If you implement only MUSTs in PE (both v1 and v2) it’s actually not that complex.

We could say in OIDC4VP which features of PE has to be implemented at the minimum but I agree ideally that should happen in DIF.

With enough clarification, using PE as a query language should drive interoperability instead of raising bar for adoption. There should not be multiple options. If it turns out most of the implementations deviate from PE, we should drop it and come up with a language that can be used for all. But I am hopeful that given a good relationship we have with DIF there will be no need to drop PE entirely and we can shape PE with the feedback from the OIDC4VP implementors.

Btw, the minimum profile you are suggesting in DIF would not work as MTI in OIDC4VP because it makes presentation_submission optional. That is the optional other that should not exist. Given that now submission will be pointing only to the format, signature and location of a VC.

‌

[David W Chadwick]

Standards are successful because they allow extensibility. OIDC does not fix the claims that can be requested or the scopes. X.509 does not fix the extensions. For OIDC to fix the policy language for requesting VCs is a retrograde step that will inhibit adoption.

‌

[Jeremie Miller]

For OIDC to fix the policy language for requesting VCs is a retrograde step that will inhibit adoption.

I agree 👍

‌

[Torsten Lodderstedt]

I don’t see how support for multiple presentation request formats facilitates interoperability. To the contrary it will degrade interoperability.

This is not an extension point. We selected PE because it was there and seems to be maintained and evolved by an agile community. If we think PE is not the way to go, we should rather switch to a different language.

[David W Chadwick]

this is definitely an extension point. Specifying policy languages is not within the remit of the OIDC group. Thus OIDC should allow any group that specifies policy languages to be able to use OIDC to transfer their policy. Forbidding this will minimise adoption of OIDC4VPs. Our objective should be to encourage adoption of OIDC4VPs by all groups that use VCs.

We already have several examples of different groups that are using OIDC that are not interoperable e.g.those using LD proofs and those using JWTs for one (but there are other examples as well). So you cannot use lack of interoperability as an excuse for not making policy languages an extension point, otherwise by this argument you would mandate JWTs for everyone, and https URL instead of DIDs (another non-interoperable feature of the protocol)

[Torsten Lodderstedt]

this is definitely an extension point.

What I wanted to get across is, it is not designed as an extension point.

There is not definitive truth in this discussion about Interoperability. We have to find a balance between broad range of options and interoperability.

It would be great to have a single credential format, but the reality in practice is different. However, I think we can cater for all those credential formats with one type of request language.

I might be wrong, so please share concrete examples of other ways to request presentations that you think should be supported.

[David W Chadwick]

I believe that most implementors of VC eco-systems have specified their own policy languages. The recent eSSIF-LAB Consent Record Demo on 12 December has a method for specifying consent policies and wants to either add this to PE or allow it to supplement other policy languages. So the range of policy languages is likely to be large as different groups determine what they need. This is why OIDC needs to be flexible and support all these different possibilities (in just the same way that it currently allows different groups to specify their own claims for their own use cases). I am sure you are familiar with the maxim “Let a thousand flowers bloom” and the market will eventually determine which policy language or languages are the most useful and therefore successful.

Whilst my favoured approach would be for OIDC to allow any policy language, I am not against OIDC recommending one policy language as the irreducible minimal subset that should be supported to aid interworking (e.g. such as the Simple PE Profile that I have suggested to DIF) as long as implementors can support different policy languages as well.

[Torsten Lodderstedt]

I’m pretty sure existing solutions use different policy languages, I would assume they even use different protocols. Some of them based on OIDC/SIOP some not.

The objective of OIDC4VP is to distill a common standard for the use case of requesting and presenting credentials. I don’t understand why you want to split the protocol in the middle and define parts of the protocol as a single protocol but other parts as extension point. The only reason I can imagine is backward compatibly with existing implementations.

Is that what you are looking for?

[David W Chadwick]

I am looking for three things

1. backwards compatibility with existing policy languages
2. forwards compatibility with policy languages that people are just defining (e.g. the consent policy) and ones that have not yet been defined.
3. low barrier to adoption of SIOPv2 4 VPs

‌

‌

[Torsten Lodderstedt]

backwards compatibility with existing policy languages

Why do you think allowing for multiple languages for requesting verifiable presentations is sufficient for backward compatibility? I assume existing implementations must change their protocol implementation to comply with OIDC4VP. Why can’t they also change this part of the protocol and foster interoperability across applications?

forwards compatibility with policy languages that people are just defining (e.g. the consent policy) and ones that have not yet been defined.

that sounds very generic to me. Why should someone develop a completely new way for requesting verifiable presentations if there is an existing way? What I see among implementers so far is excitement because we come up with a single solution they can just implement.

low barrier to adoption of SIOPv2 4 VPs

It might ease implementers to claim compatibility with OIDC4VP but it results in silos. Just as a litmus test: How would conformity testing look like?

[David W Chadwick]

Answers to your 3 questions.

1. The effort required to support OIDC is much less than the effort required to change the policy language and all the associated tooling and GUIs.
2. Because PE does not provide the functionality they require
3. Because PE is a very heavy lift and I don't know anyone who either thinks it isn't or who has implemented it fully. By insisting on PE you are effectively barring most people from implementing OIDC4VP. Is this what you are determined to do?

Concerning silos, you have already created several of them, so you cannot use this as a reason for not allowing policy extensibility. Your argument would be more credible if you removed all silos and made one mandatory to implement set of features for SIOPv2 and OIDC4VPs - preferably the set of features with the lowest lift and ease of implementation. Remember Mike’s mantra, Keep it Simple.

‌

[Torsten Lodderstedt]

I don’t mind to trim down PE (used by OIDC4VP) to a simpler profile. Aren’t you working on a proposal? Where can I find it?

What does PE miss?

What silos do you refer to?

[David W Chadwick]

The profile has been submitted to the discussions page of the PE repo (as a document). One of my next tasks is to turn it into markdown so that issues and PRs can be raised against it. This is one of my Christmas holiday tasks

PE misses GDPR requirements (e.g. retention period, purpose of use etc) which is what the Consent project has added. There may be other requirements that we are not aware of (I was not aware of the GDRP ones until I saw the eSSIF demo on 12 Dec.)

There are many silos e.g. see Issue #1379 or JWT vs LD-Proofs or 100+ DID methods.

[David W Chadwick]

The PE profile has now been published in the DIF Github repo here

https://github.com/decentralized-identity/presentation-exchange/pull/275

[Kristina Yasuda]

I was learning about OIDC Advanced Syntax for Claims which made me 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 - YouTube (21:15)

(cc @Daniel Fett )

[Kristina Yasuda]

PE v2 has been published and PE v1 implementations I am familiar with have been moving towards implementing PEv2.

suggest we keep current spec text requirement for PEv2 for the sake of interoperability and close this issue.

[Torsten Lodderstedt]

+1

[Kristina Yasuda]

pending close for few weeks, +1, no objection, closing

[Brian Campbell]

OpenID4VP -16 has “[DIF.PresentationExchange] Buchner, D., Zundel, B., Riedel, M., and K. H. Duffy, "Presentation Exchange 2.0.0", , https://identity.foundation/presentation-exchange.“ which says 2.0.0 but the URL (currently) goes to a “Pre-Draft” v2.X.X. Perhaps the ref should be changed to point to https://identity.foundation/presentation-exchange/spec/v2.0.0/ ? I haven’t read PE yet (cringe), but when I do, want to look at the right/relevant one for OpenID4VP.

‌

‌

[Kristina Yasuda]

sure, can change to https://identity.foundation/presentation-exchange/spec/v2.0.0/

[Kristina Yasuda]

PR #497