As an exercise, I tried to draw the flows described in RFC007 in more detail to see how it works and how to link all the steps together. For that purpose, I explicitly separated AS, Issuer, Verifier and Backend (BE). In your drawings, these are combined into PSP. The white parts adhere to the protocols/specs. The colored parts denote steps, that are not defined in the specs. These are mostly what I came up with to connect the dots and be able to (hopefully securely) link the user selection to Payment Attestations.
This brought up some questions:
- How to tell the wallet to use a certain key for proofing? You keep saying
Optionally, the key may also be required to be the same as one discovered during the presentation (if performed) so that the presentation can be used for wallet holder authentication.
But how exactly can we enforce this?
- In your PSP-Init flow, you say that tx_code is optional but isn't it mandatory due to pre-authoritazion-code-flow? OPENID4VCI says
If the Wallet decides to use the Pre-Authorized Code Flow, the Transaction Code value MUST be sent in the tx_code parameter with the respective Token Request as defined in Section 6.1.
Also, when in the flow is it sent to the user and how is it linked to the initiating request?
-
The Wallet can receive multiple credential_identifiers in the token response, but it cannot send them all in a single credential request. Why not? What's the reason for this decision?
-
As your flows are shown in rather high level, I'd like to know your approach to connect the dots and be able to map the user selection made at the beginning to the attestations issued at the end? It is not covered in the RFC?
-
How is the wallet authenticated (WUA) during the presentation?
As an exercise, I tried to draw the flows described in RFC007 in more detail to see how it works and how to link all the steps together. For that purpose, I explicitly separated AS, Issuer, Verifier and Backend (BE). In your drawings, these are combined into PSP. The white parts adhere to the protocols/specs. The colored parts denote steps, that are not defined in the specs. These are mostly what I came up with to connect the dots and be able to (hopefully securely) link the user selection to Payment Attestations.
This brought up some questions:
But how exactly can we enforce this?
Also, when in the flow is it sent to the user and how is it linked to the initiating request?
The Wallet can receive multiple credential_identifiers in the token response, but it cannot send them all in a single credential request. Why not? What's the reason for this decision?
As your flows are shown in rather high level, I'd like to know your approach to connect the dots and be able to map the user selection made at the beginning to the attestations issued at the end? It is not covered in the RFC?
How is the wallet authenticated (WUA) during the presentation?