Am 12.10.22 um 19:07 schrieb Hollenbeck, Scott:
For the token revocation RFC 7009 can be used as-is, all we'd need to
specify
would be the path segment like farv1_token_revocation and add signalling if
the RDAP server supports it or not in the /help response.
[SAH] 7009 describes the interaction with the Authorization Server. I assume
the RDAP client would send the refresh token via POST as described above, and
then the RDAP server submits the 7009 revocation request to the authorization
server - right?
Important factor here is that the document shall leave it open whether
the tokens are issued by the OP or the RDAP server.
The tokens are opaque to the client and this is up to the implementation
of the RDAP server to forward the tokens from the OP, to exchange them
or generate own.
From this perspective also the revocation end-point shall be offered by
the RDAP server as only RDAP server would know what to do to revoke the
token according to the own implementation.
To keep the solution more flexible we may signal the revocation
end-point as an URL in the /help path, not as a fixed one.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
