OAuth Virtual Interim Meeting - 14.09.2026

Welcome and Agenda Bashing

Rifaat and Hannes welcome the group. Rifaat announces this virtual
interim meeting series.

HTTP Message Signatures for OAuth

https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/

Justin gives the presentation and mentions his prior work on HTTP
signature work, for which a playground implementation exists as well:
https://httpsig.org/

Justin explains how HTTP signature work. The actual signature consists
of two parts, the Signature-Input and the Signature parameter. Allows to
carry multiple signatures in a message.

HTTPSig does not tell you where to get the keys from.

How to apply to HTTPSig to OAuth? Decisions described in the
OAuth-HTTPSig draft.

A few design decisions:

• What do sign? Authorization Header, Method, Target URI, something
  else?
• What keys to use? At registration time and/or at runtime
• How to request a token? key id for identifying a pre-registered key,
  public key for runtime usage

There are several open issues, listed in the draft.

Justin talks about the relationship to the DPoP RFC. There is no point
in discussing the open issues before an adoption call.

Yaroslav: Great work. This is a really large problem space and it is
better not to do everything in a single draft. There is an overlap with
DPoP and there is a question whether it deprecates DPoP eventually.

Justin: I do not believe it deprecates DPoP because there are
deployments, which are JSON/JOSE heavy.

Christian: I do not believe the goal is to replace DPoP. It provides
other features than DPoP. A feature I like is the ability to protect the
payload of the message.

Pieter: Similar comment. I would be careful about deprecation. It solves
different classes of problems. We should not discourge people from using
tools, which are already available.

Brian: I have not heard these use cases that justify the new mechanism.
There is already more than one mechanism and it feels like an
unnecessary thing.

Rifaat: Maybe we should talk a bit more about the use cases. Forget the
details. People got the idea. What are the use cases that are not
covered yet.

Justin: We have seen proposals in the group that ask features to be
added to DPoP, such as body protection and protection of more header
fields. I think we should tie the mechanism to an already existing
mechanism, like HTTPSig.

Yaroslav: Use case proof-of-possession for refresh tokens.

Brian: How do you expect that badly implemented clients will get this
right? Justin has done a great job to get the work on HTTP message
signature right. It is not simple --- it is complicated. May AI will
solve this. I have not heard about meaningful reasons for wanting body
protection or inclusion of other header fields. I do not understand the
real requirement.

Justin: The reason is (a) that some APIs require the protection of
different parts of the message and (b) how do we expect people to get
this right. How do we expect people to get DPoP plus extensions right?
I see your concerns but I draw different conclusions.

Aaron: The implemention difficulty is definitely high. It is not easy.
This is exactly the point of doing it. I think that this can be done at
the HTTP layer. You, as a developer, no longer write any of the HTTP
parts. This makes it sufficiently easier to use as a developer. This
allows us to push this difficulty to a different layer where app
developers will not see it.

Filip: I would like to draw a relationship to mTLS. We are not
implementing the complicated mTLS parts and we rely on the TLS library
to do this.

Christian: Aaron made a few remarks already. I am new to HTTPSig and I
was surprised to see how easy it was to use it. Based on the tools we
have available, this is the least messy.

Michael: If there is a conflict between DPoP and this mechanism, is
there guidance on what superseeds what.

Justin: This is a great question. Nothing in HTTP stops you from sending
both header parameters in both version. I do think that this would be an
error state where two public keys are used in a single message.

Filip: I think that this is already covered as an error case.

Dick: I am excited to see the use of HTTPSig work in OAuth. You did a
great job in addressing the challenges. This has been working well and
we have using this mechanism in WebBotAuth and also in AAuth. It
interops pretty well. I proposed the signature key spec in HTTP, and
other work in WebBotAuth and then in the email verification work. It
would be more useful to have it more generically applicable. Why does
OAuth need somethig specific rather than a more generic mechanism?

Justin: The key distribution problem is one of the most difficult
aspect. The association of the key to the right software is essential.
We are saying that in OAuth there are different places where we can
introduce a key. I have posted at length at the signature key spec on
the HTTP mailing list.

Dick asks whether there is a possibility to generalize the mechanism.
Hannes briefly summarizes the commonality with ACME and the differences.

Aaron: Having client identity with HTTP Signatures is useful but this
should be an open issue in the draft. It feels like a different problem
but still useful.

Dick: When you use the word client I do not just think about OAuth
client.

Aaron: I agree this is a useful thing but it feels like a different
document.

Rifaat & Hannes: We should get feedback from the group.

Rifaat is entering a poll: 10 (yes), 3 (no), 2 (no opinion)

Dick believes that the case of authenticating the client should go into
a separate document.