CS-01: Re-issuance and deferred issuance

[stefan-kauhaus]

One clarification and one proposal regarding CS-01:

1. Re-issuance: Can we please confirm that support for re-issuance is optional for issuers under CS-01? I find the current wording a bit ambiguous:
   • not mentioned as mandatory in section 5
   • not mentioned under Normative Requirements / Common in section 7.1
   • "Issuers MUST: ... Issue sender-constrained refresh tokens (DPoP-bound) where re-issuance is supported", section 7.8
   • but then section 9 Conformance has it like this: "An implementation conforms to this specification as an Issuer if it: (...) Implements the Issuer re-issuance requirements in sections 6.4 and 7.8, including the Refresh Token grant at the Token Endpoint (section 8.4)."

--> I propose to clarify in section 9 that the requirements from the referenced sections are to be implemented in case an issuer decides to support re-issuance.

2. Deferred issuance

• Current wording in section 7.6 is "Issuers MUST:... Support a deferred_credential_endpoint."

--> I propose to move this from mandatory to optional for issuers to support. Rationale: In many Use Cases, the capability is not needed (specifically now that we have the pre-auth code flow where the credential can be issued right away). It is also optional in OID4VCI. Relaxing this will reduce complexity for implementers in WE BUILD.

CC @lalc @georgepadayatti @endimion

[endimion]

Hey all, since I was assigned this I will answer but really this comes from discussing with @georgepadayatti I just think he forgot to paste that here...
Basically George agrees as do I with both points..

1. re-issuance was meant to be optional
2. deffered can be turned into a MAY

We can have additional test cases for these optional features inside ITB+

@georgepadayatti and @lalc happy with this I assume? @lalc will you raise a pull request for this?