Allow the service to issue Verifiable Credentials

[schanzen]

We could add the option to issue verifiable credentials as defined in https://www.w3.org/TR/vc-data-model/#json-web-token in particular in the client_credentials flow using public key authentication (JWT bearer auth).
This would mean that we issue a verifiable credential in the vc claim of the JWT.
The VC could then be used by a client to create a new self-signed JWT which in turn includes a verifiable presentation claim (vp). The VC/VP attributes could be issued using Privacy-ABCs such as https://github.com/Fraunhofer-AISEC/libpabc.

[schanzen]

BBS+ signatures (for Privacy-ABCs) are not yet standardized: https://github.com/decentralized-identity/bbs-signature
Initial implementations should probably use more standard signature schemes first.

[bellebaum]

There is ongoing development on this topic in the Verifiable Credentials Branch.

Currently this branch only supports proofs through signing the JWT-encoded VC as well as an initial implementation of the Ed25519Signature2018 LD-Proof signing algorithm, which should be checked against other implementations in the near future.

As for BBS+, there is ongoing work to propose new standards both for a new type of JWTs (called JSON Web Proofs), which aim to support selective disclosure, as well as an LD-Proof signature suite. We should probably focus on the latter, as that one has at least some implementations in other languages, see e.g. https://github.com/transmute-industries/verifiable-data/ (Although there are some inconsistencies, like the required requiredRevealStatements claim, which was not implemented as far as I can tell).

Unfortunately, as noted in this issue, relying on implementations is something we will have to do, as the LD-Proof Specs are at times vague or even contradictory.

I was unable to find a Ruby implementation of BBS+ Signatures, but we could interface with libpabc. This would probably be useful by itself, so I would recommend creating a gem in a dedicated repository.

@schanzen As for delivering the token: I assume by "the JWT" you refer to either the access or ID token. We should make sure that these are not confused with JWT-encoded Verifiable Credentials having a similar vc claim. One may like to have access tokens be the same thing, but this would require a few (mostly minor) changes to the to the token, like changing the typ header claim from at+jwt (recommended by RFC 9068) to JWT (mandated by vc-data-model). One change that would be relevant to us is the following:

• Per vc-data-model, the JWT sub claim MUST be equivalent to the VC subject's id claim (or represent it) and the latter MUST be a URI. However in the general case, and in the usecase of a DAPS especially, the sub claim is the client's ID, which is not necessarily a URI.

I would suggest following an approach close to OIDC4VP, which only deals with verifiable presentations issued by the OP (a topic we may want to explore in the future), but offers two possible delivery methods:

• Delivery within an ID token with a dedicated vp claim (we would use vc), where OIDC4VC already mentions the potential source of confusion
• An additional token, called vp_token (we would use vc_token), representing the VP (VC)

Either could then be requested using the claims request parameter. We could of course also include the VC in the access token as well, but I think having credentials belong to the ID token makes more sense.

[schanzen]

Interesting information. Please note that omejdn will never be an SSI OP (OP = OpenID Provider). SSI OPs are usually implemented as client side software. They act as an OP for example through the SIOP profile. A relying party may ask the subject to provide identity information of a SSI and a client-side OP can implement an OIDC AuthZ flow. The SIOP will then issue presentations in the JWTs (at least that is my assumption). But those presentations must be generated from (verifiable) credentials.
Now, it is a bit unclear atm to me how those VCs get into the client software of the subject. But my assumption is that it should be possible to retrieve VCs from "traditional", server-based OPs. And this functionality is what the issue is trying to address, not the SIOP functionality which provides RPs with the presentations.

[schanzen]

To follow up on this and make it a bit clearer: The feature could be implemented in omejdn by having an API endpoint, say /vc, which can be accessed by a client (the SSI "wallet" or client software) after authorization / with an access token. This enpoint then returns a VC in any format as the format das not matter.
Then, the SSI wallet / client software can use the VC for its own presentation generation.

However, the above would be non-standard functionality. I was in particular wondering, if there is a standards effort on how to do this.

[bellebaum]

There seems to be for OIDC: https://mattrglobal.github.io/oidc-client-bound-assertions-spec/

It defines a generic "Credential Endpoint" discoverable via OIDC Discovery. Were we to implement this, we should probably stick to copying their example endpoints, which would mean choosing /credential.

I would argue that the format might matter, since not all credential holders (CH) will have support for both JSON-LD with every single LD-Proof Suite as well as JWTs (with the latter probably not being the problem here). After all, the CH has to be able to derive a verifiable presentation. Subsequently, it would be helpful if CHs could specify their desired format.
The above draft has at least support for specifying whether the VC should be returned in JSON-LD or JWT format, but choosing a proof suite seems out of scope there.

Another approach is given in https://identity.foundation/credential-manifest/ .
It provides support for choosing formats, but does not specify a detailed issuance protocol.

Unfortunately, the two specs seem to be incompatible with each other. There is an open issue here.

[bellebaum]

For now I will focus on the former, as that one is easier to get running. We may choose other specs in the future

[schanzen]

The mattr spec looks exactly like what I had in mind!

[bellebaum]

It seems the above mentioned Mattr spec has been abandoned in favour of https://openid.net/specs/openid-connect-claims-aggregation-1_0.html

[bellebaum]

Quick update on APIs to issue VCs:

• The Claims Aggregation draft seems to be pretty much abandoned.
• A new draft OIDC4CI (= OpenID Connect for Credential Issuance) is being worked on at the OIDF connect WG.
  • Suitable to issue VCs to end-users, but not to clients.
  • Potentially requires the implementation of several other protocols, such as OIDC4VP and parts of the SIOPv2 draft (at a minimum, support to interact with SIOPs)
  • Very early development stage
• We could use something like OAuth 2.0 Token Exchange
  • TL;DR: Mechanism to use the token endpoint to exchange one "Security Token" (Intentionally not restricted to narrower definitions, but access tokens are mentioned as examples, in general identity or credential tokens) for another.
  • We could use this to allow any client to exchange Access Tokens for VCs.
    • VCs are currently not standardized as security tokens
    • Token Exchange currently lacks standardized support to specify a "type" of credential, should we support types (=sets of claims, think e.g. "drivers license")

[schanzen]

Quick update on APIs to issue VCs:

• The Claims Aggregation draft seems to be pretty much abandoned.

• A new draft OIDC4CI (= OpenID Connect for Credential Issuance) is being worked on at the OIDF connect WG.

  • Suitable to issue VCs to end-users, but not to clients.
  • Potentially requires the implementation of several other protocols, such as OIDC4VP and parts of the SIOPv2 draft (at a minimum, support to interact with SIOPs)
  • Very early development stage

• We could use something like OAuth 2.0 Token Exchange

  • TL;DR: Mechanism to use the token endpoint to exchange one "Security Token" (Intentionally not restricted to narrower definitions, but access tokens are mentioned as examples, in general identity or credential tokens) for another.

  • We could use this to allow any client to exchange Access Tokens for VCs.

    • VCs are currently not standardized as security tokens
    • Token Exchange currently lacks standardized support to specify a "type" of credential, should we support types (=sets of claims, think e.g. "drivers license")

I think in both cases we would have to violate or extend the specifications. So the question becomes what is cleaner and what do want. In general, I think the OIDC4CI would be nicer to have in order to support SSI wallets.