The need is in the distributed OAuth draft, which has more detail of its use case. The problem with using either the token or authorization endpoint as the sole identity of the auth server is that Oauth doesn’t stick to just one of them and there’s no solid way to tie them together apart from AS discovery.
— Justin On Nov 6, 2018, at 12:35 AM, David Waite <da...@alkaline-solutions.com<mailto:da...@alkaline-solutions.com>> wrote: 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<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 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
