the trust_framework element contains both the TF and the IAL and they should be separate

Issue #1224 resolved
Julian White created an issue

The element “trust_framework” actually contains two things, the TF and any associated identity level. I think this could be both difficult to manage and create confusion.

In the definition we say:

trust_framework: REQUIRED. String determining the trust framework governing the identity verification process and the identity assurance level of the OP.

Which is clear that it is about which trust framework you are using; however we then go on to say:

An example value is eidas_ial_high, which denotes a notified eID system under eIDAS [eIDAS] providing identity assurance at level of assurance "High".

Which seems inconsistent because we did not define that the IAL should be in the TF element.

Having the the level in the TF element means there could be a lot of TF name variants to manage because they must not clash with each other, whereas the number of actual TF’s is much smaller so is a much smaller issue.

Some TF’s do not have multiple assurance levels, so they have nothing to add here; whereas others use a very granular scoring system so could be dozens of “levels”.

The term IAL is not universal, its mostly a NIST-800-63 term, it has no meaning to an eIDAS user, for example, where they use LOA instead. The protocol should deliver something that makes sense to the consuming business, not something that they then have to work out what that means for their TF. It also seems to imply that I would have to map my TF to NIST definitions of IAL, which is not correct.

Lastly when using things like a QES as evidence the IAL isn’t important as that is already set out in the TF itself, its just that its a QES under the eIDAS TF that matters.

My suggestion is that we should make the TF element simply the name of the TF, e.g. eidas, and let each TF extend that with whatever levels they see fit (or none) that matches their business use case. For example: under eIDAS it could be loa_low, loa_substantial, loa_high; the Swedish Trust Framework could be loa_1, loa_2, loa_3, loa_4 (albeit that loa_1 is never used in practice); the UK trust framework could be cl_low, cl_medium, cl_high and cl_veryhigh.

Comments (6)

  1. Torsten Lodderstedt

    The reason to build the „trust_framework“ from trust framework and (optional) assurance level was based on a very pragmatic consideration:

    „eidas_substantial“ and „de_aml“ can be added as alternative „value“ constraints to the „trust_framework“ field in a request.
    If we split the values, the same request would require multiple verified_claims elements, one with „trust_framework“ „eidas“ and „ial“ „substantial“ and another one with „trust_framework“ „de_aml“.

    We need to keep this in mind when deciding about the proposed change.

    Speaking as implementor, for us (yes.com) it wouldn’t be a breaking change so I do not oppose against the change.

  2. Log in to comment