Include input_descriptor `id` in OIDC4VP response and request

[Kristina Yasuda]

In DIF PE / OIDC4VP call, it was pointed out that with module-approach, it is acceptable not to use presentation_submission , but not including input_descriptor.id in the response will prevent RP from knowing which VP is sent back in response to which input_descriptor.

In example 9.1.2 in OIDC4VP, this would mean adding verifiable_presentation.id

{
  "kid": "did:ion:EiC6Y9_aDaCsITlY06HId4seJjJ...b1df31ec42d0",
  "typ": "JWT",
  "alg": "ES256K"
}.{
   "iss":"https://self-issued.me",
   "aud":"https://book.itsourweb.org:3000/client_api/authresp/uhn",
   "iat":1615910538,
   "exp":1615911138,
   "sub":"did:ion:EiC6Y9_aDaCsITlY06HId4seJjJ-9...mS3NBIn19",
   "auth_time":1615910535,
   "nonce":"960848874",
   "verifiable_presentations":[
      {
         "format":"vp_jwt",
         "id": "id_document_1"
         "presentation":"ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="
      }
   ],
   "sub_jwk":{
      "crv":"P-384",
      "kty":"EC",
      "kid": "c7298a61a6904426a580b1df31ec42d0",
      "x":"jf3a6dquclZ4PJ0JMU8RuucG9T1O3hpU_S_79sHQi7VZBD9e2VKXPts9lUjaytBm",
      "y":"38VlVE3kNiMEjklFe4Wo4DqdTKkFbK6QrmZf77lCMN2x9bENZoGF2EYFiBsOsnq0"
   }
}

Building up on Issue #1256

‌

[Kristina Yasuda]

opened at 07-13-2021 SIOP call

Sister-issue filed at https://github.com/decentralized-identity/presentation-exchange/issues/231

[Michael Jones]

On the 22-Jul-21 SIOP Special Call, people pointed out that several existing Presentation Exchange implementations already don’t use the id field. Therefore, it seems like including this should be optional.

[David W Chadwick]

We discussed this again on 22 July and concluded that it should remain optional as it is a potential performance improvement for the verifier, depending upon how it checks the VP against its policy.

We also identified that a VP that contains this additional information as a property/value should have a new VP type and schema defined for it, so that the recipient can tell what type of VP is being returned.

[Torsten Lodderstedt]

Based on the discussions in the joint DIF/OIDF call on Aug 4th, I suggest to clarify whether presentation submissions are a useful addition to OIDC4VP. If not, there also no need for input descriptor IDs.

[Kristina Yasuda]

id that maps with presentation submission is presentation_definition.id

this input_descriptor_id is different and is used to look up in response to which requirement a particular VC is being sent in the response

[Oliver Terbu]

@Kristina: is this issue addressed by https://bitbucket.org/openid/connect/pull-requests/44 ?

[David W Chadwick]

the difference is that in this issue we are suggesting that the id is optional but in 44 it becomes mandatory as presentation submission is mandatory. I still maintain that presentation submission should be optional. The current design places all the work on the constrained device (wallet/smartphone) and makes it most efficient for the RP, which typically will have more processing power. This is the wrong design approach. We should lighten the load on the wallet as much as possible in preference to lightening the load of the RP.

[Jeremie Miller]

Related, not only is the wallet likely to be more constrained, it also has to be treated as a potentially hostile entity.

Every requirement added to the wallet response needs to be scrutinized as it comprises the surface area by which a wallet can use to confused or find weaknesses in verifier processing.

The verifier will always have to fully validate all presentation data, every value must be questioned and checked, so IMO there is little reason to optimize for the verifier logic when the optimizations may not even be able to be trusted.

[Torsten Lodderstedt]

We are talking about Smartphones, right? Smartphones able to perform cryptographic operation, right? Why are those smartphones (or the wallet) unable to add a piece of JSON data to a response? Data that the wallet already has since it somehow needs to map the input requirements to the response data internally.

Moreover, this is not an optimization. The presentation submission tells the verifier where to look for presentations, which gives the wallet flexibility where it places the presentations. This, for example, allows us to avoid the array overhead in the vp token in case there is a single presentation.

As a result, the design is simple for simple use cases but allows for complex use cases.

[David W Chadwick]

The current design requires the wallet to support EVERY feature of presentation exchange and therefore to be an extremely complex implementation. Recipients of policies (the wallet in this case) cannot know what the verifier will send, so must support every optional and mandatory parameter of the policy. This is the wrong approach in my opinion. We should be trying to limit the complexity of wallets, not the opposite. Simplicity was a critical success factor of OIDC, according to many public presentations of Mike. The addition of PE to OIDC4VPs turns this approach on its head, and makes complexity a mandatory component of OIDC4VPs.

My proposal is to adopt a two layer approach, with the OIDC4VPs protocol being able to request (by reference) the required VP and then return a simple VP (or set of VPs) to the RP for it to validate. We can then layer additional policy languages on top of this protocol via the referenced policy location, but in all cases the same VP (or set of VPs) will be returned by OIDC4VPs.

[David W Chadwick]

