[Openid-specs-ab] Issue #1466: Structure and location of OP metadata to support credential issuance (openid/connect)
Tobias Looker
issues-reply at bitbucket.org
Fri Mar 25 21:05:16 UTC 2022
New issue 1466: Structure and location of OP metadata to support credential issuance
https://bitbucket.org/openid/connect/issues/1466/structure-and-location-of-op-metadata-to
Tobias Looker:
Currently the spec makes use of credential manifest as the primary source of syntax for a provider to advertise what credentials it supports the issuance of. I propose that we opt to define our own simpler syntax that is more in keeping with how existing OpenID metadata is defined. Below is an annotated sample of my proposal
```
{
"credentials_supported": [ // An array of objects
{
"name": "University Credential",
"type": "university_degree", // Normatively defined as a string so CAN be something stricter like a URI/URL
"formats": {
"w3c_vc" : { // The structure of the object to be somewhat dictated by the format identifer
"binding_methods_supported": [ "did" ],
"proof_types_supported": [ "Ed25519Signature2018" ]
}
},
"claims": { // Optional This abstraction could be difficult to maintain, need to validate it more
"given_name": {
"display": "Given Name",
"description": "The given name of the subject of the degree",
"path": "$.values.given_name", // Potential path expression
"mandatory": true // Assume default is false if omitted
},
"last_name": {
"mandatory": true
},
"degree": {
"mandatory": true
},
"gpa": {
"mandatory": false
}
}
}
],
"credential_endpoint": "https://server.example.com/credential", // Endpoint for obtaining the issued credential
"pop_supported": [ "did" ]
}
```
More information about the Openid-specs-ab
mailing list