Dick, I was generally agreeing with George and stating I think we have an emerging *general* OAuth2 discovery problem emerging.
Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Nov 8, 2018, at 7:11 AM, George Fletcher > <gffletch=40aol....@dmarc.ietf.org> wrote: > > Cool! Sorry I couldn't make the meeting. One benefit of using > WWW-Authenticate is that UMA has basically the same discovery logic (from RS > to AS) and uses the WWW-Authenticate header. Keeping this discovery method > the same (since UMA is just a profile of OAuth anyway) will help all > developers. > > On 11/8/18 5:16 AM, Dick Hardt wrote: >> George: in the WG meeting we discussed this topic of where to put the >> discovery information. No one at the meeting advocated for using Link >> response (Nat was the one who was advocating for this). Many others >> preferred using the www-authenticate header similar to how you propose. >> >> On Thu, Nov 8, 2018 at 4:08 AM George Fletcher >> <gffletch=40aol....@dmarc.ietf.org <mailto:40aol....@dmarc.ietf..org>> wrote: >> Related to this discussion of AS discovery... what is the value of using the >> Link response header over just returning the variables in the >> WWW-Authenticate header? Could we not use... >> >> WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", >> error="invalid_token", rs_uri="https://api.example.com/resource"; >> <https://api.example.com/resource>, >> as_uri="https://as1.example.com,https://as2.example.com"; >> <https://as1.example.com,https//as2.example.com> >> >> Thanks, >> George >> >> On 11/6/18 12:19 AM, Justin P Richer 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 >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
