pre-configured claims eKYC requests

[Torsten Lodderstedt]

In a session I convened at IIW #32, there was a suggestion to allow RPs to setup and, in the authentication request, reference eKYC requests. I suggest to discuss this idea in the group. In our experience, such requests are pretty static per RP and such a reference could be a handy alias shortening the request and making it less vulnerable for modifications.

[Brian Campbell]

I think, because the needs of each RF are pretty static in many/most cases, there’s real value in something like this that allows the avoidance of the processing and evaluating complex content on every request.

[Kai Lehmann]

Wouldn’t the OP just introduce specific scopes for that?

[Brian Campbell]

Torsten had some hesitancy towards using scopes when we talked about this at IIW. But I don’t remember or didn’t understand the objections.

I’d be quite satisfied if the eKYC spec had some text that allowed for OP defined scopes to be used in place of a particular claims request.

‌

[Torsten Lodderstedt]

That would be RP and OP-specific scopes, whose resolution does not follow standard OIDC default claims set logic. Alternatively, a new construct (or kind of scope) could be introduced.

[Kai Lehmann]

True, it is essentially between RP and OP to define such scopes. OIDCC states “For OpenID Connect, scopes can be used to request that specific sets of information be made available as Claim Values.”, so IMO this should already be applicable to verified claims as well. OIDCC already defines a set of scope values which are defined to have all associated claims to be treated as voluntary, but it is up to the OP to define additional scopes resulting in a completely different set of claims (including verified claims) and what is voluntary or essential.

That said, there is some merit in the OP to support some kind of open scope definition which can be used by RPs to define the exact datasets they need so that they can later go ahead with just requesting this defined scope. I think that the client registration and management interface could be used for that.

[Brian Campbell]

Such scopes might be specific to a particular RP but not necessarily. An OP might well service multiple RPs with the same or slimier claims needs and could all make use the same OP defined scopes. And even for cases where each RP has unique needs, there’s nothing precluding a scope being applicable to a single RP.

[Takahiko Kawasaki]

To define shortcuts by special scope values or by other means, it is necessary to agree on what are “typical” verified_claims requests. However, it would be difficult to reach an agreement due to the complexity, flexibility, filtering mechanism and multi-jurisdiction nature of the verified_claims request format. In addition, if we decided to introduce shortcuts, it also would become necessary to explain the relationship between the shortcuts and the data minimization policy that requires client applications to request claims “explicitly”.

For instance, suppose we have agreed that a special scope value “basic_verified_claims“ represents the following verified_claims request.

{
  "id_token": {
    "verified_claims": {
      "verification": {
        "trust_framework": null
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  },
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

This would enable a client application to omit the claims request parameter by including basic_verified_claims in the scope request parameter, but the resultant verified_claims response will contain only trust_framework and the specified verified claims (given_name, family_name and birthdate) and will not contain any evidence, assurance_process, and other data because of the data minimization policy.

It might be possible to define a special scope vaue “basic_verified_claims_with_evidence_document“ that represents the following verified_claims request to include all sub-elements of evidence whose type is document.

{
  "id_token": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "evidence": [
          {
            "type": { "value": "document" },
            "check_details": {
              "check_method": null,
              "organization": null,
              "txn": null,
              "time": null
            },
            "method": null,
            "verifier": {
              "organization": null,
              "txn": null
            },
            "time",
            "document_details": {
              "type": null,
              "document_number": null,
              "personal_number": null,
              "serial_number": null,
              "date_of_issuance": null,
              "date_of_expiry": null
            },
            "issuer": {
              "name": null,
              "formatted": null,
              "street_address": null,
              "locality": null,
              "postal_code": null,
              "country": null,
              "country_code": null,
              "jurisdiction": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  },
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "evidence": [
          {
            "type": { "value": "document" },
            "check_details": {
              "check_method": null,
              "organization": null,
              "txn": null,
              "time": null
            },
            "method": null,
            "verifier": {
              "organization": null,
              "txn": null
            },
            "time",
            "document_details": {
              "type": null,
              "document_number": null,
              "personal_number": null,
              "serial_number": null,
              "date_of_issuance": null,
              "date_of_expiry": null
            },
            "issuer": {
              "name": null,
              "formatted": null,
              "street_address": null,
              "locality": null,
              "postal_code": null,
              "country": null,
              "country_code": null,
              "jurisdiction": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

If this basic_verified_claims_with_evidence_document can cover most use cases, it may be worth defining the special scope value. However, it is unlikely.

Regardless of whether shortcuts for typical verified_claims requests are achived by special scope values or by other means, they would not be so useful, I’m afraid.

[Brian Campbell]

I don’t think the spec should define special scopes. I’m advocating for individual deployments/ecosystems to be able to define and use scope values rather than the whole claims request and still be considered compliant.

[Joseph Heenan]

I worry that allowing pre-defined scopes could be a slippery slope with the end result that it becomes common for RPs to use a predefined scope that requests more PII than they actually need/want. (Or put another way, I think to some extent the use of explicit requests for claims encourages the requests from RPs to be fine grained and only for exactly what is needed.)

[Brian Campbell]

I apologize for not following this stuff closely but just came across the text from OIDC4IDA copied/linked below, which I think satisfies what I was advocating for.

‌

https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID3.html#section-6-2

It is also possible to use the scope parameter to request one or more specific pre-defined Claim sets as defined in Section 5.4 of the OpenID Connect specification [OpenID].

‌

https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID3.html#name-requesting-sets-of-claims-b

7.8. Requesting sets of Claims by scope

Verified Claims about the End-User can be requested as part of a pre-defined set by utilizing the scope parameter as defined in Section 5.4 of the OpenID Connect specification [OpenID].

When using this approach the Claims associated with a scope are administratively defined at the OP. The OP configuration and RP request parameters will determine whether the Claims are returned via the ID Token or UserInfo endpoint as defined in Section 5.3.2 of the OpenID Connect specification [OpenID].

‌

[Mark Haine]

Resolved by section 7.8 as per Brian's comment