-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OID4VP Query language requirements document #144
Comments
I made substantial comments in the document, as requested. All are aimed at simplifying implementation requirements. For instance, they point out that:
|
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:
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. |
@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. |
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):
|
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. |
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. |
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?)
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? |
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! |
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
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.
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. |
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. |
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 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 Presentation exchange deals with this here and here. Use case examples:
|
we did a session on this at IIW https://docs.google.com/presentation/d/1OxqQy4-WC5BmplCyuo-oKriXZVj2fBrGPCg7n9ryCcg/edit |
WG mtg
|
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). |
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:
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:
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 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:
|
I will not follow the rabbit hole further but that should not be construed as agreement. |
I just wanted to follow up given I chimed in earlier (and I apologize for my absenteeism);
Thanks! |
chair hat on, I am done going through the comments received so far (in the issue, google doc and some received during IIW). Below are the list of requirements that we need to discuss in the WG and agree on the direction. The question is whether the query language should have an option to support these at all, and whether the feature is mandatory to implement for everyone is a separate question in issue #157. all the comments on the google doc are resolved, please use this new Github issues to reach agreement (not google doc) on these 5 remaining features. the list of requirements that seems to have rough consensus are summarized in issue #157.
|
to prevent this issue growing long, I opened individual issues to keep discussing each of the remaining items. please comment there |
is there a concrete proposal for a new query language? apologies if i missed it. Closest i've been able to find is: is each e.g.
|
There isn't yet - expect to see a proposal on next week's working group meetings.
That's an mdl example so probably isn't great at answering this point. As I understand it the proposal for nested objects is to just an array of strings syntax, e.g. something like |
specific proposal for an alternative query language has been made in #178 and the WG has agreed to use it as a starting point. |
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.
The text was updated successfully, but these errors were encountered: