[Openid-specs-ab] Issue #1585: Anatomy of a credential request (openid/connect)

Tobias Looker issues-reply at bitbucket.org
Fri Aug 5 15:25:41 UTC 2022


New issue 1585: Anatomy of a credential request
https://bitbucket.org/openid/connect/issues/1585/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>"
        }
    }
}
```

‌




More information about the Openid-specs-ab mailing list