Am 13.10.22 um 14:24 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.
[SAH] I'm still not following. To revoke a token, the RDAP server needs to know who 
issued it (so the revocation endpoint can be found), and it needs the token itself.  How 
does the RDAP server acquire both if all it receives from the client is a path segment 
like farv1_token_revocation? A "default" OP can address the first need, but a 
token still needs to be included in the revocation request.

[PK] Yes, you are right, in order to know which OP shall receive the revocation request it has to happen within the same session, so the path shall be under /farv1_session path so that RDAP server knows the context. The token is submitted with the request as in RFC 7009 - this is a POST request with "application/x-www-form-urlencoded" parameters - token and an optional token_type_hint. This covers the second issue.

Kind Regards,

Pawel

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to