Alignment with PCTF and its Trusted Process concept

Issue #1227 resolved
Ben Helps created an issue

Investigate alignment between current spec and the Pan Canadian Trust Framework (PTCF), particularly as it relates to evidence / Trusted Process

Trust Framework | Digital ID & Authentication Council of Canada (diacc.ca)

PCTF Verified Person Component Overview (diacc.ca)

Concept of a trusted process offers a potential bridge between PR #54 (separation of trust framework and assurance level) and PR #50 (attachment of evidence) to support interoperability between trust frameworks.

Comments (5)

  1. Ben Helps reporter

    This issue also overlaps with Issue #1232 from Julian (explicitly state how the user has been verified as the owner of the claims).

    The spec would be enhanced if OPs could separate out a) what they have done to build assurance in individual attributes from b) the assurance level(s) they are asserting to either an individual attribute or a collection of attributes (such as an identity profile) and c) the Trust Framework(s) under which the assurance level(s) are described.

    This would increase interoperability between Trust Frameworks, as the basic steps to building assurance around claimed attributes are the same across different Trust Frameworks - it is the way that they are interpreted / weighted / composed into a “score” that differs.

    This would also align with the stated scope of the spec: an OP must be able to describe the basic steps in sufficient detail for “to provide the RP data about the identity verification process along with identity evidence to allow the RP to conduct their own risk assessment and to map the data obtained from the OP to other laws.”

    Example comparison of (meta)processes across PTCF, GPG 45 (UK) and NIST 800-63:

    Like Julian, I think this argues in favour of creating fields that allow the OP to differentiate between the methods used to a) validate evidence and b) verify the user as owner of the evidence/identity/attribute. Where different evidence is used to support different attributes/claims, the appropriate methods can be nested in the data structure, as per Multiple Verified Claims

    {
      "verified_claims":[
        {
          "verification": {
            "trust_framework": "uk_trust_framework"
            "assurance_level": "verification_score_3"
            "time":2012-04-23T18:25Z",
            "verification_process":"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
            "verification_method":"biometric_match"
            "evidence":[
          {
                "type":"id_document",
                "assurance_level": "validation_score_2"
                "time":2012-04-23T16:10Z",
                "validation_process":"z95c6f-8y3f-4ec5-773e-c0d8506g5vb9",
                "validation_method":"uv_ir_sec_feature_check",
                "document":{
                  "type":"passport"
         },
          "claims": {
            "given_name": "Max",
            "family_name": "Meier",
            "birthdate": "1956-01-28",
            "place_of_birth": {
              "country": "DE",
              "locality": "Musterstadt"
            },
            "nationalities": [
              "DE"
            ]
          }
        },
      ]
    }
    

  2. Julian White

    Yes. This is exactly the thing I was trying to get across in #1232.

    I was also wondering whether you might want to put the verification details inside the evidence element in the cases where you have multiple types of evidence and you have done some verification against each of them.

  3. Log in to comment