[saag] Re: Covert Web-to-App Tracking via Localhost

Michael Richardson <[email protected]> Thu, 05 Jun 2025 12:15:36 -0400
Newsgroups	gmane.ietf.saag
Message-ID	<[email protected]>
Nico Williams <[email protected]> wrote:
    > 1) as you say SAML/Oauth2/Webauthn/etc. are a mess, and they're not
    > universally supported,

It creates a level of trust in the JS which is unnecesary.
The storey of going from brower/JS to http(api) mechanisms is getting
better.  MH, which is not a browser based MUA, can now get get a token for
logging into GMAIL with OAUTH2.  It invokes a browser to do this, and then
stores the result in ~/Mail/oauth-gmail.  (Yes, mode 400. I spent ten minutes
finding the file)

Many properties require that in order to do things, that the client needs a
secret or API key, and this often means that you have to have an APP or a
closed source application, because the secret has to be kept secret.
This is why mhlogin only can do POP3, not IMAP, because google realized this
was a problem (I guess), and this was the compromise.

It's not that those things are such a mess so much as that the browser
focused ecosystem precludes better/simpler things.

****
Again, the connection to the first post is that people are forced to load an
app, because of the need for this app-specific key.   This really bites when
you want to do an open source app that also uses, for instance, Google Firebase.
****

What I would like is to be able to use a self-signed
certificate/RawPublicKey/{alg-none even}.  And then I want to authorize that
key easily on the "server".  Make it even easier than ssh keys.  (Which for
many so-called "IT" people are still a mystery, I notice)
But I would say that .ssh/authorized_keys was the major, killer-feature, that
made ssh win where stelnet/telnet-ssl/ktelnet/etc. lose.  It never scaled to
the large, but as I often say, "scaling" doesn't mean "can go big", it means,
"supports both small and big".  So I claim Kerberos does not scale: as in,
it's still too hard to make it small.

    > [*] With any authen. system where the supplicant possesses private/
    > secret key material and they have to use a proof-of-possession protocol
    > you end up wanting hardware token support and being sad that you can't
    > get it or that it's too slow, so you end up having to orchestrate
    > short-lived credentials that use software keys instead or in addition
    > to possibly-longer-lived hardware ones.  But if you do that

Yes.  RFC9060 and RFC9345 are useful here.
I am still annoyed we have both.

    > Yes, I agree fully.  Channel binding was an attempt to bridge that gap,
    > but it was still too big a chasm.

It's funny that Nico and I are involved in this thread, given that we did
RFC 5060 and 5386.

    > You're probably using OIDC though, not JWT.  Or you're using JWTs w/o
    > an `aud` claim.  To my knowledge Chrome, FF, etc. do not know how to
    > fetch Bearer tokens.  They know only how to chase redirects (or do
    > Negotiate, i.e. Kerberos), and the redirect workflows are SAML and
    > OIDC, not plain JWT.

I have no idea how I'd ever do even a self-audit on all the tokens that I
have.  It should all be built-in to the browser, and it's not really.

    > Yes, well, we could extend IMAP and SUBMIT to handle JWTs.  Has no one
    > done this work?  And then it needs to be implemented in the MUAs.

I don't know much about the JMAP WG, (IMAP using JSON), but I suspect that it
might support JWTs.

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 515 B)