Requesting Verifiable Presentation
Relying parties can have quite complex needs in terms of the VCs/claims they require to be inserted in a VP. The current document only has a simplistic way of requesting claims. For example, it does not allow for disjunctive claim requests but only conjunctive ones. Furthermore if the RP’s requirements are sent privately in the OIDC protocol between the RP and OP, so there is no guarantee that this request will conform to privacy legislation such as GDPR. For these reasons I would like to request the option of sending a pointer to a public policy server where RPs can store their policies. This has a number of advantages such as:
i) the same policy can be referred to by multiple RPs e.g. a policy for entering all the nightclubs in a region or country
ii) the ICO can inspect RPs published policies to see that they are compliant with legal requirements
iii) this stops unscrupulous RPs sending a privacy revealing policy to an OP but notifying the ICO of a different more privacy protecting one.
iv) it allows more complex policies to be specified according to need e.g. the policy store could hold a DIF PE policy or another policy format defined by a federation of users.
This feature can be enabled by introducing a new property “credential_policy” as an alternative to “credential_types” where “credential_policy” is defined as
"credential_policy": {
"policyURL": "<url of public policy server>",
"policyMatch": {
"any": "definedPolicyMatchingObject"
}
}
The policy match could be a simple “type” with any string value, e.g. “type”:”my resource policy” or it could be an “action” on a “resource” e.g. {“action”:”enter”, “resource”:”nightclub”}.
Comments (26)
-
-
I suspect the ideal model is that the credential is defined at issuance time and requests for that credential need to work within that definition.
Otherwise, the software the holder is using will not understand how to perform activities like informed user consent - and you cannot really trust the verifier to send dynamic, displayed content for display to the user without such a system being abused.
-
I think such policy can be part of the Verifiable Presentation itself - in
termsOfUse
property for example? -
@Daniel Buchner How can this be done using Presentation Exchange?
-
reporter Torsten “However, I would never use this exclusively simply because it’s to static and unnecessary limit the RP’s ability to request the credentials/claims required in a certain transaction.”
This is not how we use it. We implement least privileges by having different policies for each resource so that as the user moves around an RP’s different resources different policies can be activated. With traditional SAML and OIDC login the user gets maximal privleges as all the attributes are sent on login. With policies per resource the user gets least privileges.
-
reporter Kristina “I think such policy can be part of the Verifiable Presentation itself - in
termsOfUse
property for example?”Not so, because we are talking about the request to the user from the RP, not the response (the VP is the response which contains the VCs that match the policy)
-
reporter Kristina. re presentation exchange. This can be stores as a policy in the policy server and the request can point to it.
-
With OIDC, a RP can request the minimal set of claims it needs with every transaction (login). The most privacy preserving way to do it is the “claims” parameter as defined in https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter.
-
Just FYI.
OpenID Connect’s request_uri facility actually was partly designed for this purpose so that the “trust framework operator” or “privacy protection agent” can check for collection minimization adherence etc.
-
reporter Thanks Nat. I think this provides what I was looking for wrt to the RP telling the OP where to find its claims requirement policy. If you agree that request_uri can be used for this, then we can mark this issue as resolved by saying, use the request_uri to encode the policyURL and policyMatch parameters.
-
reporter p.s. the DIF presentation request could be transferred this way as well, and that will also resolve issue
#1230 -
- changed status to open
It was proposed on the 20-May-21 working group call to close this issue, since it's being addressed by the new draft https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html .
-
reporter Can I request that the openid-connect draft contains an example in Section 9 for the use of the request_uri parameter to point to where the verifiable presentation claims requirement policy can be obtained. Thanks
-
reporter As I read Section 8.1 it does not seem to be possible to use the request_uri parameter to specify which types of claim are required, since the text mandates credential_types to be present, viz:
credential_types
Object array containing definitions of credential types the RP wants to obtaintype
REQUIRED String denoting a credential type -
A request_uri (as defined in https://openid.net/specs/openid-connect-core-1_0.html#RequestUriParameter) refers to a complete OIDC request. So using this in conjunction with OIDC4VPs means to create a request including the claims parameter following the definition on the draft and publish it under a suitable URL, which becomes the request_uri.
-
reporter In addition the OIDC standard definition for request_uri, as I read it, does not fulfil exactly what is needed, because it requires the claims to be specified in OIDC format rather than in some externally defined policy format viz:
request_uri OPTIONAL. This parameter enables OpenID Connect requests to be passed by reference, rather than by value. The
request_uri
value is a URL using thehttps
scheme referencing a resource containing a Request Object value, which is a JWT containing the request parameters.What is actually needed is a reference to a publicly accessible policy store, where the policy can be retrieved by anyone (including the ICO to ensure conformance to GDPR). So the request_uri should contain the https location of the policy server, plus a match parameter/search string which enables the policy server to locate the referenced policy and return it to the OP.
-
reporter The current OIDC claims mechanism is too simplistic for a large number of VC use cases, in which a number of alternative VCs are required, with selective disclosure rules for each one. As I read it, the existing OIDC claims mechanism does not support disjunctive requests, nor selective disclosure of attributes from a credential. Also, if VCs really take off, the types of VCs will explode (consider the different types of plastic cards that are available today, there are hundreds if not thousands of them). So an extensibility mechanism for claim types will need to be supported, which VCs do.
-
If you want to specify a policy in some non OIDC format, I think you are looking for a different extension. OIDC4VP (in the same way as OIDC4IDA) extend the existing OIDC syntax to extend the functionality for OIDC RPs.
The extension you might be looking for would need to specify how non OIDC formats need to be transformed into something an OIDC OP can process.
Can you please give a concrete example?
re your original requirements in this ticket:
- complex requirements (such as this credential type or another one or some combinations) do require a more sophisticated request language. The idea is to adopt PE elements (optionally) for that purpose.
- If you want to implement legal compliance by restricting the dynamic of OIDC authentication requests, the OP must also enforce static requests only for the respective RPs. This , in my opinion, should be described in a separate spec along with architecture and trust thoughts, as it is applicable to all kinds of OIDC deployments (not only those using VPs).
-
reporter The model I am using is for a SIOP in (or next to) the user’s VC wallet. The RP sends its policy reference to SIOP and SIOP passes it to the wallet. Existing VC wallets already process policies from RPs and produce a VP to satisfy the policy. But they all use different protocols. I would like them to converge on OIDC SIOP. So today there is no problem in VC Wallets handling policies in different (non OIDC) syntaxes. The SIOP hands the policy reference to the existing wallet in the smart phone, and it knows how to process the policy in whatever syntax it is in. The DIF PE work is attempting to standardise this policy format, but until that is widely accepted we will have different policy formats. However, that is not an issue, since the public policy server can hold the same semantic policy in different syntaxes allowing the wallet to pick up the syntax it supports. I am giving a presentation about this to the Linux/CCI group this Tuesday if you are interested.
-
reporter To answer Torsten’s specific questions and points.
- The extension you might be looking for would need to specify how non OIDC formats need to be transformed into something an OIDC OP can process. Ans. The SIOP wont process the policy, but the VC Wallet will.
- Can you give a concrete example. Ans. I have a video on Youtube showing the purchase of a car parking permit online by presenting three VCs with selective disclosure from each and combining them into a VP to return to the RP. But of course if currently uses HTTPS and not OIDC protocols. You can watch it here https://youtu.be/w0FJayxCYwk
- The idea is to adopt PE elements (optionally) for that purpose. Ans. That is not represented in the current protocol draft, hence this issue. But if we agree to represent the semantic content of PE as OIDC claims that could work. But it does not answer the compliance issue.
- f you want to implement legal compliance by restricting the dynamic of OIDC authentication requests…Ans. There is no intention to reduce the dynamicity. On the contrary, the mechanism I am proposing is just as dynamic as what you have today but also supports least privileges since different policies can be returned to each resource access request. We demonstrated this several years ago to the NHS, and describe this in our paper David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant, Samer Wazan, Manreet Nijjar “Improved Identity Management with Verifiable Credentials and FIDO”. IEEE Communications Standards Magazine. Vol 3, Issue 4, Dec 2019, Pages 14-20. You can download this for free from https://kar.kent.ac.uk/80304/
-
- changed component to Verifiable Presentation
-
assigned issue to
-
During the SIOP discussion today Justin described the use of
request_uri
in the OpenID Connect spec section 6.2.While there are known security challenges using this pattern for a traditional authorization requests where the URI could point anywhere, in the use case described in this issue the URIs would all be well-known trusted endpoints from a policy server or as part of a trust framework.
The by-reference request pattern also already supports the ability for the client to include values such as the nonce per-request, only the trusted fixed values are sourced at the URI.
I believe this is readily usable for policy/framework use cases with SIOP and presentations where there is a larger agreement in place on the authority of the hosted request objects.
-
reporter @Jeremie Miller thankyou for summarising our discussion today.
-
This issue seems to be duplicative with Issue
#1340and we are reaching the same conclusion in both issues ,so could we merge the two issues into this one and rename this one to “Sending the presentation definition by reference“? -
reporter Yes I agree. They can be merged
-
- changed status to resolved
This issue has been merged with Issue
#1340. - Log in to comment
Having the option to refer to an externally hosted credential request seems an interesting option wrt auditing and so on.
However, I would never use this exclusively simply because it’s to static and unnecessary limit the RP’s ability to request the credentials/claims required in a certain transaction.
Additionally, there are other solutions to cope with large requests. Namely PAR is increasingly used for that purpose (and part of FAPI2).