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
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
