[Openid-specs-ab] Issue #1250: Separating Claims Aggregation and Credential Provider drafts (openid/connect)

Kristina Yasuda issues-reply at bitbucket.org
Fri Jun 25 08:20:29 UTC 2021


New issue 1250: Separating Claims Aggregation and Credential Provider drafts
https://bitbucket.org/openid/connect/issues/1250/separating-claims-aggregation-and

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.



More information about the Openid-specs-ab mailing list