OpenID4VP

OpenID4VP copied to clipboard

WG agreed on the process outlined here as a way forward to approach query language discussion in OID4VP.

Following up on step 1 of what was agreed there, below is a document that started compiling requirements for the query language in OID4VP: https://docs.google.com/document/d/1OSnRT9QB_8OiPGgfg3IbZnoCJtat8chYkJbcthXGf_g/edit

please review and comment directly in the google document.

I made substantial comments in the document, as requested. All are aimed at simplifying implementation requirements.

For instance, they point out that:

• Requesting multiple credentials at once is not a core requirement.
• Having an algebra to specify combinations of alternatives is not a core requirement.
• Several of the proposed features are credential-format specific and not universally applicable.

IMO, in the document it is requirement to list the use case and the purpose for each requirement clearly. Also what community or ecosystem requires that. Especially for more advanced/complex features, we would also need to find out whether those are already in production. I want to avoid that we start with a list of requirements where it is unclear how this initial list was even compiled and what the purpose is of each requirement. I would prefer we start with a list of fully uncontroversial requirements without premature optimization.

As much as is possible (and it is understandably difficult to do given the context of all this) this kind of document should be about what is actually needed in a query language rather than describing features that PE (theoretically) provides, which is somewhat how it reads now.

I responded to a few of Mike's comments. But just to repeat one particular answer here:

Requesting multiple credentials at once is not a core requirement. Having an algebra to specify combinations of alternatives is not a core requirement.

From my understanding it is a requirement (from the EU) that it is possible to request a PID and a matching credential that uses claims based binding (both from the same wallet) in a single transaction. Hence if we were to deprecate PE in OID4VP, it is a requirement for whatever replaces PE. Whether that feature is mandatory to implement seems separate to me.

As much as is possible (and it is understandably difficult to do given the context of all this) this kind of document should be about what is actually needed in a query language rather than describing features that PE (theoretically) provides, which is somewhat how it reads now.

@bc-pi I have not included anything that I thought is hypothetical and included only the features that I know at least one use-case/implementation. would appreciate if you could point out specifically which requirement/feature you think is hypothetical and I am happy to provide a use-case/implementation example. concrete feedback really helps make progress...

