[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