Is there a need for a client to understand the identity of an authorization server?
This would seem to mean that the token or authorization endpoint would need to be that identity, 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 <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 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 of them > being the issuer to be constructed somehow (as_issuer). I ran into a similar > problem on a system that I built last year where all of our servers had > discovery documents but not all of them were easily constructed from an > issuer style URL (using OIDC patterns anyway). So we solved it by having two > different variables. If the full URL was set, we used that; if it wasn’t, we > tried the issuer; if neither was set we didn’t do any discovery. > > I’m sensitive to Torsten’s concerns about complexity, but I think this is a > simple and deterministic solution that sidesteps much of the issue. No pun > intended. > > — Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
