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]

I got convinced that supporting an array of verified claims is simpler to use than the encoding Daniel and I proposed. After having thought about this for quite some time ((:-)), I’m leaning towards supporting a single value as default and additional an array.

[Takahiko Kawasaki]

From developers' point of view, if verified_claims can be an array, it should always be an array even when the number of elements is 1.

[Marcos Sanz]

I’d be against “a single value as default and additional an array” (they’d even have to have different names).

“an array that cannot be empty” (and thus it has one element at least) would be much easier to handle.

[Torsten Lodderstedt]

that would be a breaking change for existing implementations. Besides this, there are other places in OIDC, where we use the same pattern, namely aud.

[Marcos Sanz]

Would there be well-formed JSON-schema for that? (excuse my ignorance, never seen such a thing)

[Takahiko Kawasaki]

Yes, it is a breaking change, but luckily, there are few implementations at this moment. I myself (Authlete) is okay and will change our current implementation accordingly.

I know aud can be either a string or a string array. Actually it was in my mind when I posted my last comment. The following snippet is what implementers have to do for aud. Apparently, extra work is required, which non-implementers may not know or even cannot imagine.

‌

Object aud = json.get("aud");

// The type of the 'aud' claim may be an array or a string.
if (aud instanceof JSONArray)
{
    verifyAudAsArray((JSONArray)aud);
}
else
{
    verifyAudAsString(aud);
}

‌

The "single or array" pattern prevents developers from using JSON-to-Class-type parsers. If such pattern exists, developers have to convert JSON into a generic Key-Value map and parse the properties one by one manually. This is the reason developers don't like the "single or array" pattern and the "variable property name" pattern that spec authors may not care about.

That the “single or array” pattern has already been used in other places is not a convincing reasoning from developers’ point of view.

[Torsten Lodderstedt]

We have already rolled out the latest draft with our banks and are integrating and activating RPs as we are speaking. Most of them are regulated entities and are not as agile as you. A breaking change is therefore a tremendous issue for us.

I’m not saying it is impossible, but it at least requires a sounding migration strategy (versioning?) and time.

[Takahiko Kawasaki]

Understood. Then, possible options are (1) the single-or-array pattern or (2) a new different name as Marcos has suggested.

[Marcos Sanz]

I also understand the problem of the breaking change. I would accept the single-or-array pattern if there’s JSON-schema support for such construct (Identity Assurance is the first OIDF spec I see making use of schemata and I really think there’s lot of value to that).

[Torsten Lodderstedt]

I experimented a bit with JSON schema and created a new revision supporting object-or-array for verified_claims.

BTW: JSON Schema itself heavily relies on the object-or-array pattern, so support is natively built in.

[Torsten Lodderstedt]

PR exists

[Takahiko Kawasaki]

I noticed that It might be worth considering making the type of “verified_claims in the request (input)” object-or-array, too.

[Torsten Lodderstedt]

Why do you think this is needed? My assumption is that the RP does not need an array to define its requirements. But I might be wrong.

I suggest we wait for the outcome of #1153 do decide this particular question.

[Torsten Lodderstedt]

fixed with pull request #5