[has-PR] Anatomy of a credential request

[Tobias Looker]

Currently the structure of a credential request is as follows.

{
  "type": "https://did.example.org/healthCard"
  "format": "ldp_vc",
  "did": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "proof": {
    "proof_type": "jwt",
    "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8
    xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR
    0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm
    NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
  }
}

Where the proof contains several key pieces of information, namely

1. The public key or how to get it, to validate the proof (pop)
2. Optionally an attestation about the key used to generate the pop
3. What the credential binding method is, e.g direct to a public key or via a resolvable identifier like a DID

In order to better preserve extensibility of these different elements of the request which come in multiple possible representations and have different relationships to one and other, im proposing that we flatten the request structure to something along the lines of the following

{
    "type": "drivers_license",
    "format": "iso_mdl",
    "credential_binding": {
        "binding_method": "public_key",
        "public_key": { 
            "key_format": "jwk",
            "key": { ...JWK },
            "key_attestation_format": "x509chain",
            "key_attestation": ["...."],
            "key_pop_format": "jwt",
            "key_pop": "<JWT>"
        }
    }
}

‌

[Tom Jones]

I have had a major objection to credential requests ever since Daniel started to push for a PE. The primary goal of any request MUST (IMHO) be to communicate the purpose of the request to the holder. I was planning to create a purpose metaschema for another effort - perhaps we need to address that here as well?

BTW - why is there no @context in a request?

‌

[Torsten Lodderstedt]

I support the proposed change.

[Giuseppe De Marco]

+1

[Kristina Yasuda]

In Connect call, agreed with the direction of decoupling pop from attestation, and let’s flesh out details in the issue before doing a PR ;)

[Kristina Yasuda]

Personally, I think details matter. In particular would like clarity in below points:

in the PR, would be great if we can define basic params and say explicitly profiles are free to define their own parameters.

Also would like to discuss why “key“ has to be separate parameter while “key_pop“ JWT can include “key“ in `kid and body.

Also I think it is important to decide on which parameters are required and which ones are optional.

[Kristina Yasuda]

clarify that protocol supports issuance of bearer credentials - `credential_binding` itself should be optional

[Kristina Yasuda]

I still think “key“ to which credential is bound should be included in the header (kid/jwk parameters) of a pop instead of being sent separately. separating “key“ as a separate parameter does make it cleaner when the binding is to a raw key or an identifier like DID, but it increases the amount of verification and there is a risk of DID in “key“ not matching DID in “kid“ for example.

[Jeremie Miller]

I’m not sure about the rest of it, but I definitely support renaming this to “credential binding” and not re-using or locking it into “proof” alone.

[Kristina Yasuda]

will do a PR with a following direction based on a Aug-22 Connect call

{
  "type": "https://did.example.org/healthCard"
  "format": "ldp_vc",
  "credential_binding": {
    "credential_binding_type": "jwt",
    "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8
    xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR
    0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm
    NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
  },
  "attestation": {
    "attestation_type": "SafetyNet",
    "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8
    xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR
    0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm
    NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
  }
}

‌

[Kristina Yasuda]

PR #293

[Tobias Looker]

Closing because proposal is no longer relevant.