Remove references to OAuth Token Binding

[Dave Tonge]

We discussed on the call today removing references to OAuth Token Binding from the specs.

This is because currently there aren’t interoperable implementations of this yet, we are likely to add support in later when the spec starts to be used.

We discussed that it would be good to indicate that in the future we will support other methods for sender-constraining tokens, e.g. DPOP. However we need to balance this with the aim of achieving interoperability.

I will propose some wording around this.

[Dave Tonge]

We discussed on the call today removing references to OAuth Token Binding from the specs.

This is because currently there aren’t interoperable implementations of this yet, we are likely to add support in later when the spec starts to be used.

We discussed that it would be good to indicate that in the future we will support other methods for sender-constraining tokens, e.g. DPOP. However we need to balance this with the aim of achieving interoperability.

I will propose some wording around this.

[Joseph Heenan]

Hope you don’t mind Dave, I’ve had a go at some wording along the lines you suggested and put it in a pull request here: https://bitbucket.org/openid/fapi/pull-requests/117/fapi-rw-make-mtls-the-only-holder-of-key

[Dave Tonge]

Thanks Joseph

[Dave Tonge]

FAPI-RW: Make MTLS the only holder of key mechanism

At the present time, OAuth Token Binding has not been widely deployed, so in the interests of interoperability it is better to focus implementors attention on MTLS certificate bound access tokens at the current time - MTLS has been used in many FAPI deployments.

This situation is likely to change again in later drafts if other methods of sending constraining tokens are developed.

closes #225

→ <<cset aab212e71cc0>>