The ability to ask for and receive more than one credential in a single OID4VP exchange remains something I believe brings more complexity than value (I've said as much back to at least OSW last year), and is the source of at least a good amount of the difficult complexity in PE. Of course, there are use-cases for multiple credentials, but they could be handled up at the application layer with more than one OID4VP exchange in the session/transaction. I am aware that you disagree with me here, but that doesn't make it invalid.

The ability to ask for and receive more than one credential in a single OID4VP exchange remains something I believe brings more complexity than value (I've said as much back to at least OSW last year), and is the source of at least a good amount of the difficult complexity in PE. Of course, there are use-cases for multiple credentials, but they could be handled up at the application layer with more than one OID4VP exchange in the session/transaction. I am aware that you disagree with me here, but that doesn't make it invalid.

In general, I consider that to be able to ask for multiple different credentials can be tackled by application level. The ability, though, to reply (to a single requirement) with multiple credentials I think that it is not a corner case.

A wallet may hold multiple credentials of the same format and type but representing different datasets.

For instance, present your diplomas (in sd-jwt-vc)

One may argue that this could be solved also with multiple presentations, yet there are cases where the number of such credentials (instances) is not so small.

So, single query perhaps defining the number of the results (credentials):

• None (implied)
• One
• top X

A wallet may hold multiple credentials of the same format and type but representing different datasets.

I think we should distinguish between cases where a relying party wants to, in one request say "I want your drivers license and I will accepted it in this format or that format", from the multi-credential request case which is "I want your DL AND diploma". With the former case only a single credential at maximum is ever sent in response, whilst the latter is where multiple credentials can be returned and where I believe others are highlighting the inherent complexity lies.

This usecase "Verifier is able to express claim based binding" I don't agreed with being a requirement. As I've said in the comments of the doc, it can easily be addressed through multiple requests and ironically is how relying parties would generally request this information from a user when scanned copies of physical documents are being requested. The functionality as implied by the proposed requirement would likely be a bigger disruption for existing relying party websites to implement then simply allowing them to request each credential individually.

One may argue that this could be solved also with multiple presentations, yet there are cases where the number of such credentials (instances) is not so small.

More generally for the multi-credential usecase in my experience many relying parties don't want to take such a risk of aggregating their requirements together into one multi credential request, because for instance if the user doesn't have all the information ready at the time a relying party makes a request it can be very difficult for the relying party to help guide the user on what to do next. Another variation of this case is what if the relying party needs a DL and diploma, but the user has the DL in a wallet and a scanned copy of a physical document for the diploma? Given how credentials are being adopted I think usecases where some information is sourced from credentials and the rest from other existing sources is going to be frequent.

More generally for the multi-credential usecase in my experience many relying parties don't want to take such a risk of aggregating their requirements together into one multi credential request, because ...

I'm wondering if there are 2 conflicting points of view here wrt the role of the wallet/user agent in orchestrating the flow (and if we settle that, the answer to complex requests becomes clearer?)

1. One approach may be looking at the user agent to make as many business logic decisions as possible, since it has a view on the contents of the user's wallet and can help them decide 'up front'. Like when I apply for a passport, I have to show up at the office with all my relevant documentation in one shot based on information provided ahead of time, or
2. the other approach may be trying to keep the user-agent as naive as possible (1 credential at a time, limited options), and requiring the RP to take an active roll in guiding the holder through the process (give me presentation A, then presentation B, skip C, but presentation D is now required...)

From our experience at SecureKey / Gen we have seen a strong desire for option 1 mainly because of the UX cost associated with option 2 in having to continually re-engage the wallet (scanning multiple QR codes just to get through a process...), even though it is prone to errors as Tobias pointed out... and maybe if there is a way to alleviate the UX concern then option 2 becomes the preferred choice for all?

For option 2, is there a method (or a plan to build a method) to easily re-engage with the wallet for follow up presentations to help with the UX?

More generally for the multi-credential usecase in my experience many relying parties don't want to take such a risk of aggregating their requirements together into one multi credential request

Writing personally (not as a chair), unless we think we can convince everyone that multi-credential requests is a bad user experience, it's quite difficult to see how we can combine the feedback of people that say this feature isn't necessary with the feedback of people who say this feature is necessary (which we now seem to have a number of) and come to any conclusion other than that this feature is one that OID4VP must support because sufficient people do require it.

If someone sees a path to coming to a different conclusion please do explain it!

Writing personally (not as a chair), unless we think we can convince everyone that multi-credential requests is a bad user experience, it's quite difficult to see how we can combine the feedback of people that say this feature isn't necessary with the feedback of people who say this feature is necessary (which we now seem to have a number of) and come to any conclusion other than that this feature is one that OID4VP must support because sufficient people do require it.

Just to be clear in certain cases multi-credential requests are a bad user experience, because if an RP makes a request for 2 or more credentials and any of the following situations occur

1. The user has the required credentials held across different wallets
2. The user doesn't have all the credentials requested
3. The user has some of the credentials required in another form, e.g as a scan of a physical copy or in a file format like PDF

There is no way for a relying party to distinguish these above cases from other cases like the user just failed to provide consent to share the information. Which basically leaves the RP confused as to what to do next or how to adequately guide the user. I appreciate the attraction of this feature in the protocol, but what I think others in this thread have tried to signal is that this feature creates some pretty difficult problems that we need to be able to have an answer to.

From our experience at SecureKey / Gen we have seen a strong desire for option 1 mainly because of the UX cost associated with option 2 in having to continually re-engage the wallet (scanning multiple QR codes just to get through a process...), even though it is prone to errors as Tobias pointed out... and maybe if there is a way to alleviate the UX concern then option 2 becomes the preferred choice for all?

I don't necessarily have an answer to this at this stage, perhaps there are additional protocol features here we could consider. I would point out though that the UX inconvenience is notably less in same device flows as there is no QR scanning required, really the difficultly mainfests most is in cross device flows which require multiple credentials.

Concerning an additional protocol feature I would suggest that if the RP requests multiple credentials then whichever of the user's wallets answers the request, when none of them can answer the query in full for any reason, then we add a response type of "request single credential queries". In this way the RP knows to return a query requesting just one credential, and to repeat this operation until all of the credentials are obtained.

Concerning an additional protocol feature I would suggest that if the RP requests multiple credentials then whichever of the user's wallets answers the request, when none of them can answer the query in full for any reason, then we add a response type of "request single credential queries". In this way the RP knows to return a query requesting just one credential, and to repeat this operation until all of the credentials are obtained.

I don't see how this works, by design wallets are not able to understand what may or may not be in other wallets on a users device, so a wallet is unable to conclude "when none of them can answer the query in full for any reason" which is where in lies one of the inherent problems with multi-credential requests. A single wallet can only ever respond based on what they have or do not have.

I am assuming that all wallets have a GUI that talks to the human user. In our implementation, when we obtained a request for multiple credentials, the wallet evaluated this and if it could not fulfil it, it replied with an error to the RP without asking the user. But a simple modification to the wallet would allow the wallet to talk to the user in this case, and ask the user if they wanted to send credentials one by one. This would then trigger the new proposed error response code.

@tplooker

Just to be clear in certain cases multi-credential requests are a bad user experience, because if an RP makes a request for 2 or more credentials and any of the following situations occur

To clarify, I do agree with you that in some cases multi-credential requests are a bad user experience. I certainly did not intend to imply that we should force an RP that wants multiple credentials to request them all in a single request. Whether a single request (for multiple credentials) or multiple requests are used is to me clearly a decision that the VP specification can't dictate because which is the better UX is very likely use-case specific.

I don't necessarily have an answer to this at this stage, perhaps there are additional protocol features here we could consider. I would point out though that the UX inconvenience is notably less in same device flows as there is no QR scanning required, really the difficultly mainfests most is in cross device flows which require multiple credentials.

I think it could be good to explore this, but we should probably discuss in a separate issue as I don't think it directly affects the query language requirements.

What hasn't been mentioned yet and is also not in the document is the credential lifecycle. In general, holders and verifiers deal with "active" credentials only. But there are some use cases where expired/suspended/revoked credentials can be shared as well, which should be signaled to the wallet.

For VCs this can be quite complex, as a credential can be expired and suspended at the same time. The credentialStatus can contain multiple sources and the possible states are fully custom (though only suspended & revoked are common). Expiration of a VC is independent of its status. With current implementations in the VC world (e.g. Bitstring Status List), just sharing the credential status information also has major impact on the privacy - being able to selectively share it could be a use case (though it's hard for me to come up with good examples).

Presentation exchange deals with this here and here.

Use case examples:

• I have a club membership credential, which gives me membership discounts at third parties.
  • Suspended use-case: Due to non-payment, my credential is suspended. I can still use the credential to authenticate at the club portal to update my payment method.
  • Expired use-case: At the end of the year, my membership expires. I can still use my credential to renew the membership and receive a new credential for the current year.
• Even though my driving license is suspended, I can still use it to prove my age.

we did a session on this at IIW https://docs.google.com/presentation/d/1OxqQy4-WC5BmplCyuo-oKriXZVj2fBrGPCg7n9ryCcg/edit sounds like there is a rough consensus on the requirements.

WG mtg

• Please comment on this issue if you strongly object to the current set of the requirements within the next week (until april 26th).
• Otherwise, chair would consider there is rough consensus
• We are starting the discussion on the concrete syntax in a new issue (not opened yet) (that might influence the requirements, so this issue will remain open until updated syntax is merged)
  • please add new requirements coming up from the concrete syntax requirement (cc @QZHelen)
• Chairs to figure out if the PE spec is forked or moved to OIDF from DIF, to be able to update it in OIDF

Need to add a requirement for the syntax to support matching or filtering on a data element value (e.g. issuance state = CA / age over 21 = true).

@tplooker

Just to be clear in certain cases multi-credential requests are a bad user experience, because if an RP makes a request for 2 or more credentials and any of the following situations occur

To clarify, I do agree with you that in some cases multi-credential requests are a bad user experience. I certainly did not intend to imply that we should force an RP that wants multiple credentials to request them all in a single request. Whether a single request (for multiple credentials) or multiple requests are used is to me clearly a decision that the VP specification can't dictate because which is the better UX is very likely use-case specific.

I suspect there's a confluence of deployment scenarios and compatibility issues here that will lead to a user experience bad enough to limit multi-credential-single-request outside of very specific "known wallet" scenarios:

1. The set of desired credentials may only exist across multiple wallets for a particular end-user
2. A single credential may likewise exist within multiple wallets
3. Even if the transport protocol for the request can present a set of wallets which claim they can successfully complete the query/request, such a selector cannot understand and represent priority today (e.g. that the third wallet to answer is the one containing the best answer to the verifier, for some definition of "best")
4. The alternative to a missing digital credential may often be some process for verification of a physical document, e.g. none of the digital credentials requested are truly required, just preferred.
5. Credentials which dictate a presentation format will be limited in being returned alone or with compatible formats

My interpretation of these limitations leads me to believe the following: a multi-credential request will have a poor user experience outside of cases where the following aren't all true:

1. every alternative for fulfilling the request equivalently fulfills the verifier requirements
2. you can expect the multiple credentials provided by the relevant fulfillment option to be always held within the same wallet (such as both mandating issuance be to a wallet maintained by or in partnership with a country, or an employer wallet issued to employees via MDM), and may prefer that there is a user expectation of such exclusivity.
3. that wallet is expected to contain the desired set of credentials in digital form, rather than only containing a subset of them for particular end users (due to say a stratification of identity verification requirements)

My opinion of my own straw man is thus that this is limited usage. If we decide there are indeed scenarios that still warrant the complexity, we also should commit to guidance someplace documenting the expected usability limitations.

I don't necessarily have an answer to this at this stage, perhaps there are additional protocol features here we could consider. I would point out though that the UX inconvenience is notably less in same device flows as there is no QR scanning required, really the difficultly mainfests most is in cross device flows which require multiple credentials.

I think it could be good to explore this, but we should probably discuss in a separate issue as I don't think it directly affects the query language requirements.

I think we do understand the family of transports we will have and their characteristics at this point. As such, we can evaluate whether query features correspond to deployable functionality or if they instead just serve as implementer foot-guns.

A comment I put late onto the document which I will echo here - the purpose string has issues around user presentation (such as the lack of any localization) as well as concerns about abuse (such as providing conflicting messaging to the wallet to socially engineer the user to release sensitive PII).

As such, I would suggest that a query syntax allow for other future mechanisms to indicate purpose, such as (for examples) an index into issuer-provided purposes, generic localized handles for common purposes, or information gathered during determination of a verifiers authorization to request a credential and any restrictions on scope of usage.

A requirement doesn't cease to be a requirement because the technologies to fulfill that requirement aren't readily available. In the case of requesting multiple credentials, it is true that the credentials may very well be on different devices, applications, etc and the key material necessary to present those credentials may similarly be dispersed.

This does not mean not include the requirement for multiple credential presentation, it means we need to account for the variety of options one can present multiple credentials. It does not need to take place within a single transaction - such a constraint is unnecessarily limiting. Multi-part responses seem to be an inevitability. A worse user experience is not being able to fulfill a verifiers requirement at all or needing to have a sub-par workaround such as initiating multiple repetitive flows across the different contexts where a users data may lie.

Users will have multiple keys/identifiers, multiple credentials, multiple devices and wallets, and OID4VP needs to be flexible enough to accommodate all of it. We need to embrace the complexity already present in the ecosystem or else we risk more fragmentation with additional overlapping protocols.

Having a flat list of alternative requests is obviously needed. But we should stop there and not have an algebra for expressing multiple-choice alternatives. In particular, the "Three from column A and one from column B or two from column C" kind of logic in PE is over the top.

Support for requesting multiple credentials at once is something that not all use cases need. This should therefore be supported through an optional extension that not everyone needs to implement.

Not having to deal with multiple credential responses, for instance, means that no logic is needed to match requests to responses, which is a significant simplification.

"any piece of data in a credential" seems overly broad. Certainly selection by format, type, and claims makes sense. I would hope that issuer, purpose, and possibly intent-to-retain can be handled as claims and not special-purpose syntax.

There's an active separate discussion about signing algorithms, and I would not include them in the "any piece of data" statement.

Claim value matching is complexity that goes away if you don't request multiple credentials at once.

Agree that the combinatorial kind logic and requesting multiple credentials at once is something that not all use cases need and can handled up at the application layer with more than one OID4VP exchange in the session/transaction. It shouldn't therefore be a core or mandatory to implement requirement of this query language.

Just to try to avoid people going too far down unnecessary rabbit holes:

1. I don't believe we need to collect data on what may or may not be mandatory to implement at this stage, we just need to collect data on what requirements the language itself needs to support. (If you can see a reason for collecting that data at this stage please explain.)
2. (Speaking as a working group member rather than as a chair) I really feel like we've already established that requesting multiple credentials at once needs to be supported by the query language (but not necessarily mandatory to implement, see point 1) so I don't think we need to rehash that point any further. The requirement comes from some implementors and also the EU law. The counter argument seems to be "it adds complexity and you could do it instead with multiple presentations" but the problem there is it's a poorer UX in some cases, particularly (but not only) in cross device use cases, and I really don't believe we should force poor user experiences onto implementers.