Hmmm. But the Link-header is the generalized discovery method which is pretty widely used outside of OAuth community with the added benefit of being able to find things without linking to authentication.
From: OAuth <[email protected]> On Behalf Of George Fletcher Sent: Friday, November 09, 2018 12:12 AM To: Dick Hardt <[email protected]>; [email protected] Cc: [email protected] Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
