Since I brought this up initially, I want to re-voice my support for a general
mechanism. I think it makes sense to have something that all of the OAuth
JSON-spouting endpoints (introspection, token, revocation, registration,
discovery) can use to universally put out signed and/or encrypted JWTs
Would it make sense for these to be a different client_auth_method entirely?
Much the same way that we have private_key_jwt and client_secret_jwt today,
both of which use the JWT assertion framework but have very different keying
and security assumptions. In the same way, here you’re still valid
entity, rather than the issuer (since now the metadata might not be
from an authoritative location)
-DW
On Nov 5, 2018, at 10:19 PM, Justin P Richer
mailto:jric...@mit.edu>> wrote:
In the meeting tonight I brought up a response to the question of whether to
have full URL or plain issuer
In the meeting tonight I brought up a response to the question of whether to
have full URL or plain issuer for the auth server in the RS response’s header.
My suggestion was that we have two different parameters to the header to
represent the AS: one of them being the full URL (as_uri) and one o
