How are credential copies issued?

[danielfett]

Originally posted by @danielfett in #65 (comment)

The relationship currently described is that in any issuance process, multiple "types" of credentials can be issued (*), and for each "type" there can be multiple instances. An instance is described as "contains different claim values or different subset of claims within the claimset identified by the Credential type"

(issuance process) --- 1:n --- (credential definition*) --- 1:m --- (credential instance)

How is the relationship to batch issuance for unlinkability as suggested in SD-JWT? Is this already covered or should there be a separate mechanism for that? I.e., to have something like this for k copies of the same credential:

(issuance process) --- 1:n --- (credential definition*) --- 1:m --- (credential instance) --- 1:k --- (credential instance copy)

---

(*) entry in the credentials_supported Credential Issuer metadata - I added a comment suggesting to find a good term for this to use instead of credential type.

[danielfett]

Note: The individual credential instance copies would also need different keys.

[danielfett]

I only now noticed that an issue for this exists already: #91

[paulbastian]

My opinions on the matter in the sibling-thread: #91 (comment)

[paulbastian]

---------DEPRECATED EXAMPLE------------

Token Response

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

  {
    "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ",
    "token_type": "bearer",
    "expires_in": 86400,
    "c_nonce": "tZignsnFbp",
    "c_nonce_expires_in": 86400,
    "credential_identifiers": [ "CivilEngineeringDegree-2023", "ElectricalEngineeringDegree-2023" ]
  }

---------DEPRECATED EXAMPLE------------
Credential Request

POST /credential HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

{
  "CivilEngineeringDegree-2023": {
    "proof": [
      {
        "proof_type": "jwt",
        "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOjE1MzY5NTk5NTksIm5vbmNlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
      },
      {
        "proof_type": "jwt",
        "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOjE1MzY5NTk5NTksIm5vbmNlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
      }
    ]
  },
  "ElectricalEngineeringDegree-2023": {
    "proof": [
      {
        "proof_type": "jwt",
        "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOjE1MzY5NTk5NTksIm5vbmNlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
      }
    ]
  }
}

---------DEPRECATED EXAMPLE------------
Credential Response

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "credentials": {
    "CivilEngineeringDegree-2023": {
      "credential": [
        "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L",
        "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L"
      ]
    },
    "ElectricalEngineeringDegree-2023": {
      "credential": [
        "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L"
      ]
    }
  }
}

[Sakurann]

a quick note that a proposal that introduces any changes to the token response (like a new top level claim credential_identifier) would not work for implementations like Microsoft's that re-use existing AS and cannot make breaking changes to that AS. In general, this would limit what ASs can implement VCI which I hope we can avoid.

[Sakurann]

To the question... As discussed during DCP WG call, one information that needs to be communicated between the issuer and the wallet is how many copies of credentials need to be issued.

I am not sure the issuer cares which endpoint the wallet uses for batch issuance, when the issuer supports both credential and batch credential endpoint. and i am not sure issuer can force the wallet to use either of the endpoints for batch issuance because there is no guarantee the wallet supports both endpoints. so in reality the issuers that want to do batch issuance will have to support batch issuance on both endpoints. as longs as we keep both endpoints of course. it might be simpler to have one credential endpoint and a flag whether the issuer supports batch issuance at that endpoint or not - i don't know yet.

I would imagine it is the issuer who dictates the number of copies, but I have also seen an implementation in ISO mDL world where the user can choose how many copies (not sure if this is a hard requirements though)

[jogu]

I would imagine it is the issuer who dictates the number of copies, but I have also seen an implementation in ISO mDL world where the user can choose how many copies (not sure if this is a hard requirements though)

I imagine it might be a bit of negotiation. Probably the issuer somehow tells the wallet the maximum number of copies it's willing to issue, and the wallet decides how many to actually request (by supplying the requisite number of holder proofs?). Certainly the issuer shouldn't fully dictate the number of copies as the wallet may hit limits on the number of distinct private keys it can create in the secure enclave, etc.

I firmly believe that (at least for the "average person on the street") the complexities of having multiple copies of credentials should be hidden from the user as much as possible, so if the user has any input at all on the number of copies it should be hidden deep in an "advanced settings" screen that normal users can ignore.

[paulbastian]

most recent ideas for Credential Request

POST /credential HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

{
  "credential_encryption_jwk": "...",
  "credential_response_encryption_alg": "...",
  "credential_response_encryption_enc": "...",
  "credential_requests": [
    //uses credential_identifier returned from the Token Endpoint. issues 2 copies of a credential
    {
      "credential_identifier" : "CivilEngineeringDegree-2023",
      "proofs": [
        {
          "proof_type": "jwt",
          "jwt": "..."
        },
        {
          "proof_type": "jwt",
          "jwt": "..."
        }
      ]
    },
    //issues one copy of a credential
    {
      "format" : "mdoc_mso",
      "proofs": [
        {
          "proof_type": "cwt",
          "jwt": "..."
        }
      ]
    },
    //issues 2 copies of the same credential
    {
      "format" : "sd-jwt+vc",
      "proofs": [
        {
          "proof_type": "jwt",
          "jwt": "..."
        },
        {
          "proof_type": "jwt",
          "jwt": ""
        }
      ]
    }
  ]
}

[paulbastian]

most recent ideas for Credential Response

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "credential_responses": [
    //issuer was able to successfully issue both copies of the credential
    {
      "credentials": [
        "eyJraWQiOiJkaWQ6ZXhhbXBsZTpl...C_aZKPxgihac0aW9EkL1nOzM",
        "eyJraWQiOiJkaWQ6ZXhhbXBsZTpl...C_aZKPxgihac0aW9EkL1nOzM"
      ]
    },
   //issuer wants to defer issuance of this credential
    {
      "transaction_id": "8xLOxBtZp8"
    },
    //issuer was not able to successfully issue both copies of the credential

    {
      "error": "unsupported_credential_format",
      "error_description": "..."
    }
  ],
  "c_nonce": "fGFF7UkhLa",
  "c_nonce_expires_in": 86400
}

note: i removed the REQUIRED format from credential response, I think its unnecessary. Also single credentials are still returned as an error

[tlodderstedt]

most recent ideas for Credential Request

multiple proofs ask for multiple instances of the same credential?

[tlodderstedt]

a quick note that a proposal that introduces any changes to the token response (like a new top level claim credential_identifier) would not work for implementations like Microsoft's that re-use existing AS and cannot make breaking changes to that AS. In general, this would limit what ASs can implement VCI which I hope we can avoid.

I think this is why we came up with the idea back in MV to only issue credential identifiers with authorization details, right?