@jeremie. Its probably worse than what you say (from the user’s perspective). My understanding is that if the wallet mis-states the presentation submission, but even so the VP is correct and fulfils the RP’s policy, nevertheless the user’s request will be rejected. So it would appear that the verifier is not checking the VPs content “as is” but only to the extent that the wallet says it should be checked.

[Torsten Lodderstedt]

I understand your concerns. I don’t see how call by reference will address it. What we could do is to define a mandatory to implement baseline of PE features and add additional profiles.

[David W Chadwick]

Call by reference addresses it by removing all knowledge of the policy from the OIDC protocol. With a public policy server that is able to return the same semantic policy in different syntaxes that different wallets support, the wallet will make the request to the policy server ‘read semantic policy X in my syntax Y’. It will evaluate the policy and return the VP(s) that match it. Different wallets will read the same semantic policy in their own syntax and return the same VP(s). This does not require OIDC to know anything about the policy syntax or semantics. OIDC only needs to carry the policy reference from the RP and return the VP(s) to the RP. Different policies can then be layered on top of this. Eg. a community might decide to support policies in XACML format (an OASIS standard), or in different profiles of PE etc.

Interworking within a trust federation will then be enabled by the federation specifying its own policy requirements. If global interworking is required (as opposed to interworking within a trust federation) then we should specify a simple policy format that all conforming wallets should implement in order to provide a minimum global interworking system e.g. return one VC of one type issued by one issuer.

[Torsten Lodderstedt]

How does a RP/Verifier pick the policy? How is the policy defined?

[David W Chadwick]

In general this will be a decision of the trust federation that the RP is a member of. It is envisaged that some federations will generate a set of policies that are usable by all federation members of a particular class e.g. enter a nightclub, purchase alcohol, access adult web site, apply for government document etc. as applicable to the federation. RPs will reference these and wallets will pick them up from the public policy server. Other federations may provide tools to RPs to specify their own policies. We have produced an open source tool for specifying policies (semantically) and a demo is on Youtube here

https://www.youtube.com/watch?v=Dv-4RovYrC0

We also have a policy convertor that converts the semantic policies into our proprietary policy syntax and stores it in a public policy server. It will be easy to create a tool to convert the same policies into PE syntax and store them in the same public policy server so that PE wallets and our wallets can download the same semantic policy in different syntaxes.

[Jeremie Miller]

How does a RP/Verifier pick the policy? How is the policy defined?

In the simplest of systems, it’s just a static URI. RP/Holder/Issuer all agree to use the same URI that is associated with a definition of policy/format/claims/etc. The URI could point to a developer page describing these things, or to a policy server, or even be a urn: or custom scheme that the implementors all use based on the trust framework’s documentation.

Such an approach imposes no heavy requirements on any of the parties except that they recognize and match the URI to the correct handling logic and data as defined by the owner of the URI. It doesn’t support dynamism, but it is the lowest common denominator for simple systems and very easy to define an interoperability profile around.

‌

[Kristina Yasuda]

we can close this in the next SIOP call since in DIF-OIDF calls it has been agreed that in OIDC4VP, presentation_submission MUST be included in the ID Token.

See section 6.2 of OIDC4VP

[David W Chadwick]

I dont believe that this was agreed in DIF-OIDF call this week. Daniel gave a reason why his particular implementation needed the presentation submission parameter to stop DOS attacks on his system. He said that an attacker could send 1000 ZKP VPs in response to a request for one or two VCs and his implementation would have to cryptographically validate all 1000 VPs before determine which VP satisfied which policy requirement if there was no presentation submission in the response. He believed that including presentation submission would nullify this attack. However, any RP that gets a 1000 ZKP VPs in a response to PE policy request should dump it immediately without needed to evaluate the presentation submission parameter because it obviously is not a valid response. Again I consider that presentation submission should be an optional parameter that some wallets might wish to provide.

Good protocol design is almost always to restrict what should be sent but to be flexible on what the receiver allows. Mandating this parameter is the opposite of this good design principle, and furthermore, given that PE mandates that RPs must reject valid VPs that satisfy the RP’s policy simply because the presentation submission parameter was wrongly formatted is also against this good design principle.

[Kristina Yasuda]

PR #79 that removes an option to embed VP in the ID Token introduces the option to put presentation_submission in the VP as the preference, while implementations will still be able include presentation_submission in the ID Token if they cannot put it inside the VP because of the VP format or if they want to provide more information

[David W Chadwick]

In my opinion OIDC4VPs/SIOPv2 should be independent of both the policy for requesting one or more VPs and the contents of the returned VPs. In this way we make OIDC future proof against all changes in the policy language and the VP format. OIDC should simply be a transport mechanism to carry a policy (any policy) and return a result (any set of VPs), without necessarily specifying either in detail. The detail can be in meta information either statically published by the RP and SIOP/Wallet or dynamically transferred in the OIDC protocol. This detail needs to be extensible to allow for future enhancements to both.

(Note there is already discussion about PEv3 - this should be evidence enough not to bake any policy into OIDC)

[Kristina Yasuda]

superseded by the events. agreed to include presentation_submission in the response.