There is a requirement in Distributed OAuth for the client to locate one or more AS metadata files for a given resource.
On Tue, Nov 6, 2018 at 12:35 PM David Waite <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> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
