Write spec should only support confidential clients

[Dave Tonge]

In order to progress the write spec, I suggest that we remove support for public clients and remove (or make optional) token binding.

[Nat Sakimura]

I am not sure of removing public clients. I am fine with Token Binding being optional as long as there are other HoK mechanism, e.g., embedding the client's keyhash in the JWT access token. I have even got an expired draft for it :-) https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06

[Sascha Preibisch]

Removing public clients will be a problem. I deal with banks as customers and they are all going mobile.

[Dave Tonge]

As discussed, there are 2 main use cases for FAPI:

1. A FI or service provider using the standard for its own applications and services
2. A FI or service provider using the standard to provide an API to third parry applications and services

For option 1, public clients make sense as a bank may want to use the spec for its own mobile apps

For option 2, public clients make sense for stand alone software that doesn't depend on a server, e.g. a non-cloud piece of accounting software.

I've made an attempt at documenting these use cases in the intro: https://bitbucket.org/openid/fapi/pull-requests/14/first-attempt-at-the-intro-to-the-fapi/diff

[Dave Tonge]

Change made to the introduction