Using scope Parameter to Request VCs
#44
Conversation
peppelinux
requested review from
Sakurann,
tlodderstedt,
rohe and
selfissued
and removed request for
Sakurann
|
Putting a URL to a bitbucket issue from where it was migrated because there has been some good discussion. |
|
|
||
| Such a scope value MUST be an alias for a well-defined Presentation Definition that will be | ||
| referred to in the `presentation_submission` response parameter. | ||
| In the case where all the Input Descriptors defined within the Presentation Definition are required within the request, the value contained in the scope parameter MUST match to the Presentation Definition id value. In the case where only a subset of Verifiable Credentials is required, each value contained in the scope parameter MUST match to one Input Descriptor(s) `id` value, as defined within the Presentation Definition. |
There was a problem hiding this comment.
I think I originally suggested adding both options: using presentation definition and input descriptor ids, but thinking about it I am not sure about this optionality. feature-wise, input descriptor level id might be enough, assuming that when submission requirements feature is used, both parties know how to map submission_requirements to the input descriptor ids (this should probably be made explicit if we go this route.)
There was a problem hiding this comment.
that's what I have in mind:
when the verifier requests all the input descriptors defined within its presentation definition (or the one within a common trust framework/assurance profile) the scope value must then contain the PE id.
when the verifier requests specific input descriptors, then the scope values must contain the required input descriptors ids separated by space.
Co-authored-by: Kristina <[email protected]>
…e normative language about that
|
@peppelinux As far as I understand @peppelinux wants to pass a reference to a vetted presentation definition. I think the most straightforward way would to utilize @David-Chadwick as far as I remember, you suggested that feature initially based on your implementation experience. Did you also use signed/attested presentation definitions? |
|
We also have a need for signed PDs, for instance for out of band discovery purposes. We are actually thinking about is using VCs to do the job, as parties already have all the support to handle these. That however is not really viable for OID4VP I guess as it would tie it to W3C VCs |
|
@tlodderstedt Our implementation did use the presentation_definition_uri. We then had a publicly accessible policy server from which PDs could be downloaded. We published the policy server as open source code. Our model was that a federation would have a set of PDs that all verifiers would use (e.g. all nightclubs would use the same PD to obtain the person's age). We did not think it was necessary to sign the PDs as their urls would be widely known, and wallets could have downloaded them already and stored them locally. The other feature that our policy server enabled was the support of different PDs in different formats and languages that were semantically equivalent. So wallets could retrieve the PD in its own language/format by appending the required format to its request to the policy server. |
|
that's why in our implementation we do not support presentation_definition_uri @David-Chadwick said something relevant about how to satisfy the requirement of non-repudaibility, since as far as I understand it uses a sort of trusted lits, provided by a trusted third party, where the participants fetches the policies related to one or more participant. However it is still in plain text, it's not long-lived and then it's repudiable over time |
|
@peppelinux Yes, we store the presentation_definition_uri in the ETSI trust list entry of the verifier. So this allows the wallet to check that the URI sent by the verifier in the protocol is the same one that the trust anchor verified when it created the entry in the trust list. This also allows the GDPR minimal disclosure to be verified, since the PD says what PII is needed for the verifier's service that is being accessed. In this way the verifier cannot change the PII it is requesting for its service without notifying the trust anchor and getting its trust list entry updated. |
|
@tlodderstedt I agree that allowing that the request to the we didn't reach the consensus about the proposed usage of the scope parameter because we assume that the scope values are not dynamic or variable and it should be known by the entities, then well defined in a shared trust framework or in an international spec regarding this PR, I would propose a revamping of its content according to this discussion to bring editorials and wording improvements, if any |
|
The openid4vp draft 04 reports the following text
during the dcp wg call it seems to me that we agreed that scopes cannot be aliases of presentation definitions ids or presentation definition input descriptors. If this is confirmed, the text in the current draft should be changed accordingly and this PR may be changed as well to produce the final text we want in the specs. Following the last times we have talked about this PR, it seems to me that the scopes must be defined within a specs, as openid connect core did for example, or a trust framework, and in a way that all the participants are able to know which scopes exists and how to use them. At the same time, following a chat with @jogu, it may be reasonable to say that if the scopes are used in the request, the presentation response must not contain a presentation submission json object but the accepted scopes which the response is related to. This is quite similar to what today already happen with the OAuth 2.0 token response, where the scope member is optional, or required if some of the scopes in the request was ignored or not supported by the AS in the response. |
|
@peppelinux the text in the spec is right. It just says that the scope in some way needs to be resolvable to a presentation definition, simply because otherwise the response cannot be interpreted by the verifier. We can also completely change the way the spec uses scopes and introduce a special treatment for responses based on requests with scopes. That would mean we end up with two distinct ways to request and present credentials. I'm worried about the additional complexity and don't see the benefit and would rather like to drop scopes altogether. As far as I understood your use case, you don't need scopes. What you want are references to cryptographically protected presentation definitions. I don't understand how scopes help you with this and why the presentation_definition_uri does not help. |
There was a problem hiding this comment.
I think this PR tries to add another way of requesting VPs using a certain way to use scopes but at the same time feels underspecified to me. It completely changes the way scope values are currently used in the spec (just as alias).
I would encourage a more comprehensive definition and examples.
|
|
||
| Such a scope value MUST be an alias for a well-defined Presentation Definition that will be | ||
| referred to in the `presentation_submission` response parameter. | ||
| In the case where all the Input Descriptors defined within the Presentation Definition are required within the request, the value contained in the `scope` parameter MUST match to the Presentation Definition `id` value. In the case where only a subset of Verifiable Credentials is required, each value contained in the `scope` parameter MUST match to one Input Descriptor(s) `id` value, as defined within the Presentation Definition. |
There was a problem hiding this comment.
Which presentation definition does this text refer to? Same for input descriptors.
|
@tlodderstedt instead of commenting details in this thread, I would say why this PR has born and what's its goal:
I should re-read this PR and its thread before committing anything else. What I remember is that during a DCP WG call some concerns was raised about using scopes as refs to Presentation Definitions, since these are defined by the RP's while the scopes, in OAuth 2.0, are absolute and well known by all the participant. That's why I decided to not continue in the direction of this PR and propose a different change. or differently. then, let's try to start over with an high level approach to bring what we want in the text and the implementation, then the right workings will come in advance |
|
I added a comment to italia/eudi-wallet-it-docs#152. I think we need to discuss why and how (and whether) we use scope values in the future to request credential presentations. |
|
This PR has been stuck for almost 6 months now. We should do something with it. Responding to Guiseppe's comments:
I'm not sure it's entirely clear that a PR is needed. As Torsten says the spec currently basically says "the credential issuer needs to communicate out of band to the verifier what scope value is associated with what nominal PE request". The same way in OAuth2 the AS needs to communicate out of band to the RP what a given scope value actually means. My understanding is that the whole concept of using scopes in this way was that it basically allowed bother verifiers and wallets a simple way to just not implement PE at all apart from potentially minimal parsing of the presentation submission in the response. The issuer's documentation just tells the developer of the verifier "hey, use scope=mobiledrivinglicense and you get will back a full mobile driving license".
The spec doesn't hint that it would be sensible to use PR id values. It feels a little redundant to say "scope values must comply with the syntax for scope values" and a little odd to single out space when you also can't use , ", £ or 😍. I think if we do anything with this PR it should just be to make it simpler and communicate the two above points if it's felt the current spec language isn't clear enough. Let me know if I missed something! |
|
closing due to lack of activity since my comment 8 weeks ago; if we want to do something here we should open an issue & discuss |
This PR aims to clarify how a Verifier requests VCs using the parameter scope. For achieving this, this PR uses normative languages about the following aspects:
This PR has strong relations to the issues listed below (to be alinged to the ones moves to GH, once done):