RFC 0511 - challenge/domain should be not required (or optional)

[awoie]

The current spec says that in offer-credential challenge and domain are REQUIRED.

There might be two issues:

• It contradicts with the request-credential message where the spec says that challenge and domain might be obtained OOB. If OOB transmission is allowed, then we should probably not require these two fields in the request-credential message.
• The DIF Credential Manifest specification can include a presentation_definition which is defined here. Further, the Presentation Definition MAY include (or MAY be the same as--still unclear to me) a Presentation Request which allows to include challenge / domain parameters. So, instead of passing challenge / domain in the offer-credential as individual parameters, we could use the Presentation Request to pass challenge / domain to the Holder for the Presentation Submission.

But I might be missing something @llorllale ?

[llorllale]

@awoie

It contradicts with the request-credential message where the spec says that challenge and domain might be obtained OOB. If OOB transmission is allowed, then we should probably not require these two fields in the request-credential message.

I agree. Another reason is the fact that a CM may not have a presentation_definition.

The DIF Credential Manifest specification can include a presentation_definition which is defined here. Further, the Presentation Definition MAY include (or MAY be the same as--still unclear to me) a Presentation Request which allows to include challenge / domain parameters. So, instead of passing challenge / domain in the offer-credential as individual parameters, we could use the Presentation Request to pass challenge / domain to the Holder for the Presentation Submission.

As I answered in https://github.com/decentralized-identity/presentation-exchange/issues/112#issuecomment-698348423, a presentation definition is not the same as a presentation request. This means if you are using issue-credential v2 with RFC0511 alone then both domain and challenge need to be send in offer-credential.

I haven't fully explored the alternative of running present-proof as a co-protocol in order to deliver the proof to the issuer but it seems to have unnecessary overhead for this use case IMO. The issue-credential v2 state machine would launch present-proof v2 and go to sleep. The Holder would need to send a propose-presentation msg in the role of Prover, the Issuer would need to respond with a request-presentation in the role of Verifier, and the Holder would respond with presentation in the role of Prover. Then the issue-credential v2 state machine would then resume.