Identity Proofing w/Open ID

From IIW

Identity Proofing w/Open ID

Day/Session:Wednesday 4H

Convener:Torsten Lodderstedt

Notes-taker(s): (1) Torsten Lodderstedt & (2) Nick Roy

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

(1) Link to Torsten’s slides:

(2) Nick Roy’s Notes:

BC Government OrgBook - Stephen Curran, BC Gov't

Issuing/tracking organizational DIDs on a hyperledger

Intergovernmental interop and person resolution through DIACC

Central repository of org credentials starting with a foundational credential - what is issued at the incorporation of a company

BC registries registers company - prints a certificate, and mint a verifiable credential. Company doesn't have a wallet, the registry issues the credential to the public OrgBook. Then it's a repository of verifiable credentials.

Have issued 1.4 million credentials to date.

Only public keys involved is the issuer (registry's DID) and the OrgBook key that it uses to interact with the issued credentials. Live on the Sovrin network, 10 transactions so far.

The data is all public.

Shows the relationship between corporate entities like subsidiaries.




Credential types

Can feed it any credential and it can process it.

Issue a proof request to the org book that proves the credential, shows a green checkmark. They display the proof request response (JSON).

A permit issuer that needs to know info about a requester can issue a proof request to the org book to prove that the credential is active, exists, hasn't been tampered with, and is still valid.

Could be really useful for InCommon org identity proofing.

Can you claim ownership of a company?

The org can get their own wallet, which contains the proof that they own the company. Provide an administrative inteface to add metadata about the company - self-issued credentials like operating hours, lines of business, etc.

Two instances live - Ontario and BC.

Running in an enterprise use/scaled environment.

Built it for multiple jurisdiction support.

The relationship mapping/proof would also be really interesting for InCommon for stuff like the TALX<-->Equifax relationship.

The registrar can revoke old credential and reissue a new credential to orgbook.

>> Identity proofing with OpenID Connect - Torsten Lodderstedt,

Verifying data that an IdP provides

Prove identity data to relying parties because the RPs have regulated use cases

There is no way to communicate that today in SAML or OIDC

Invented their own way to do this

Use cases

- Opening a banking account (anti-money laundering)

- Applying for a loan (AML)

- Mobile subscription (Anti-terrorism)

- ID for access to health data

- Qualified electronic signature (eIDAS/etc)

Needed for

user claim values

confidence level per claim or set of claims

data about the verification process and identity sources (e.g. document number)

Supports mixture of verified and unverified claims (self-declared and issuer verified)

Used with: User info, ID token, access token introspection

Needs to be a way to request specific claims to be verified (selective disclosure)

What verification means is defined by assurance frameworks, but need a syntax to transport the data

This is very similar to authentication context and vectors of trust, but they are not granular enough

Side note: Token introspection is a problem for Google/Microsoft because of scaling/throttling


RP wants to verify user identity according to eIDAS assurance level substantial

Need Name, Birth Date, Place of Birth, Nationality

User was verified using national ID card by the bank, according to anti-money-laundering law

Bank has know your customer data associated with online banking account

How they did it:

Add a verified_person_data claim in a specific namespace (

Verification gives all the verificatoins evidence, associated with a claims object

Externalize all the data collected to verify the data. Banks collect data according to anti-money-laundering law, but that data can be mapped into eIDAS verification requirements.

Method of proofing is included in the verification context because some forms of proofing are excluded for certain use cases.

What ties the verification data to the claims? Nesting within the JSON. Claims are nested within the verification data.

Must be possible to dynamically request the claims

Extended the set of claims for OIDC because they needed some claims that don't exist yet

Requesting verified person data

Extend the claims parameter - can specify at the user info endpoint that you want to see a type of claim, and you want to make it essential.

The RP can specify which claims it wants from the OP

Mike Jones says the right way to do this is to make the verified_person_data type be an attribute of the claim you are requesting from the user info endpoint. One of the syntaxes is outside the claims portion and one is inside the claims portion in Torsten's model, which Mike says is incorrect.

But, also need to set parameters on the verification type - example: expected value of the max age of the verification date. Can't do that at the top level, or you'd have to specify that for each and every claim.

Step-ups scenario

Want a success/failure scenario - if failure, ask for a different set of claims. Does this support that kind of dynamic challenge-response?

Not doing protocol, just doing syntax.

Use cases exist, and there is money behind it.

Could see multiple signals coming from multiple directions - example the CIVIC demo. They are doing this from a different direction, using blockchain. They insert in the process of issuing something, where they can involve the verifier, and cache the result of the verification on your device, and place a hash of the information on the blockchain. Whenever you need verification, you just verify the claim on their device with the hash, so info never leaves the device.

Are there opportunities for collaboration?

Agree on the schema/syntax for this kind of assertion

This doesn't require c18n, whereas verifiable claims require RDF/JSON-LD and that has been rejected by developers with their feet. We shouldn't try to do that again.

Want the data, and evidence of the data, feed that into a risk engine.

How are the clients consuming the verifiable claims? Are they looking for specific strings of the proofing type, etc?

It's not being widely used yet - there is at least one client looking for specific values of proofing type.

Electronic audit trail for digital signatures - in case of dispute or audit.

The schema is a hard problem that needs a generalized solution.

RP knows what they want, but the question is how do they tell the OP what they want, and how does the OP communicate back to the RP what it can provide?

Some of the claims have a fixed list of values - starting point for creating a registry.

What happens when verification policy changes?

Need the ability to add new verification methods to the implementations/taxonomy

Should we be talking about standardized levels of methods to do abstraction? That maps back to stuff like NIST SP800-63, but that failed. Need to be able to express desired properties of a verification.

This feels like overcommunicating, the NIST method undercommunicates. We have to play with what works and what doesn't.

The issuer needs to sign the document so that you have verifiability that the issuer's claim isn't tampered with by the OP.

Would want the verifier to sign things directly using the distributed and verifiable claims system in OpenID Connect.