Phil, would you clarify what you are suggesting? I'm unclear if you are disagreeing with George or not.
On Thu, Nov 8, 2018 at 4:28 AM Phil Hunt <phil.h...@oracle.com> wrote: > I’m seeing broader need for discovery of OAuth infrastructure for APIs in > general now that APIs are being deployed by many parties: > * based on a standard (e.g. SCIM, IMAP, SMTP) > * Implemented in open source and deployed by many (e.g. K8S and its > various components). > * Services like streaming (Kakfa) > * Serverless/microservices APIs > > I agree, that having some process where the RS can indicate to a client > where to go do discovery would be helpful. The issue is somewhat complex > and we have talked about some of this before. For example, an RS may have > multiple AS’s it accepts tokens from. Does the RS indicate many or specific > discovery endpoint that may or may not involve registration (in order to > determine the appropriate AS)? How is the metadata secured? How do we > ensure we haven’t opened up an automated attack point (e.g. a MITM’d RS > gives a client false discovery information). > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.h...@oracle.com > > On Nov 7, 2018, at 1:08 PM, George Fletcher < > gffletch=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 listOAuth@ietf.orghttps://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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
