Separating Claims Aggregation and Credential Provider drafts

[Kristina Yasuda]

Claims Aggregation draft and Credential Provider draft deal with the flows that are different enough that they should be separate specifications:

• Dynamic vs “Chopped” flow. Claims Aggregation flow is a dynamic, real-time flow like the rest of OpenID Connect. The entire flow between RP->IP->IA->IP->RP (IP = Intermediary OP; IA = Issuing Authority, or Authoritative Claims Provider) happens real-time, usually non-stop. When it comes to Verifiable Credentials, it is more of a “chopped“ flow, where the IP->IA->IP flow of issuing VC to the IP is separated in time from the RP->IP->RP flow of presenting VP when RP requests for it. RP can ask for a VP right after VC is issued to IP, or weeks after.
• Necessity to do status check / validation. In Claims Aggregation flow, RP does not need to do a check status of a credential, because it is issued real time, it is valid. In “Chopped” flow with the VC/VP, RP needs to do a validation check, because IA might have issued VC to IP weeks ago and have revoked it since than.
• Mechanism of Credential Binding. In Claims Aggregation flow, using the same nonce throughout RP->IP->IA->IP->RP flow can serve as a mechanism to bind credential to the IP (although now I think uid is the proposed mechanism). IA would use the same nonce to bind issued credential to the IP. In “Chopped” flow, since nonce cannot be re-used across two separate flows, cryptographic binding is used for proof of 'holdership' by the IP. IP would sign VC with its key and send as a VP.

Being dynamic is the beauty of Claims Aggregation draft and it should not be mixed with the “Chopped” flow. Credential Provider that has been contributed to the WG should be adopted as a separate draft that addresses the issuance part (IP->IA->IP) of the “Chopped“ flow. OIDC4VP already addresses presentation part (RP->IP->RP) of the “Chopped“ flow.

The issue is based on the conversations at Identiverse 2021 following the panel on SIOP. For clarity, attaching the Claims Aggregation flow slide created by Nat and used at the SIOP panel.

※ Issuing Authority (IA) has also been referred to as Authoritative Claims Provider, or just Claims Provider is some issues.

[Torsten Lodderstedt]

First of all, I support adoption of the credential provider draft (see http://lists.openid.net/pipermail/openid-specs-ab/2021-May/008356.html).

Second, we are desperately waiting for an official WG draft defining a way for credential issuance based on OpenID Connect to start work on some prototypes.

I don’t mind whether this is Claims Aggregation or a credential provider draft as long as it solves the use case. However, my feeling is we will quicker reach a stable draft when focussing on the problem at hand. So I support Kristina’s proposal.

[Nat Sakimura]

Nothing claimed in this ticket about the Claims Aggregation draft seems to be correct.

1) Dynamic vs “Chopped” flow. 

The slide I used in the SIOP panel at Identiverse was for the purpose of depict issues around dynamic v.s. pre-issued claims and has nothing to do with the Claims Aggregation draft. If anything, it is OpenID Connect Core. The Claims aggregation draft does not use “nonce” and explicitly allows pre-issued ones and allows “out-of-sync” flows.

2) Necessity to do status check / validation

The statement “In Claims Aggregation flow, RP does not need to do a check status of a credential” is wrong as stated above.

The “Claims Aggregation” draft does verify included “credentials”. It does not explicitly state how to validate etc. as it depends on the type of the “credentials”.

For example, for a regular JWT, you need to retrieve the verification key according to the JWS spec and verify the signature, make sure that it has not expired, etc. Other rules may apply depending on the profiles. To make profiling possible, the Claims Aggregation draft states in 9.6 Claims Verification

1. the RP MUST extract the signed claims from JWT and other relevant members and verify according to their verification rule;

3) Mechanism of Credential Binding.

The Claims Aggregation draft does not use nonce. So, the statement made here is wrong.

What you have stated here as “Claims Aggregation” is OpenID Connect Core 1.0. The claims aggregation draft uses issuer and subject identifier for this purpose.

4) Being dynamic is the beauty of Claims Aggregation draft

No, that’s the beauty of the OpenID Connect Core 1.0. Claims Aggregation draft is extending it and allowing out-of-sync flows.

Finally, please do not submit somebody else’s material without permission to the working group. The material was not contributed to the WG by the author and will cause IPR issues. It is kind of ok because it was me who created it, but all WG members should be careful about something like this. It does not conform to the OpenID Foundation’s IPR policy. A

‌

‌

‌

‌

[Kristina Yasuda]

I am very sorry about the material and will be careful. Do you want me to delete it? @Nat Sakimura

[Kristina Yasuda]

I will try to reiterate the core of the question I was trying to ask. We have a need for the specification to issue Verifiable Credentials to the user’s mobile device, and I would appreciate if you can help clarify how this can be done using Claims Aggregation draft.

Let’s use the scenario where employer is asking for a graduation credential issued by a university from a user’s wallet.

The way I currently interpret is, if employer is CC, university is IA, and a user’s wallet is IW, implementations could use Claims Aggregation draft for issuance between IA and IW (steps 3 and 4 in the delivery phase text below), and use OIDC4VP draft for presentation between IW and CC (steps 1, 2, 3, and 6 in the delivery phase text below) - is this enabled in the claims aggregation draft, since claims collection can be done out of sync? Apologies if there is already a text clarifying this and I missed it.

Delivery Phase (CC Phase)

In Delivery Phase, the claims are delivered to CC. To do so, it typically goes through the following steps:

1. (Claims Request) An CC makes an OpenID Connect Authentication Request with extension parameters defined in this document to the IW.

2. (Request Verification) The IW verifies if the request is valid.

3. (Subject Granting) The IW shows dialogue to the Authenticated Subject if it grants the access to the claims and obtains grant from the Subject.

4. (Claims Collection) The IW accesses relevant Credential Endpoints with Access Tokens to collect signed claims.

5. (Claims Delivery) The IW delivers the collected claims through ID Token, UserInfo endpoint, and/or Credential Endpoint if it supports.

6. (Claims Verification) The CC verifies the recieved response.

Claims Collection MAY be done out of sync. That is, the signed claim sets can be obtained before the CC requests. This is typically the case when claims are provided through the W3C Verifiable Credentials container.

‌

[Michael Jones]

If openid / connect / Pull Request #40: Proposal for issue #1270 — Bitbucket is merged, then we should evaluate the result to ensure that the capabilities described in this issue are enabled.

[Nat Sakimura]

Maybe PR 39 instead?