An RP should not be able to repudiate to have obtained a presentation

[peppelinux]

according to article 6a amending Regulation (EU) No 910/2014 as regards establishing a framework for a European Digital Identity, it says

This function should provide an easy, user friendly interface with an overview of all relying parties with whom the user has shared data, including attributes, and the type of data shared with each relying party. It should allow the user to track all transactions executed through EDIW

At this moment the RP cannot repudiate to have requested some data to a wallet instance, considering signature of the request, while it can repudiate to have received the vp from the wallet instance, because it doesn't return a verifiable proof about the data obtained. The RP at this stage just provide a response like the following one

  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store

  {
    "redirect_uri":"https://client.example.org/cb#response_code=091535f699ea575c7937fa5f0f454aee"
  }

while it may return a proof of the acquired presentation, in a form of signed JWT for instance, to allow the Wallet Instance to build a registry of the data provided to the RPs.

at the same time the RP may cheat, by saying to not have received nothing while it has.

This issue brings pro/cons and further complexity, it must be discussed more.

[awoie]

I can read two things in this issue @peppelinux :

1. having a mechanism that supports article 6a.
2. allowing non-repudiable Authz Response receipts.

Re 1. I would argue that the wallet is already enabled to implement the requirement by checking the Response URI result.

Re 2. I don't know if this solves the problem of RPs not issuing those non-repudiable Authz Response receipts if they want to cheat the user.

Are you proposing 2 to address 1 only? Because I'd argue that the requirement can be implemented already without 2. Or are you proposing 2 independent of 1?

[David-Chadwick]

This is where a trust framework comes into play. If the RP is registered as a trustworthy RP, which the wallet can determine at the start of the proposed advanced flow, then it is highly unlikely that the RP would try to cheat the user. If it does, the user can report it to the trust anchor and have the RP removed. If the RP is found to be untrustworthy at the start of the transaction, and the user still wants to go ahead and send their PII to the RP, then they should not be surprised if the RP tries to cheat them. So I suggest that trust frameworks are a protocol-independent way of handling this issue, (and any similar ones) and indeed when implemented, can help to simplify protocols due to the trust assumptions that can be made.

[awoie]

This is where a trust framework comes into play. If the RP is registered as a trustworthy RP, which the wallet can determine at the start of the proposed advanced flow, then it is highly unlikely that the RP would try to cheat the user. If it does, the user can report it to the trust anchor and have the RP removed. If the RP is found to be untrustworthy at the start of the transaction, and the user still wants to go ahead and send their PII to the RP, then they should not be surprised if the RP tries to cheat them. So I suggest that trust frameworks are a protocol-independent way of handling this issue, (and any similar ones) and indeed when implemented, can help to simplify protocols due to the trust assumptions that can be made.

@David-Chadwick are you saying this is out of scope of OpenID4VP and should instead be handled by the trust framework?

[peppelinux]

trust frameworks may be protocols agnostic

in the case of OpenID4VP and this issue, the protocol should provide a way to give a signed proof of the obtained data/vc to the Wallet Instances.

the Wallet instance, in possession of this signed proof, would build its historical registry of the given presentations to the RPs. Users, therefore, may use their Wallet Instance and consulting the historical registry and request to a specific RP the deletion of their data.

Might the RP repudiate to have obtained those data? If the wallet instance has a signed proof issued by RPs -> no.

[awoie]

trust frameworks may be protocols agnostic

in the case of OpenID4VP and this issue, the protocol should provide a way to give a signed proof of the obtained data/vc to the Wallet Instances.

the Wallet instance, in possession of this signed proof, would build its historical registry of the given presentations to the RPs. Users, therefore, may use their Wallet Instance and consulting the historical registry and request to a specific RP the deletion of their data.

Might the RP repudiate to have obtained those data? If the wallet instance has a signed proof issued by RPs -> no.

No, but the RP can always decide to not return the Authz Response Receipt if it is not genuine and if it can be assumed it is genuine because of a trust framework, then I'm wondering why we would need this feature. The wallet can already keep track of a transaction history by keeping track of the response to their Authz Response.

