clarify batch endpoint encryption

[c2bo]

closes the batch endpoint part of #286

[babisRoutis]

Changes are clear, IMO.

Would it make sense to include in the non-normative example of the batch request the top-level credential_response_encryption attribute?

For instance, something like:

POST /batch_credential HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW
{
   "credential_requests":[
      {
         "format":"jwt_vc_json",
         "credential_definition": {
           "type":[
             "VerifiableCredential",
             "UniversityDegreeCredential"
           ]
         },
         "proof":{
            "proof_type":"jwt",
            "jwt":"eyJ0eXAiOiJvcGVuaWQ0dmNpL...Lb9zioZoipdP-jvh1WlA"
         }
      },
      {
         "format":"mso_mdoc",
         "doctype":"org.iso.18013.5.1.mDL",
         "proof":{
            "proof_type":"jwt",
            "jwt":"eyJraWQiOiJkaWQ6ZXhhbXBsZ...KPxgihac0aW9EkL1nOzM"
         }
      }
   ],
   "credential_response_encryption": {
    "jwk": {
      "kty": "RSA",
      "e": "AQAB",
      "use": "enc",
      "kid": "5981f333-23e0-4b4a-9bd6-853ca70344f6",
      "iat": 1715685980,
      "n": "tbXb9U8Q_4cpsPcLp7fDPoTQlGOERZBwPUkQBlimrubl6cTsg4hF2Hrwi_K_Qe8RPGGTPTg_l1stBxGcE3JHSx0W2bkhbhNsAYBwHx2V07scrbjecHN_w2hrS8UMGwAuoZlBDvAbYRd16ifHKfby0hfuIKRXni_pUGte-ZkpbAcIAqug75MvYxRVw_xWPHQSCWpMXhPgV6YMZ4L3K_z1PT_zMclwvVd6dzJjALOG3z-JJpYCNwgL8LOWkaHB9mQwexLIfovpprYWRYe5dqXnOApH71C7-3AsFgZxRExjsIM5Qnbyimqyhhq84cUZ_wB0fgi3iQF-c3rHqzT2kXE8ww"
    },
    "alg": "RSA-OAEP-256",
    "enc": "A128CBC-HS256"
  }
}

[c2bo]

We do not have any example for a request with encryption in the spec yet -> I like the idea of expanding this example. Any objections?

[tlodderstedt]

I would rather suggest to have another example (pair) for request for encrypted response and encrypted response.

[c2bo]

I would rather suggest to have another example (pair) for request for encrypted response and encrypted response.

Should we then leave this PR as is and create another PR with examples for encrypted request / response? There is some discussion in #324 as well, so I think that makes things easier.

[Sakurann]

Suggested change

	* `credential_response_encryption`: OPTIONAL. Object containing information for encrypting the Batch Credential Response. It contains the same parameters as defined in #{credential-request}. If this request element is not present, the corresponding Batch Credential Response returned is not encrypted.
	* `credential_response_encryption`: OPTIONAL. Object containing information for encrypting the Batch Credential Response. It contains the same parameters as defined in #{credential-request}. If this request element is not present, the corresponding Batch Credential Response is returned not encrypted.

[c2bo]

This is the same formulation as in Credential Request - should we change both then?

* `credential_response_encryption`: OPTIONAL. Object containing information for encrypting the Credential Response. If this request element is not present, the corresponding credential response returned is not encrypted.
    * `jwk`: REQUIRED. Object containing a single public key as a JWK used for encrypting the Credential Response.
    * `alg`: REQUIRED. JWE [@!RFC7516] `alg` algorithm [@!RFC7518] for encrypting Credential Responses.
    * `enc`: REQUIRED. JWE [@!RFC7516] `enc` algorithm [@!RFC7518] for encrypting Credential Responses.

[Sakurann]

why is it the Client SHOULD reject the Credential Response. and not a MUST?

[c2bo]

I tried to keep it consistent with the Credential Response which currently says the same

[Sakurann]

I would rather suggest to have another example (pair) for request for encrypted response and encrypted response.

Should we then leave this PR as is and create another PR with examples for encrypted request / response? There is some discussion in #324 as well, so I think that makes things easier.

sounds like a plan.