OIDF – EAP Use Cases
OIDF – Enhanced Authentication Profile (EAP) Use Cases
Wednesday 4D Convener: Annabelle Bachman & Mike Jones
Notes-taker(s): Paul Madsen
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Mike Jones described the value proposition
Good things coming out of IETF - Token Binding specifies how applications can bind tokens to particular TLS sessions. Can prevent cookie/token replay - mitigate risk of bearer tokens
Dirk Balfanz @ Google implemented an earlier version of this for Chrome
The first deliverables for EAP is to write a description for how to do token binding for an OIDC id_token, to prevent an id_token from being represented
basic idea is you put a reference to the public key of the TLS into the id_token so that the Client can confirm the token is being presented over the right TLS channel
a second deliverable of the EAP is to allow an
- the OIDC RP to signal to the OP that it desires 'phishing resistant authentication'
- the OP to signal that it did indeed do so, and some level of detail
The WG will need to specify how the RP can best direct the OP
Dick asked whether the OP being able to prove that it actually performed a specific authentication was in scope. Mike said 'perhaps'.
Dick told the minute taker to 'fuck off'
Justin drew out the OIDC triangle, asking to which channel the id_token is bound. Brian responded that it is bound to the channel between the UserAgent & the Client - regardless of whether
the id_token is presented over that channel (or not)
Justin asked for clarification on the scope of the authentication - is in scope where the OIDC RP might be doing its own strong authn, in addition to accepting the id_token?
Mike responded that his assumption was that the OIDC OP would be doing the strong authn.
Annabelle pointed out that the other mechanisms exist as an alternative to Token Binding with the same security characteristic of mitigating token theft, ie PoP etc. John referred to the HTTP
Signing spec, a different Proof of Possession Mechanism. Lots of grumbling about OAuth 1 and MAC spec.
Dick asked whether these two deliverables were independent and whether there could be value in combining them - ie the FIDO keys could be used in the token binding of the id_token.
John said the WG would be looking at that.
Mike explained how the Token Binding worked for federation, specifically that the OP can mint a token that is bound to a TLS channel that the OP doesn't participate in
Dick posed question "what do we mean by 'strong' authentication?" or what do we mean by 'phishing resistant'? etc etc
Consensus seemed to be that we should talk in terms of the resultant security characteristics, rather than LOA or specific mechanisms
