Identity Proofing w/Open ID
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: https://de.slideshare.net/TorstenLodderstedt/identity-proofing-with-openid-connect
(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.
Names
Addresses
Relationships
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, yes.com
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
Example
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 (yes.com)
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.
torsten@lodderstedt.net
Would want the verifier to sign things directly using the distributed and verifiable claims system in OpenID Connect.
