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

Tom Jones thomasclinganjones at gmail.com
Fri Jun 25 15:15:50 UTC 2021


Thanks for the clarification.  I would change some of the terms as follows;
chopped => async (that allows use of promises for claims that will be
provided later.)
dynamic => sync

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.

hth ..tom


On Fri, Jun 25, 2021 at 1:20 AM Kristina Yasuda via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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.
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210625/7d337c5c/attachment.html>


More information about the Openid-specs-ab mailing list