(Oliver Terbu)
All information provided is not decided and not part of any official standard. The information only reflects the personal opinion of the presenter. It is also not intended to create a new eID standard. Priority have attended use cases where the verifier and mDL holder have physical contact.
Two models:
Problems
OIDC feasible approach in general?
Mitigate privacy issues due to issuing authorities potentially seeing every transaction
Assurance level framework - NIST, eIDAS, gov.uk/etc. (which one/mapping?)
How does it play together with eIDAS, gov.uk/etc.?
Could we solve part of the "which assurance framework?" problem by using something like a refactored Kantara "meta IAF" as discussed in: https://tiime.pad.sessiontracker.eu/p/sonofiaf?
It turned out that for the use case specifying the authentication context class reference may be sufficient rather than using one specific assurance level framework. OIDC also supports means to express the authentication context class reference values.
Architecture
Requirements for this workshop
OIDC model
Assumptions:
Verifier has:
ICAO PKI database access
Bilateral trust agreements between verifier and issuing agencies
Questions** :**
TFP?
Answer: out of scope
Why using OIDC, which relies on browser TLS, which is not real security, rather than signed SAML?
Answer: OIDC supports signed encrypted request objects and id tokens are also signed and optionally encrypted.
Remark: There are no consistent implementations available for this option.
Why go online at all?
Answer: in the online model you can get attributes from the issuing authority online - get immediate effect in status changes.
Discussion of payment system model - offline key used to sign a transaction with a reader, only the reader needs to be online. This could be a model when the mDL is off-line in case verification is needed.
With OICD all trust is derived from endpoints on the transport layer; extending it with signatures is not standard. It was also stated that OIDC does also support encrypted request objects which may be signed and id tokens are signed by the IdP and can be optionally encrypted.
Revocation (opposed to ICAO) should be possible
Two levels of key revocation needed:
Authentication of a driver's license online requires the entry of a second factor to prove presence - require specific authentication context
Four bridges forum as a federal PKI bridge - look into using this for rooting trust - US gov, pharmaceutical industry, UK/Netherlands gov't., Aerospace industry, etc.
Hooking into a heavy duty PKI infrastructure makes sense here because it is a government high-assurance use case. The most advanced instance are the PKIs linked up in the Four Bridges Forum ( http://www.the4bf.com/)
The use case requires secure message exchange, metadata registry, LoA, message level encryption. SAML has that out-of-the-box, with OIDC this is years away until becoming mature. The key benefits for OIDC are message compactness and ease of use for JavaScript clients. It was also mentioned that OWASP considers OIDC as secure and stable.
After further discussions it turned out that it is not possible to register every SP i.e. verifier. SAML typically relies on a metadata registry.OIDC feasible approach in general?
Mitigate Privacy issues because issuing Authorities can potentially see every transaction
Assurance Level Framework (NIST,eIDAS.GOV.UK,etc.)
How does it play together with eIDAS.GOV.UK etc.?
Architecture
1.
For example a simple bar code should have enough information to give someone the priority to drive a car for example.
Requirements:
OIDC model
2, 3.Service discovery URL
4, 5. Dynamic Client Registration
6, 7. Create authorization request using the token as log in
8, 9. Optional user info endpoint
In most cases we should use a browser but in this case the token is being used.
Actually the biggest pro of this system is that you will not need any more a physical id which you need to use but this also opens a big issue with copying the information.
There are two models the online and the offline model the online is not required is actually an added option.In common and similar systems only the reader needs to be online but the user doesn't wait every let's say 10 transactions in order to refresh.
It is based on explicit trust. If let's say someone is using open id connect because it is easy for implement but then you lose the benefits of it because it is different.
There is also this bilateral trust problem because if the key does not work it will need to be replaced and basically someone else could steal the information this way. The person needs to be authenticated as well and there will also be a second factor.
It cannot be done without any central registry so there is a big complexity so it is years away from any realistic implementation. The problem is that it actually is not scalability use cases.
The only way to do authentication well is by challenge and response all the other ways like time based authentication is not secure enough.
The second factor could be by a challenge for example.
A driving licenses can be used as a proving device for many things like buying age restricted items , showing nationality , etc. this device can be used for all other means of authentication , it is only one device . The holder will be authenticated.
