Correcting previously mis-corrected sentence

[TallTed]

Important questions, where the answers may lead me to change this PR:

• Are the security domain and/or receiver-supplied challenge both optional?
• Can either be present without the other, or does including one mandate the other?
• Are these the only optional proof options (i.e., while all the others are MUST, these are MAY)?

---

Preview | Diff

[msporny]

@TallTed, I've made an attempt at answering your questions below:

• Are the security domain and/or receiver-supplied challenge both optional?

Yes.

• Can either be present without the other, or does including one mandate the other?

Either can be present without the other.

• Are these the only optional proof options (i.e., while all the others are MUST, these are MAY)?

I'm going to answer your question in a round-about way.

On a conforming proof object, the following properties are required: type, proofPurpose, verificationMethod, proofValue

On a conforming proof object, the following properties are optional: id, created, expires, domain, challenge, previousProof, nonce

Implementations are expected to provide mechanisms for setting all of the fields above, which might include "convenience options" that set multiple values at the same time, or use implementer-defined defaults for both required and optional values. We are trying to stay out of the implementers way so they can create the interfaces that they want to create while ensuring that the algorithms clearly articulate where each option is used in the algorithms (which can be implemented in any way that an implementer would like, as long as the output of the final algorithm matches what is specified).

I hope that gives you enough to go on for revising this PR. If you're done, let me know, as it's ready for merge if you are done.

[TallTed]

@msporny Hmmm. The re-corrected sentences are good now. We do not seem to list the same required and optional properties for a conforming proof object, in the way you have here. Perhaps we should, maybe as bullet lists before or after the algorithm (as now written), and rephrase your large paragraph into something meant for implementers?

[msporny]

@TallTed wrote:

Perhaps we should, maybe as bullet lists before or after the algorithm (as now written), and rephrase your large paragraph into something meant for implementers?

Yeah, we might want to do that... it would be easier to read here... we might want to do that for all the other sections as well.

I'm going to merge this in now, and then look at applying your suggestions more generally throughout the rest of the algorithms in the spec.

[msporny]

Normative, multiple positive reviews, no objections, merging.