[Openid-specs-ab] Issue #1248: Should _claim_sources member format (currently only JWT) be expanded? (openid/connect)

Nat issues-reply at bitbucket.org
Wed Jun 16 06:43:07 UTC 2021


New issue 1248: Should _claim_sources member format (currently only JWT) be expanded?
https://bitbucket.org/openid/connect/issues/1248/should-_claim_sources-member-format

Nat Sakimura:

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.

‌




More information about the Openid-specs-ab mailing list