As I said in the meeting, I think this is an interesting idea that is worth exploring.
I don’t think we need to resolve this for WG adoption of the document. On Sat, May 15, 2021 at 8:36 AM Filip Skokan <[email protected]> wrote: > Hello Vittorio, Brian, everyone > > This is a followup to my feedback in the TMI BFF interim meeting on April > 26th where I mentioned I'd bring this to the list for discussion. > > I proposed an alternative to using fixed endpoint locations and/or > discovery. HTML <meta> Tags <https://www.w3schools.com/tags/tag_meta.asp>. > > These would be in the returned page HTML's head tag, e.g. > > <meta name="oauth-bff-token" content="/api/bff-token"> >> <meta name="oauth-bff-sessioninfo" content="/api/bff-sessioninfo"> > > > The javascript SDK handing TMI BFF would know to look for these defined > meta tags to source the location of the different endpoints. I think this > could be the primary place an SDK would look at as it doesn't require any > upfront external requests. > > For the SDK this is as simple as > > var bffTokenPath = >> document.querySelector('meta[name="oauth-bff-token"]').content; > > > If this was the only mechanism defined by the document (to be bashed) I > think it can save the group a lot of time defining a client discovery > document which would be otherwise needed. If discovery as an alternative > solution is indeed inevitable, it can be a second in line mechanism the > javascript SDK would know to use. > > As discussed in the interim, a well known set of endpoints (or even a > single root client discovery document) might not always be available for > control to the webpage depending on where and how it is hosted, on the > other hand the HTML it serves always, I hope, is. > > Best, > *Filip Skokan* > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
