Support multiple verified_claims elements

[Torsten Lodderstedt]

Hi Thorsten,

As it's my first post on this list, let me introduce myself. I am working with Marcos in ID4me initiative and within technical group we are right now in the process to define the framework for federated and verified identities for ID4me ecosystem.

Very interesting question. I had envisioned the external claim provider to provide the while “verified_claims” Claim at
once. As this is a top level claim, one can rely on the standard OIDC mechanisms.

This is what I would also expect it to be, to bind "claims" and "verification" under the same object and signature.
The problem we see is that "verified_claims" is a singular claim, so cannot be delegated to two or more entities, which may provide different subset of verified data requested by the RP.

Now you are proposing to obtain the claims within the “verified_claims” Claim from external providers. Syntactically
we can make that work on one way or the other.

I would like to understand more about the context and use case. How does the IDP asserting the “verified_claims"
Claim to the RP ensure that the externally provided data comply with the data provided in the verification element?

I think this is the issue with solution proposed by Marcos, that delegating claims on the second level it is not expected that aggregated/distrtibuted claim would contain whole "verified_claims" object including "verification".

A solution to that would be defining "verified_claims" as an array and using JSON references.

{
"iss":"https://server.example.com",
"sub":"248289761001",
"verified_claims":[
{
"claims":{
...
},
"verification":{
...
}
},
{
"$ref":"#/verified_claims_src1"
},
{
"$ref":"#/verified_claims_src2"
}
],
"_claim_names":{
"verified_claims_src1":"src1",
"verified_claims_src2":"src2"
},
"_claim_sources":{
"src1":{
"JWT":"..."
},
"src2":{
"JWT":"..."
}
}
}

Kind Regards,
Pawel

[Pawel Kowalik]

‌

From: Torsten Lodderstedt
Sent: 13 August 2019 09:23
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

It sounds reasonable to me but I we as as WG need to understand the consequences. Do you envision any changes to the request syntax or is the split among the array elements at the discretion of the OP?

‌

As the request is describing what information RP wants to receive (with applicable restrictions about Verification Data as specified in 5.3), and there is no intention to specify more how OP shall fulfill this request, I think it shall be left to the discretion of the OP whether it can fulfill the request using one data source or more data sources and to what extent.

[Torsten Lodderstedt]

makes sense.

[Torsten Lodderstedt]

How often will your IDPs need to return multiple verified_claims elements? I’m asking because this means your IDP needs to obtain claims from at least two sources.

[Pawel Kowalik]

“How often” is a difficult question to answer. As we are defining an open and federated framework I cannot tell how frequent it will occur right now. I would like to avoid that the specification does not allow at all for such setup.

[Torsten Lodderstedt]

That’s understood. But it makes a huge difference whether it is an edge case or the standard use case. OpenID Connect very successfully adopted the philosophy “make simple things simple and make complicated things possible”. This means in the context of this ticket, if this a common case then we should just turn verified_claims into an array whereas if this a case that happens seldom (in terms of number of deployments) I would leave the single value and add another option to carry more than a single verified_claims object.

[Pawel Kowalik]

I think in general context of the deployments all around it would be rather a corner case.

[Daniel Fett]

Torsten and I thought about an alternate syntax for multiple verified_claims objects. In this syntax, a dollar sign is used as a separator between verified_claims (as the identifier of the object type) and an arbitrary id. See example:

{
    "iss":"https://server.example.com",
    "sub":"248289761001",
    "verified_claims$vc0":{
        "claims":{
            ...
        },
        "verification":{
            ...
        }
    },

    "_claim_names":{
        "verified_claims$vc1":"src1",
        "verified_claims$vc2":"src2"
    },
    "_claim_sources":{
        "src1":{
            "JWT":"..."
        },
        "src2":{
            "JWT":"..."
        }
    }
}

Implementations that are aware of this notation see multiple “verified_claims” objects and can parse them accordingly. For implementations that expect (and get) only one “'verified_claims” object, nothing changes.

[Marcos Sanz]

This is for me pretty clever and ok, as long as we make clear that this must not leak to the query syntax in the current section 5.1 (that is, there is no such thing as a claim name verified_claims$vc3you can directly query for)

[Torsten Lodderstedt]

I agree. The query syntax currently does not determine the allocation of information to aggregated or distributed claims and I would like to keep this behavior for this case. It’s at the discretion of the also re allocation to different verified_claims. It’s at the discretion of the OP to provide the RP with multiple verified_claim elements.

BTW: This also means the OP could provide the RP with the same end-user claim verified by different claim sources in different verified_claims elements.

[Torsten Lodderstedt]

transferred to https://bitbucket.org/openid/ekyc-ida/issues/1105/support-multiple-verified_claims-elements