Hi! Sorry for the delayed answer!
> > Okay, that's good to know. But I'm still missing how the end user (a > human) trusts that magic CA within the browser or device they use to > finish the actual flow? More than the end user "trusting" a "magic" CA, it's about what company will tell you to use a CA, most of the time you don't have option as a developer or even as a sysadmin since these kind of things are coming strictly from InfoSec departments or are just some instruction to accomplish some certification like ISO9001 or ISO27001, which for isolated environments are required to be CA managed internally, and must of the times the users may not see this CA, this will be actually pushed by another external application installed in the company workstation like CrowdStrike does, I'm not saying this will be the case, but it's an example of how companies work now days with the CA's > > > Same question as above, but I'm slowly being convinced that this > thread needs to remain separate from the PGOAUTHDEBUG split > discussion, even if they're related. Totally agree, now I'm thinking the same, it should be a feature because there's more examples that I've been thinking about that may require this to be even a bit more flexible, for example, when working with edge computing, if you want (in the future because now it's not possible, yet) authenticate a device against PostgreSQL it may require to have that CA as a encoded string int he variable, not just as a file, wild thought I know, but it may make sense > This might be a silly-small example, but I've added a stub spec: > > > https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature > How can we work on that? because of the above it may be required to add even more possibilities. > > > Who's running the CI, and how do OAuth and Device Authorization > factor > into it? (And why would a human user be okay with feeding their > privileges into an authorization server with a random-looking host > name every time they run it?) > With that I was thinking more in the future than what you can do now, the OAuth flow provides many features that can be implemented in the future and I was just looking ahead with the CI example. > > > The reason I ask is that we'd briefly talked about splitting > > > PGOAUTHDEBUG into more granular settings than just "off" and > > > "UNSAFE". > > > > I was thinking the same for another patch that will require > > discussion > > for sure, but it's something similar to add some levels of debug, > > for > > example, when you want to have the tokens or when you only want to > > see > > the URLs used to negotiate (which are really useful when working > > with > > the OAuth flows) or the deep one when you want to see the tokens. > > I think that's reached critical mass, then. > More than happy to help with this! --