The only reason why I think this could be useful is because it represents a more harmonized method across different Response Modes. For example, with response_mode query it might be hard provide this information to the wallet.

What do other folks think?

[David-Chadwick]

"are you saying this is out of scope of OpenID4VP and should instead be handled by the trust framework?" Yes, because whatever protocol mechanism you introduce a cheating RP can usually (always?) bypass it e.g. by not sending any Ack message. And no protocol can determine the difference between a sent message that was not delivered and a message that was never sent, unless it is built on a lower level protocol that guarantees delivery and itself never fails. (To test this you could simply switch off the power supply at the critical moment.)

[awoie]

"are you saying this is out of scope of OpenID4VP and should instead be handled by the trust framework?" Yes, because whatever protocol mechanism you introduce a cheating RP can usually (always?) bypass it e.g. by not sending any Ack message. And no protocol can determine the difference between a sent message that was not delivered and a message that was never sent, unless it is built on a lower level protocol that guarantees delivery and itself never fails. (To test this you could simply switch off the power supply at the critical moment.)

I would agree with this statement but as mentioned in my previous comment, I do see utility of this Authz Response Receipt for UI reasons. If the wallet is using a flow that concludes with a browser redirect, then it is quite hard for the wallet to get the final feedback from the RP. Normally, this is covered by error responses but in OID4VP, the wallet is the OP, so no error response in that case.

Are there any other options of getting a reliable signal back to the wallet based on our current specification?

[awoie]

"are you saying this is out of scope of OpenID4VP and should instead be handled by the trust framework?" Yes, because whatever protocol mechanism you introduce a cheating RP can usually (always?) bypass it e.g. by not sending any Ack message. And no protocol can determine the difference between a sent message that was not delivered and a message that was never sent, unless it is built on a lower level protocol that guarantees delivery and itself never fails. (To test this you could simply switch off the power supply at the critical moment.)

I would agree with this statement but as mentioned in my previous comment, I do see utility of this Authz Response Receipt for UI reasons. If the wallet is using a flow that concludes with a browser redirect, then it is quite hard for the wallet to get the final feedback from the RP. Normally, this is covered by error responses but in OID4VP, the wallet is the OP, so no error response in that case.

Are there any other options of getting a reliable signal back to the wallet based on our current specification?

On the other hand I believe that it will be also quite challenging to add such an Authz Response Receipt to flows that don't have a Response URI. @peppelinux do you have an idea how that might work?

[peppelinux]

The RP responds with an HTTP response, after having obtained the presentation (eg: direct post from the wallet instance).

In the specs we don't say how the RP must respond to the wallet request. We assume HTTP Status code 200, but this aspect is an issue, because it is not specified (or I miss it and probably it would be improved from the editorial perspective).

having an http response with a status code 200, we may think to provide an application/json content-type, with a response object and the minimal information to proof the obtained response.

let's assume that a wallet presents 4 credentials, 1 required and 3 optional. One of the optional fails the validation, the RP in its response would give this evidence, without blocking the end-user authentication.

[awoie]

The RP responds with an HTTP response, after having obtained the presentatio

Right, that I understood. Do you have a proposal how this might work with pure redirect flows where there is no Response URI endpoint, e.g., if response_mode is fragment which is another possible option for OID4VP?

[peppelinux]

Actually I don't have a proposal but if the requirement is confirmed we can find a way, let's keep focused on the requirements. Solutions can be found.

[peppelinux]

@awoie WDYT enabling a response with content type application/jwt with signed JWT instead of a plain json object?

as oidc userinfo endpoint allows

[Sakurann]

@peppelinux I think the text you are referring to is part of recital/preamble and not the main body, so it is not exactly normative anymore... so I think this issue can be closed?

also, responses are non-repudiable in nature, as long as presented credential is signed using asymmetric digital signature (HMACing presented credentials is what could give repudiation)