<div dir="ltr"><div>Hi Joseph,</div><div><br></div><div>can you clarify if you're talking about refresh tokens in general or the scope offline_access + prompt consent condition of OIDC?</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 28 Jun 2019 at 16:29, Joseph Heenan <<a href="mailto:joseph@authlete.com">joseph@authlete.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi FAPI WG,<br>
<br>
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...).<br>
<br>
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?”<br>
<br>
The options seem to be:<br>
<br>
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)<br>
<br>
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: <a href="https://bitbucket.org/openid/fapi/issues/239/fapi-part-2-should-mention-require" rel="noreferrer" target="_blank">https://bitbucket.org/openid/fapi/issues/239/fapi-part-2-should-mention-require</a> - the counter argument is that potentially ASs may support refresh tokens but only for non-FAPI-RW use cases)<br>
<br>
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)<br>
<br>
4) The test is marked as “not testable” or some similar phrase, probably resulting in a similar conversation as for ‘3’.<br>
<br>
Does anyone have any thoughts please?<br>
<br>
Thanks<br>
<br>
Joseph<br>
<br>
</blockquote></div>