Open ID Connect 4 Indy Assurance

From IIW

OpenID Connect for Identity Assurance


Tuesday 2L


Convener(s): Torsten Lodderstedt (yes.com)

Notes-taker(s): Neil Thomson (QueryVision) & Torsten Lodderstedt


Tags for the session - technology discussed/ideas considered:


OpenID Connect, Proofing, Identity, Assurance, Validation, Verified Claims


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


Notes from Neil Thomson:

Torsten (w slide deck) presented the core concepts behind the Use Cases driving the need for Identity Validation/Certification/Assurance as being driven by German standards/compliance (e.g. Anti-Money Laundering Laws, Telecommunication Acts, Anti-Terror Laws, and regulations on trust services, such as eIDAS) governing Health services use cases for users accessing their own health system data.


The proposed standard defines the presentation of verified vs non verified claims via the JSON package provided by the IdP to the RP, plus the ability of the RP to query for both claims and verification metadata about those claims in the RP/IdP communication protocol.


The key requirement is the need for the RP to be able to retrieve validation metadata about user claims (from the IdP) to ensure that requests don’t proceed if the user does not meet the validation criteria.


The proposal for OIDC identity assurance is focused on the unchangeable “natural” data about a person in the health system. For example, this includes unchangeable information about the physical person (birth family name, country… and birth records), but not email or current address, which can change over time.


The proposal adds a number of claims to enhance the current OIDC claims for the “natural person”. This may not be complete.


Torsten emphasized that the intent of the proposal was a “MVP” (minimal viable product)/pragmatic approach, based on dealing with the minimal complexity based on concrete use cases and standards which have been proven in initial application - as a starting point which could move forward immediately, with updates based on a new proposed Working Group.


The proposal is based on actual working solutions based on customized OpenID Connect solutions, which are in the process of being upgraded to use the new Identity Assurance specification – so the proposal is based on working, German regulatory compliant solutions, including online/electronic signatures.


He also emphasized that this specification must – by design – accommodate evolution of the metadata and techniques used for validation.


The discussion quickly changed to questions, observations and additional requirements (in support) of the proposal.


  • The presentation is about the solution to the standards/requirements driving a pragmatic solution to those factors
    • What are the use cases driving Identity Assurance?
    • This should be documented and expanded by proposed Work Group (WG) contribution
  • The proposal doesn’t currently allow for claims to be individually be validated by different Trusted Providers.
  • The dividing line between the “biological person” vs. the “data person” is difficult to determine. Perhaps this needs to be determined by convention/input from the proposed WG
  • A key point is the accommodation for verification determined by multiple Trust Frameworks, with each claim being validated by traceability to one or more Trust Frameworks.
  • Requesting individual claims vs using scopes - feedback
    • This is potentially a privacy issue for RPs requesting claims they should not be allowed to ask for (phishing for personal data). Suggest some standard “Scopes” which are pre-defined for “unchangeable person” metadata to avoid this problem.
  • Request for having the Trust Framework (TrstFrmWk) identified for each claim (e.g. if the “natural person” claims are provided by multiple TrstFrmWks
  • RPs filtering – the concept of the RP can request which claims to return and which must be verified plus how they are verified
    • The proposal was well received – allowing the RP to request only the data it requires.
    • This should be extended to allow the RP to specify which Trust Framework(s) must be included in the validated claims request.
  • The standard should include the ability to extend what metadata is required (as this evolves) by the specification supporting extension
  • Observation (from several) – Trusted Frameworks may be common in principle, but in practice are Country specific (e.g. EU standard, but Italy has their own variation) – so determining a common set of claims is complicated (observation: almost random selection and mapping from one country to another in EU).

Perhaps an abstracted model of claims will mapping to individual Country (or other jurisdictions) claims organization or naming is required to have sufficient commonality to avoid an explosion of claims (and complexity for RPs). There was consensus that a mechanism to stop an explosion in complexity is required.

  • How does the IdP know which Trust Frameworks can be trusted? Are they subject to a tiered level of trust (from weak to strong)?
  • On the subject of explosion of size of URLs that include claims parameter requests:
    • Use JPATH?
      • Incompatible with OpenID Connect
    • Torsten proposed new “Push Authorization Request” – proposal to be tabled soon to avoid “piping” large volume of data via URL requests.
  • Question – how to conduct verification based on consent from the user on the individual claims?

It was proposed to determine how to integrate consent (by the user) into the validation process


The current proposal leaves the user consent at the discretion of the OP


Link to Torsten Slidedeck:

https://www.slideshare.net/TorstenLodderstedt/openid-connect-for-identity-assurance-178535795

Retrieved from "https://iiw.idcommons.net/index.php?title=Open_ID_Connect_4_Indy_Assurance&oldid=22577"