[DO NOT MERGE] Add proof chain and set documentation to credential issuance

[bparth24]

This PR addresses #422 by clarifying how the /credentials/issue endpoint handles credentials with existing proofs as agreed upon in the 2025-05-27 call.

📋 Changes Made

• Enhanced Issue Credential section to document three configuration-based behaviors:

  • Proof Sets: Append proofs in parallel for cryptographic flexibility
  • Proof Chains: Link proofs sequentially for approval workflows
  • Error Handling: Reject credentials with existing proofs when configured

• Clarified instance configuration determines proof processing behavior

🔧 Files Changed

• index.html - Updated "Issue Credential" section documentation

🤔 Reviewer Input Requested

• Should I also perform schema updates?

Potential changes:

1. Update components/Credential.yml file - enhance UnsecuredCredential proof property description to An optional proof or array of proofs for credentials that are secured using proof sets or chains. When present, the issuer instance configuration determines how these existing proofs are processed (appended to create proof sets/chains, or trigger an error).
2. Update components/IssueCredentialOptions.yml - add optional proofId and previousProof properties
3. Update root level issuer.yml file - enhance endpoint description for proof handling

@msporny @dlongley

Please review this documentation approach first and guide me if the schema enhancements are needed to resolve issue #422.

---

Preview | Diff

[bparth24]

@dlongley thanks for the input. It makes sense to me.

[BigBlueHat]

Group discussed on 7/22 and agreed to merge this pending an addition from @bparth24 and/or confirmation of no additional schema changes being needed.

[bparth24]

@dlongley cc: @msporny @BigBlueHat

PR #499 created to address this comment and for potential changes: - #495 (comment)

[TallTed]

Minor, as elsewhere.

[msporny]

@bparth24 Thank you for the PR!

Please try to rebase this PR to do the following:

• Bundle editorial change suggestions from the same person into a single commit when possible. For example, all of @TallTed's editorial changes should've been bundled together to make the commit history more clean.
• Avoid using non-descriptive commit messages such as "Update index.html", commit messages such as "Fix grammar and syntax in proof chain/set section." are better

We should also give you rights to this repo so you don't have to fork -- when that happens, I can't fix up issues like the above, which just slows down the merge process.

[bparth24]

@bparth24 Thank you for the PR!

Please try to rebase this PR to do the following:

• Bundle editorial change suggestions from the same person into a single commit when possible. For example, all of @TallTed's editorial changes should've been bundled together to make the commit history more clean.
• Avoid using non-descriptive commit messages such as "Update index.html", commit messages such as "Fix grammar and syntax in proof chain/set section." are better

We should also give you rights to this repo so you don't have to fork -- when that happens, I can't fix up issues like the above, which just slows down the merge process.

@msporny

Noted all the comments. I will rebase this PR. I will certainly keep all comments in mind for future PRs. Thank you for the direction. Yes, I got access rights to the W3C-CCG repo.

[bparth24]

@msporny

I rebased it.

[bparth24]

PR #503 is the new PR addresses and maintains contribution from all reviewers with a single commit history replaces PR #495 and PR #495 should not be merged.

@msporny @dlongley @TallTed

[msporny]

Overtaken by PR #503, closing.