Add challenge management endpoint to verifying APIs

[dlongley]

Challenge management is a common and (fairly) simple feature that all users of the verification APIs will need in order to securely implement VP verification.

We should add a /challenges endpoint to verifier instances to allow callers to generate and manage challenges for use in authentication requests.

Posting an empty body to /challenges on a verifier instance (with appropriate authorization) should result in a 200 response (or 4xx / 5xx error) body with {challenge: <the challenge>}. This challenge can then be included in, for example, a VPR request.

When a VP is later submitted to the same verifier instance (and the challenge is passed in the request), the verifier can check the challenge and the number of times it has been seen / used previously (e.g., {"verified": true, "uses": 1} as challenge verification metadata), reporting this back to the caller. This allows the caller to check for challenge reuse / replay attacks and make a business-level decision.

If the challenge was not previously created with that verifier instance (or the challenge is otherwise determined to be invalid, e.g., expired), the verifier must return that the VP is not verified and include an appropriate error.

[dlongley]

A reason to report back uses and not just fail verification if the number of uses > 1, is that the caller may be able to determine that their verification request timed out -- but they do not know whether it may have been processed by the verifier. Upon retrying the request and seeing uses: 2 in the challenge verification metadata, the caller may decide to accept the risk of a replay attack occurring concurrently with their timed out request vs. requiring the end user to generate another authentication proof.

[msporny]

This issue was discussed on 2022-10-18. @dmitrizagidulin asked the group if anyone else is implementing challenges. @msporny outlined a typical flow between a Holder Coordinator, a Verifier Coordinator, and a Verifier Service that puts the challenges endpoint on the Verifier Service. @jandrieu mentioned that he was concerned that a challenges endpoint could be construed as business logic that should go on the Verifier Coordinator. @jandrieu noted that he thought the relationship was symmetric, is the Verifier checking the challenge? If they are, then they still have to communicate the challenge to them, or to an earlier request, whether we have to echo it back either directly or indirectly -- net-net it might be better for coordinator to manage it. @dmitrizagidulin didn't want to lose track of if we should have a challenge endpoint in the first place. @jandrieu noted that it depends on where you want to put it? @dmitrizagidulin asked if others would find it useful if we had an endpoint. @jandrieu pushed back noting that "usefulness" isn't a high enough bar -- we should look at this from who has the most/least security issues wrt. where challenges are exposed. Having another party in the loop feels like a security problem. @msporny noted that challenge management was a convenience on Verifier Service. @dmitrizagidulin noted that exchange endpoint lives on issuer island because exchange endpoint is issuing VCs. Before exchanging there are pre-requisiteds that need to be met.

The issue wasn't resolved on the call, we'll discuss this next meeting.

[msporny]

We discussed this on the 2022-10-25 call. @msporny reviewed what we had discussed in the previous week. @dlongley noted that a system might need to keep track of how often a challenge is used or if it has been re-used. Putting that in business logic will make it so that everyone might need to re-implement it vs. having a common mechanism to support that check (given that it might be used often). @jandrieu noted that is sounds like these are business rules, how the challenge is to be used or maintained. It's strange to verify to outsource relationship to Verifier Coordinator through the Verifier Service. @dlongley noted that "strange to outsource relationship to verifier service" did not resonate with him. When a holder provides a presentation, they outsource to a verifier service -- it gives them a tool to verify presentations. Part of verifying a presentation that has a proof on it is ... you can make a call to another system to another system to note your challenge state, and then it is a business decision based on how many times challenge has been re-used. Joe also mentioned having to manage state anyway -- don't need to manage state, Verifier Coordinator can outsource that entirely - clean abstraction boundary.

Coordinator doesn't have to maintain state. @jandrieu noted that there is agreement on this being business rules, if coordinator is driving this, unless coordinator is giving VCs to everyone that's showing up, they have to manage state between current session and whoever current session is with... Coordinator is managing state no matter what. @dlongley "managing state" is overly broad, there are services that will not manage state, and there will be ones that do, specifically, we are talking about challenge state, with what I mentioned before, they don't have to manage /that/ state. Managing that state might be a more challenging thing to do, keeping atomicity w/ those proofs. Whatever we can do to handle less state at the Coordinator is helpful. @jandrieu if verifier is going to check challenge, no reason that coordinator can't provide that information at the same point. You can have an atomic check, all of business validation rules are meant to be atomic, either you pass them or you don't. You could construct a spectrum, but no one has modeled that. @dmitrizagidulin noted that he cares a lot about this issue both w/ him and DB's implementation. Most every implementation will need a challenge management system such as this.

@msporny asked for other opinions on the matter. @jandrieu noted it's a useful function to define and implement, might not need to be a service usable by anyone. @dlongley and @dmitrizagidulin noted that because of the atomicity issues, it belongs on the Verifier Service. @jandrieu noted that having a PR might help move things forward.

Next steps are to raise a PR to place the endpoint (/challenges) on the Verifier Service to create a challenge for when an interactive challenge is needed (CHAPI, VC-API)... Verifier Service checks state of challenge (keeping track of the number of times a particular challenge is used -- using multiple times might be ok due to network drop-outs/failures and the subsequent retries w/ the same challenge), understanding that there is no strong consensus on placing it there. The PR is just being raised so we can have a more detailed conversation about the topic.