FAPI CIBA Profile

[Dave Tonge]

We've recently started the implements draft review process for OpenID Connect Client Initiated Backchannel Authentication Core: http://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html

I've updated the FAPI CIBA profile to be based of the new draft. The changes we made to the core CIBA profile have enabled me to remove most of the FAPI specific clauses that we had.

I will create some separate issues that I believe need discussion. The PR is here: https://bitbucket.org/openid/fapi/pull-requests/86/rework-of-the-fapi-ciba-draft/diff

[Freddi Gyara]

Dave,

This is such a significant uplift on the earlier MODRNA draft!!

Here are a few inputs on both the core side of things and the FAPI side of things:

For the Core Draft - Why is the Grant Type namespaced to modrna if we have moved this up to OIDC core ?

OpenID Provider Metadata - Why is this required ONLY for ones supporting ping and poll ? Why not for push ? - Why is there no registration token for login_hint_token_signing_algorithms_supported

For FAPI

1. Do we need to re-assert that backchannel_authentication_request_signing_alg_values_supported should be ES256 or PS256 ?

2. We should state that we should always use login_hint_token and not login_hint OR always used signed authentication request

3. Should we extend the requirements around request objects to the authentication request ? Do we have a preference to express over auth request with request object or signed authentication request ? I really like the belts and braces that are provided by the exp and jti claims provided by the signed authentication request - and that could help mitigate a number of unseen issues.

4. binding_message - could we do some work on improving this. There are a number of types of bindings that would be useful and we could investigate: - two way binding - where the AD and CD are both bound to each other for a short period of time - binding through NFC/scanned bar code rather than relying on a human

[Dave Tonge]

Thanks Freddi.

I've opened up an issue for the core queries you had: https://bitbucket.org/openid/mobile/issues/147/ciba-queries-from-fapi

For the FAPI questions:

1. I suppose we could iterate this, referring to 8.6 in FAPI RQ
2. I don't think we need to do this. If the whole request is signed, then is there any additional benefit to having the hint signed as well?
3. So the signed authentication request in CIBA is instead of a request object. We decided that we couldn't just re-use the definitions of the request object as it was very much intended for front-channel usage, so we (mainly Brian :-)) defined the signed authentication request for CIBA. So I think the answer is: request object for front-channel, signed auth request for back channel. Both are JWTs with similar purposes and claims.
4. I agree we should discuss this - I'll open a separate issue for it.

[Brian Campbell]

from http://lists.openid.net/pipermail/openid-specs-fapi/2019-January/001218.html:

Should we require the use of login_hint_tokens rather than just login_hints.

I don't think there's reason enough to require the use of login_hint_tokens.

[Dave Tonge]

I've opened this PR: https://bitbucket.org/openid/fapi/pull-requests/88/re-iterate-algorithm-considerations/diff to re-iterate the algorithm considerations.

[Dave Tonge]

Merged in dgtonge/fapi/fapi-ciba-edits (pull request #88)

Re-iterate algorithm considerations

Addresses issue #198

→ <<cset 969c5d99cf8b>>

[Dave Tonge]

I've merged the PR and will now close this issue