Should _claim_sources member format (currently only JWT) be expanded?

Line 579 goes like:

1. If the claim set was obtained as W3c Verifiable Credential, then it MUST be stored in the corresponding "verifiable_presentations" member of the aggregated claims.

This was just thrown in to stir conversations on this.

Aggregated Claims is a generic container format that allows the delivery of a bunch of pieces of evidence for something like customer due diligence to be packaged and signed at once, delivered, and stored. From the point of view of the business that performs customer due diligence, it is not an option for it to dictate the acceptable format. They likely have to accept what is available in the market. It is not going to be all-JWT. mDL for instance is CWT if I remember correctly. OIDC Core 1.0 anticipates it by putting a format name as the member of _claim_sources member instead of having something like value but also states that when claim_sources is presented as an Aggregated Claims, the value of the _claim_sources is a “JSON object that MUST contain the JWT member “. This leads to the following Problem Statement.

(PS1) The current OIDC Core 1.0 text mandate the _claim_sources member to have a member "JWT" regardless of what the source format is. If the source format was anything but natively JWT, it would probably have to be wrapped in JWT and duplicate the claims in the enclosed format and cause bloat as the current OOIDC Core 1.0 text says “JWT [JWT] that MUST contain all the Claims in the _claim_names object that references”. If it is possible to just provide metadata and linking information of the enclosed format and the OP subject, it would be a lot of improvement. In addition, it can potentially have another encoding one (e.g., the verifiable_presentation member here), but the above duplication issue persists. The error case of where JWT member value and enclosed/referenced format also is a headache. (This problem is alleviated if we use Distributed Claims but then the CP will know who is the RP without CP and RP being colluding, besides, how the access_token member is being issued is undefined.)

In addition, the current text in aggregated and distributed claims (5.6.2 of OIDC Core 1.0) around sub says:

The JWT SHOULD NOT contain a sub (subject) Claim unless its value is an identifier for the End-User at the Claims Provider (and not for the OpenID Provider or another party); this typically means that a sub Claim SHOULD NOT be provided.

This leads to the next problem statement.

(PS2) Not providing sub in the JWT or other "evidence data set" does not make sense as that should be some kind of "assertion" around the subject. At least, some kind of strong correlation handle is needed between the issued evidence’s subject and the subject of the ID Token of the OP.

‌

Comments (8)