[Openid-specs-fapi] FAPI certification testing for refresh tokens

Filip Skokan panva.ip at gmail.com
Fri Jun 28 15:21:07 UTC 2019


If the OP has a custom policy for deciding whether to issue a refresh token
you can't always mandate they issue them to the tool which may not fall
under that policy. The only thing testable for conformance and
interoperability's sake would be if the server indicates offline_access
scope and refresh_token grant type support, in which case you can mandate
the tester whitelist this grant for the tested client and you can then test
section 11 of Core.

Going beyond this would be creating a profile of your own.

S pozdravem,
*Filip Skokan*


On Fri, 28 Jun 2019 at 17:13, Joseph Heenan <joseph at authlete.com> wrote:

> Hi Filip,
>
> Refresh tokens in general.
>
> Specifically some/many UK banks issue them without scope=offline_access.
> FAPI certification also doesn’t currently require the user info endpoint is
> supported, though I believe core certification requires this.
>
> (I suspect the desire to issue refresh tokens is related to a desire to
> not have to support revoking access tokens - i.e. that short lived access
> tokens that can be refreshed mostly removes the need to ever revoke an
> access token, but I could be wrong.)
>
> Joseph
>
>
> On 28 Jun 2019, at 15:41, Filip Skokan <panva.ip at gmail.com> wrote:
>
> Hi Joseph,
>
> can you clarify if you're talking about refresh tokens in general or the
> scope offline_access + prompt consent condition of OIDC?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Fri, 28 Jun 2019 at 16:29, Joseph Heenan <joseph at authlete.com> wrote:
>
>> Hi FAPI WG,
>>
>> A question has arisen about exactly how refresh tokens should be tested
>> in the FAPI-RW conformance suite (tests for this are currently being
>> written, a suggestion Dave Tonge originally made as many banks in the UK
>> ecosystem are able to issue refresh tokens, and I presume in some cases not
>> correctly...).
>>
>> As support of refresh tokens is entirely optional in FAPI, the question
>> is essentially: “what should happen if the AS doesn’t issue a refresh
>> token?”
>>
>> The options seem to be:
>>
>> 1) The test is marked as passed (I’m not in favour of this option as it
>> may well be that the tester has accidentally registered the clients without
>> the refresh token grant)
>>
>> 2) The test fails if the discovery document indicates the server supports
>> refresh tokens (on the grounds that it indicates that the client has been
>> wrongly configured and if the server supports refresh tokens they
>> conformance suite must be able to test them - note that discovery is also
>> optional in FAPI-RW, though I’m questioning whether this should be the
>> case:
>> https://bitbucket.org/openid/fapi/issues/239/fapi-part-2-should-mention-require
>> - the counter argument is that potentially ASs may support refresh tokens
>> but only for non-FAPI-RW use cases)
>>
>> 3) Same as ‘2’ but make it a warning instead of a failure (essentially
>> suggesting that it may be okay but certificatee should be able to give a
>> good reason why refresh tokens aren’t issued in their server when FAPI-RW
>> is in use)
>>
>> 4) The test is marked as “not testable” or some similar phrase, probably
>> resulting in a similar conversation as for ‘3’.
>>
>> Does anyone have any thoughts please?
>>
>> Thanks
>>
>> Joseph
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20190628/64bc63c3/attachment.html>


More information about the Openid-specs-fapi mailing list