- changed status to open
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 theaccess_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)
-
reporter -
I already need to support X.509 and expect to get other formats as well. Seems like it needs to be part of SIOP. If that cannot be done w/o damage to OIDC, then the link between siop and oidc should be broken.
-
reporter In the previous call, it was hinted that there is an initiative around representing a bunch of formats like ZKP in JWT. I am interested in learning them.
-
Referencing here the work planned in issue #1254 for ZKPs in a JOSE based package.
-
Does this assume that if VCs are being requested by the intermediary provider in JSON-LD format from one source, it would have to use aggregated claims syntax ie
_claims_sources
? -
reporter @Tom Jones What format of X.509 is needed? I guess encoding it to JWT is too much overhead …
-
ISO 18013-5 (etc.) embodied the x.509 as a bitstring in a cose structure.
-
It’s CBOR, not JSON and is based on “RFC: CBOR Object Signing and Encryption (COSE): Headers for carrying and referencing X.509 certificates” the latest version is this one, I think draft-ietf-cose-x509-03
- Log in to comment
The sentiment of the Call on 2021-06-22 is that:
Microsoft has a wrapping format for JWT for ZKP for uProve and Idemix etc., so Mike may be able to provide reference to it.