<div dir="ltr">Thanks for the clarification.  I would change some of the terms as follows;<div>chopped => async (that allows use of promises for claims that will be provided later.)</div><div>dynamic => sync</div><div><br></div><div>then that leads us to the core problem created by the VC spec. Namely, it mixes the traditional concept of certificate into the broader term VC.  Since certificates will not go away for a very long time I dislike the mixing of vc with credentials where they result in the same  structure and the distinction is purely semantic. I would find the concepts much clearer if the term VC was reserved for places where a blind proof was required and we continued to use the term certificate for a signed set of claims that is not blinded as they will surely continue in the mix.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">hth  </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 25, 2021 at 1:20 AM Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">New issue 1250: Separating Claims Aggregation and Credential Provider drafts<br>
<a href="https://bitbucket.org/openid/connect/issues/1250/separating-claims-aggregation-and" rel="noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1250/separating-claims-aggregation-and</a><br>
<br>
Kristina Yasuda:<br>
<br>
Claims Aggregation draft and Credential Provider draft deal with the flows that are different enough that they should be separate specifications:<br>
<br>
* **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.<br>
* **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. <br>
* **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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
※ Issuing Authority \(IA\) has also been referred to as Authoritative Claims Provider, or just Claims Provider is some issues.<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>