Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 6 Oct 2021 17:01:38 -0400

All,

As a followup on the interim meeting today, this is a *call for adoption *for
the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft as
a WG document:
https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/

Please, provide your feedback on the mailing list by* October 20th*.

Regards,
 Rifaat & Hannes

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 6 Oct 2021 14:03:59 -0700

I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <[email-masked]>
wrote:

> the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
> as a WG document:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 6 Oct 2021 14:08:44 -0700

I am not supportive of adoption of this document at this time.

I am supportive of the concepts in the document. Building upon existing,
widely used, proven security mechanisms gives us better security.

HTTP Sig looks very promising, but it has not been adopted as a draft, and
as far as I know, it is not widely deployed.

We should wait to do work on extending HTTP Sig for OAuth until it has
stabilized and proven itself in the field. We have more than enough work to
do in the WG now, and having yet-another PoP mechanism is more likely to
confuse the community at this time.

An argument to adopt the draft would be to ensure HTTP Sig can be used in
OAuth.
Given Justin and Annabelle are also part of the OAuth community, I'm sure
they will be considering how HTTP Sig can apply to OAuth, so the overlap is
serving us already.

/Dick

ᐧ

On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <[email-masked]> wrote:

>> As a followup on the interim meeting today, this is a *call for adoption
>> *for the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
>> as a WG document:

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Oct 2021 17:20:54 -0400

> HTTP Sig looks very promising, but it has not been adopted as a draft

Just to be clear, the HTTP Sig draft is an official adopted document of the HTTP Working Group since about a year ago. I would not have suggested we depend on it for a document within this WG otherwise.

 — Justin

> On Oct 6, 2021, at 5:08 PM, Dick Hardt <[email-masked]> wrote:
> 
> I am supportive of the concepts in the document. Building upon existing, widely used, proven security mechanisms gives us better security.
> 
> HTTP Sig looks very promising, but it has not been adopted as a draft, and as far as I know, it is not widely deployed.
> 
> We should wait to do work on extending HTTP Sig for OAuth until it has stabilized and proven itself in the field. We have more than enough work to do in the WG now, and having yet-another PoP mechanism is more likely to confuse the community at this time.
> 
> An argument to adopt the draft would be to ensure HTTP Sig can be used in OAuth.
> Given Justin and Annabelle are also part of the OAuth community, I'm sure they will be considering how HTTP Sig can apply to OAuth, so the overlap is serving us already.
> 
> /Dick
> 
> 
> ᐧ
> 
> On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
> All,
> 
> As a followup on the interim meeting today, this is a call for adoption for the OAuth Proof of Possession Tokens with HTTP Message Signature draft as a WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ <https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/>
> 
> Please, provide your feedback on the mailing list by October 20th.
> 
> Regards,
>  Rifaat & Hannes
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Oct 2021 17:24:35 -0400

As author of the document and proposer of the work, I support its adoption. :)

 — Justin

> On Oct 6, 2021, at 5:01 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> All,
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 6 Oct 2021 14:24:46 -0700

I meant it is not yet adopted as an RFC.

To be clear, I think you are doing great work on the HTTP Sig doc, and a
number of concerns I have with HTTP signing have been addressed => I just
think that doing work in the OAuth WG on a moving and unproven draft in the
HTTP WG is not a good use of resources in the OAuth WG at this time.

ᐧ

On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <[email-masked]> wrote:

> Just to be clear, the HTTP Sig draft is an official adopted document of
> the HTTP Working Group since about a year ago. I would not have suggested
> we depend on it for a document within this WG otherwise.
>
>  — Justin
>
>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <
>> [email-masked]> wrote:
>>
>>> All,
>>>
>>> As a followup on the interim meeting today, this is a *call for
>>> adoption *for the *OAuth Proof of Possession Tokens with HTTP Message
>>> Signature* draft as a WG document:

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Oct 2021 17:31:54 -0400

Thanks for the clarification, though I certainly disagree with your conclusion.

If you have additional outstanding concerns with the HTTP Sig document, Annabelle and I would welcome your feedback and engagement in HTTP to ensure those are addressed. :)

Thanks,
 — Justin

> On Oct 6, 2021, at 5:24 PM, Dick Hardt <[email-masked]> wrote:
> 
> To be clear, I think you are doing great work on the HTTP Sig doc, and a number of concerns I have with HTTP signing have been addressed => I just think that doing work in the OAuth WG on a moving and unproven draft in the HTTP WG is not a good use of resources in the OAuth WG at this time.
> 
> 
> ᐧ
> 
> On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Oct 6, 2021, at 5:08 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 6 Oct 2021 14:48:16 -0700

This actually seems like a great time for the OAuth group to start working
on this more closely given the relative stability of this draft as well as
the fact that it is not yet an RFC. This is a perfect time to be able to
influence the draft if needed, rather than wait for it to be finalized and
then have to find a less-than-ideal workaround for something unforeseen.

Aaron

On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt <[email-masked]> wrote:

>> HTTP Sig looks very promising, but it has not been adopted as a draft,
>> and as far as I know, it is not widely deployed.
>>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 6 Oct 2021 14:55:12 -0700

Remember token binding? It was a stable draft. The OAuth WG spent a bunch
of cycles building on top of token binding, but token binding did not get
deployed, so no token binding for OAuth.

As I mentioned, I think Justin and Annabelle (and anyone else interested)
can influence HTTP Sig to cover OAuth use cases.

/Dick

ᐧ

On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <[email-masked]> wrote:

>>> Given Justin and Annabelle are also part of the OAuth community, I'm
>>> sure they will be considering how HTTP Sig can apply to OAuth, so the
>>> overlap is serving us already.
>>>
>>> /Dick
>>>
>>>
>>> ᐧ
>>>

---

From: Denis <[email-masked]>
Date: Thu, 7 Oct 2021 11:03:12 +0200

I am not supportive of adoption of this document by the WG /at this time/.

As I said during the last interim meeting, at this time, there is no 
security considerations section, nor a privacy considerations section.

The current draft describes a mechanism but does not state how the 
signing key will be established and / or come from.

 From a security considerations point of view, if the client has the 
control of the private key, it might be able to voluntary transmit
the private key to another client in order to mount a client 
collaborative attack. If the client is unable to transmit the private key
to another client in order to mount a collaborative attack, it might be 
able to perform all the cryptographic computations that
the other client needs. It is important to state which protections (or 
detection) features will be obtained as well as which protections
(or detection) features will not be obtained. A top-down approach is 
currently missing.

 From a privacy considerations point of view, if the same public key is 
used to sign the messages whatever the RS is, this will allow
different RSs to link the requests from the same client. It is important 
to state which protections (or detection) features will be obtained
as well as which protections (or detection) features will not be obtained.

Let us wait to have both the security considerations section and the 
privacy considerations section written,
before adopting this draft as a WG document.

Denis

> Remember token binding? It was a stable draft. The OAuth WG spent a 
> bunch of cycles building on top of token binding, but token binding 
> did not get deployed, so no token binding for OAuth.
>
> As I mentioned, I think Justin and Annabelle (and anyone else 
> interested) can influence HTTP Sig to cover OAuth use cases.
>
> /Dick
> ᐧ
>
> On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This actually seems like a great time for the OAuth group to start
>     working on this more closely given the relative stability of this
>     draft as well as the fact that it is not yet an RFC. This is a
>     perfect time to be able to influence the draft if needed,
>     rather than wait for it to be finalized and then have to find a
>     less-than-ideal workaround for something unforeseen.
>
>     Aaron
>
>     On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         To be clear, I think you are doing great work on the HTTP Sig
>         doc, and a number of concerns I have with HTTP signing have
>         been addressed => I just think that doing work in the OAuth WG
>         on a moving and unproven draft in the HTTP WG is not a good
>         use of resources in the OAuth WG at this time.
>
>
>         ᐧ
>
>             Just to be clear, the HTTP Sig draft is an official
>             adopted document of the HTTP Working Group since about a
>             year ago. I would not have suggested we depend on it for a
>             document within this WG otherwise.
>
>              — Justin
>
>>             On Oct 6, 2021, at 5:08 PM, Dick Hardt
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             I am supportive of the concepts in the document. Building
>>             upon existing, widely used, proven security mechanisms
>>             gives us better security.
>>
>>             HTTP Sig looks very promising, but it has not been
>>             adopted as a draft, and as far as I know, it is not
>>             widely deployed.
>>
>>             We should wait to do work on extending HTTP Sig for OAuth
>>             until it has stabilized and proven itself in the field.
>>             We have more than enough work to do in the WG now, and
>>             having yet-another PoP mechanism is more likely to
>>             Given Justin and Annabelle are also part of the OAuth
>>             community, I'm sure they will be considering how HTTP Sig
>>             can apply to OAuth, so the overlap is serving us already.
>>
>>             /Dick
>>
>>
>>             ᐧ
>>
>>             On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef
>>                 <[email-masked]
>>                 <mailto:[email-masked]>> wrote:
>>
>>                     All,
>>
>>                     As a followup on the interim meeting today, this
>>                     is a *call for adoption *for the *OAuth Proof of
>>                     Possession Tokens with HTTP Message
>>                     <https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/>
>>
>>                     Please, provide your feedback on the mailing list
>>                     by*October 20th*.
>>
>>                     Regards,
>>                      Rifaat & Hannes
>>
>>                     <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>                 <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>             <https://www.ietf.org/mailman/listinfo/oauth>
>
>

---

From: Warren Parad <[email-masked]>
Date: Thu, 7 Oct 2021 12:08:16 +0200

I do not support adoption.

While I love the idea to be able to restrict the usage of the access token
by the client, enabling longer expiry access tokens, and preventing usage
to perform unexpected actions with that token, the reasons I do not support
the adoption are as follows:

* The draft depends on another draft and personally not one that I even
agree with. Saying that the "draft is officially adopted" doesn't justify
depending on it.
* I reject the use of an additional header to transmit additional
authorization information. Due to the nature of this information may be
conveyed and stored throughout a number of systems which would all need
access to this complexity. As headers and authorization evolves the
introduction and replacement of existing headers provides additional
security vulnerabilities.
* The draft does not support multiple clients with access to the access
token who all should be able to provide different client signatures and all
be verifiable by the RS.
* This forces the RS to lookup two pieces of information in the case of
signed JWTs, the JWKs from the AS and the JWKs from the client
* The argument in the introduction is flawed

Bearer tokens are simple to implement but also have the significant
> security downside of allowing anyone who sees the access token to use that
> token.

This is not a complete argument because I can replace the words in the
sentence and justify that HTTPSig should never be used by the same argument:

> HTTPSig tokens are incredibly complex to implement but also have the
> significant security downside of allowing anyone who sees the access token
> and signature to use that token.

We need to come up with a better argument such as: *This allows a client to
reduce use of the token to a smaller window to where the signature is also
valid.*
That would allow us to better focus on the value that the RFC would
provide, rather than getting stuck with arbitrary implementation of another
RFC draft as it would apply to OAuth.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Thu, Oct 7, 2021 at 11:03 AM Denis <[email-masked]> wrote:

> I am not supportive of adoption of this document by the WG *at this time*.
>
> The current draft describes a mechanism but does not state how the signing
> key will be established and / or come from.
>
> the private key to another client in order to mount a client collaborative
> attack. If the client is unable to transmit the private key
>> working on this more closely given the relative stability of this draft as
>> well as the fact that it is not yet an RFC. This is a perfect time to be
>> able to influence the draft if needed, rather than wait for it to be
>> finalized and then have to find a less-than-ideal workaround for something
>> unforeseen.
>>
>> Aaron
>>
>>>> I am supportive of the concepts in the document. Building upon
>>>> existing, widely used, proven security mechanisms gives us better security.
>>>>
>>>>>> adoption *for the *OAuth Proof of Possession Tokens with HTTP
>>>>>> Message Signature* draft as a WG document:
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 7 Oct 2021 13:01:47 +0100

Canonicalised signature schemes inevitably lead to cryptographic doom, and should die with SAML (ha!). For that reason I do not support adoption of this draft. 

I also think the arguments for canonicalisation vanish as soon as you want end-to-end confidentiality too.

— Neil

> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> 
> All,
> 

-- 
Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe 
<https://preferences.forgerock.com/>

---

From: Ash Narayanan <[email-masked]>
Date: Fri, 8 Oct 2021 15:05:33 +1100

Oh geez, yesterday was my day off but ended up down a deep rabbit hole
after reading this draft and the ones that came before it.

I do not support adoption and was going to list my reasons but Warren Parad
beat me to it.

In addition to the list he has provided, I'd also like to see the draft
make a mention of public clients; obviously we can't use any sensitive keys
with these.

Regards,
Ash

On Thu, Oct 7, 2021 at 11:02 PM Neil Madden <[email-masked]>
wrote:

> Canonicalised signature schemes inevitably lead to cryptographic doom, and
> should die with SAML (ha!). For that reason I do not support adoption of
> this draft.
>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 7 Oct 2021 21:13:45 -0700

> obviously we can't use any sensitive keys with these

That's not true at all, public clients can use keys that they create
themselves or are issued to a particular instance. That's one of the
reasons we are giving a name to this type of client in OAuth 2.1, a
"credentialed" client.

A public client clearly can't share credentials with other instances of the
public client, but there's no reason they can't use a key that is only ever
known to them.

On Thu, Oct 7, 2021 at 9:06 PM Ash Narayanan <[email-masked]>
wrote:

> I do not support adoption and was going to list my reasons but Warren
> Parad beat me to it.
>
>> Canonicalised signature schemes inevitably lead to cryptographic doom,
>> and should die with SAML (ha!). For that reason I do not support adoption
>> of this draft.
>>
-- 
---
Aaron Parecki
https://aaronparecki.com

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 8 Oct 2021 17:48:13 +0000

I support adoption of this draft as a working group document.

I have seen a few objections due in part to the draft not addressing this or that topic. Bear in mind that this is a call for adoption of a draft; this is not WGLC. It is generally expected that a draft may be far from complete before being adopted. One advantage of adopting an incomplete draft is that it can be further developed within the Working Group, with changes subject to the IETF consensus process.

—
Annabelle Backman (she/her)
[email-masked]<mailto:[email-masked]>

On Oct 6, 2021, at 2:01 PM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

All,

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 8 Oct 2021 18:30:14 +0000

On Oct 7, 2021, at 2:03 AM, Denis <[email-masked]<mailto:[email-masked]>> wrote:
As I said during the last interim meeting, at this time, there is no security considerations section, nor a privacy considerations section.

The current draft describes a mechanism but does not state how the signing key will be established and / or come from.

These items can (and I'd argue should) be addressed within the Working Group. I think key establishment in particular would benefit from a broader discussion than is typically possible with only an individual draft.

if the client has the control of the private key, it might be able to voluntary transmit the private key to another client in order to mount a client collaborative attack.
I assume the private key in question is the one used by the client to generate the message signature? By definition, the client has possession of the client's private key. I would argue that if System A shares their keys and tokens with System B, then for the purposes of OAuth 2.0 both A and B are part of the same client. Constraining client architecture is outside the scope of this draft. It could be interesting to explore this separately, perhaps via a generic "token usage constraints" mechanism.

If the client is unable to transmit the private key to another client in order to mount a collaborative attack, it might be able to perform all the cryptographic computations that the other client needs.
Correct, save that per above I would argue both such systems are part of the same OAuth 2.0 client. Note that it is also the case that this is not really any different from System A accessing RSes at the direction of System B, and sharing results with System B. That is actually a common pattern, e.g., a web application back end (System A) making a request to an RS because the end user clicked a button in the web application front end (System B).

if the same public key is used to sign the messages whatever the RS is, this will allow different RSs to link the requests from the same client.
If correlation across RSes is a concern, then a client must use different access tokens with each RS. It ought to be possible for a client to use a different key for each of these access tokens. This gets into the key establishment topic mentioned above. For my part, I think this is a good example of why the doc should cover key establishment/agreement, and I'd like to see that discussed within the Working Group.

Let us wait to have both the security considerations section and the privacy considerations section written, before adopting this draft as a WG document.
Why make adoption contingent on drafts of each of those sections? I think it would be more effective to develop those within the Working Group, as WG discussions/decisions are likely to have security and privacy implications. (e.g., if key establishment is included in this doc, those sections need to cover that; if it is left out of scope, then they don't need to cover it)

—

On Oct 7, 2021, at 2:03 AM, Denis <[email-masked]<mailto:[email-masked]>> wrote:

I am not supportive of adoption of this document by the WG at this time.

As I said during the last interim meeting, at this time, there is no security considerations section, nor a privacy considerations section.

The current draft describes a mechanism but does not state how the signing key will be established and / or come from.

From a security considerations point of view, if the client has the control of the private key, it might be able to voluntary transmit
the private key to another client in order to mount a client collaborative attack. If the client is unable to transmit the private key
to another client in order to mount a collaborative attack, it might be able to perform all the cryptographic computations that
the other client needs. It is important to state which protections (or detection) features will be obtained as well as which protections
(or detection) features will not be obtained. A top-down approach is currently missing.

From a privacy considerations point of view, if the same public key is used to sign the messages whatever the RS is, this will allow
different RSs to link the requests from the same client. It is important to state which protections (or detection) features will be obtained
as well as which protections (or detection) features will not be obtained.

Let us wait to have both the security considerations section and the privacy considerations section written,
before adopting this draft as a WG document.

Denis

Remember token binding? It was a stable draft. The OAuth WG spent a bunch of cycles building on top of token binding, but token binding did not get deployed, so no token binding for OAuth.

As I mentioned, I think Justin and Annabelle (and anyone else interested) can influence HTTP Sig to cover OAuth use cases.

/Dick

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=220e8879-1cf9-481e-804c-a9ca9622d19e]ᐧ

On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
This actually seems like a great time for the OAuth group to start working on this more closely given the relative stability of this draft as well as the fact that it is not yet an RFC. This is a perfect time to be able to influence the draft if needed, rather than wait for it to be finalized and then have to find a less-than-ideal workaround for something unforeseen.

Aaron

On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
I meant it is not yet adopted as an RFC.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=43ada4a0-1251-44ee-b32c-f82f530a9e53]ᐧ

 — Justin

On Oct 6, 2021, at 5:08 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

/Dick

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=50ab0782-c889-43c8-9cb2-819eda9391bc]ᐧ

On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
All,

Regards,
 Rifaat & Hannes

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 8 Oct 2021 19:39:16 +0000

I agree that Token Binding is not an experience we want to repeat, and I understand having a "once bitten, twice shy" reaction to this. However, the circumstances that led to Token Binding's failure do not apply to Message Signatures. Token Binding required changes in the user agent, meaning that an AS/RS/client could only use Token Binding if an unrelated party – the browser vendor – had already deployed support for it. This is not the case for Message Signatures. Any service can use Message Signatures, as long as they can convince their clients to use it. (And vice versa)

Regarding adoption, bear in mind that Message Signatures is not a complete security solution (by design) – it is a building block, intended to be used within some higher level authorization protocol. (e.g., OAuth 2.0) I'd expect that most parties that use OAuth 2.0 today and are interested in Message Signatures will hold off on implementing the latter until the WG tells them how to use it with their existing OAuth 2.0 deployment. Blocking WG development of an OAuth 2.0 profile of Message Signatures behind widespread deployment of Message Signatures risks creating a deadlock where the WG is waiting for implementations from would-be implementers who are waiting for guidance from the WG. Worse, rejecting the draft is likely to further discourage these parties from implementing Message Signatures, as it suggests the WG is not interested in standardizing its usage with OAuth 2.0.

While I appreciate your faith in our abilities, it is difficult to advocate for requirements that have not been defined, and harder still to when advocating on behalf of a Working Group that has said it is not interested in Message Signatures.

—

On Oct 6, 2021, at 2:55 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

/Dick

Aaron

 — Justin

/Dick

- Aaron

Regards,
 Rifaat & Hannes

---

From: Dick Hardt <[email-masked]>
Date: Fri, 8 Oct 2021 13:33:16 -0700

On Fri, Oct 8, 2021 at 12:39 PM Richard Backman, Annabelle <
[email-masked]> wrote:

>
> Blocking WG development of an OAuth 2.0 profile of Message Signatures
> behind widespread deployment of Message Signatures risks creating a
> deadlock where the WG is waiting for implementations from would-be
> implementers who are waiting for guidance from the WG. Worse, rejecting the
> draft is likely to further discourage these parties from implementing
> Message Signatures, as it suggests the WG is not interested in
> standardizing its usage with OAuth 2.0.

If the main use case for HTTP Signing is the OAuth WG, then effectively the
OAuth WG is developing HTTP Signing and it is not really a general purpose
standard.

IE, if the success of HTTP Signing is tied to the OAuth WG adopting the
draft, then Mike's arguments about the WG already doing this work is valid.

ᐧ

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 8 Oct 2021 20:43:53 +0000

We need to come up with a better argument such as: This allows a client to reduce use of the token to a smaller window to where the signature is also valid.

We have one: prevent unauthorized parties from using access tokens. Since a client's signing key never needs to leave the client's system, requiring a signature over the `Authorization` header raises the bar from "read an access token out of a server log" to "compromise the client itself." Additionally, Message Signatures defines an optional `nonce` parameter that can be used by the recipient of the message to enforce one-time usage of a signature, meaning that a signature cannot be replayed in another request, even if the signed message components are the same as in the original request.

 I reject the use of an additional header to transmit additional authorization information. Due to the nature of this information may be conveyed and stored throughout a number of systems which would all need access to this complexity. As headers and authorization evolves the introduction and replacement of existing headers provides additional security vulnerabilities.

I'm not sure I follow the concern here. I agree that this adds complexity. While there are many use cases for which this complexity/security tradeoff is worth it, this will not be the case for every OAuth 2.0 deployment out there.

The draft does not support multiple clients with access to the access token who all should be able to provide different client signatures and all be verifiable by the RS.

Access tokens are not intended to be used by multiple clients. They may be used by multiple hosts/devices, for example if the client is a distributed system running on multiple hosts. Different hosts within such a client could use different keys, provided they are all identified in the JWKS the client registers with the AS.

This forces the RS to lookup two pieces of information in the case of signed JWTs, the JWKs from the AS and the JWKs from the client

Yes, however this could be changed. For example, the AS could embed the client's public key in the access token JWT, so the RS only has to retrieve the AS key. That comes with its own set of tradeoffs, but this is likely not the only solution – it's just the one I came up with while writing this email. :)

That's the thing about adopting a draft: once the Working Group adopts it, the Working Group gets to change it to cover all the use cases and requirements that the original author didn't think of. "The draft doesn't cover my use case" is really an argument for adoption.

—

On Oct 7, 2021, at 3:08 AM, Warren Parad <wparad=[email-masked]<mailto:wparad=[email-masked]>> wrote:

While I love the idea to be able to restrict the usage of the access token by the client, enabling longer expiry access tokens, and preventing usage to perform unexpected actions with that token, the reasons I do not support the adoption are as follows:

* The draft depends on another draft and personally not one that I even agree with. Saying that the "draft is officially adopted" doesn't justify depending on it.
* I reject the use of an additional header to transmit additional authorization information. Due to the nature of this information may be conveyed and stored throughout a number of systems which would all need access to this complexity. As headers and authorization evolves the introduction and replacement of existing headers provides additional security vulnerabilities.
* The draft does not support multiple clients with access to the access token who all should be able to provide different client signatures and all be verifiable by the RS.
* This forces the RS to lookup two pieces of information in the case of signed JWTs, the JWKs from the AS and the JWKs from the client
* The argument in the introduction is flawed

Bearer tokens are simple to implement but also have the significant security downside of allowing anyone who sees the access token to use that token.

This is not a complete argument because I can replace the words in the sentence and justify that HTTPSig should never be used by the same argument:
HTTPSig tokens are incredibly complex to implement but also have the significant security downside of allowing anyone who sees the access token and signature to use that token.

We need to come up with a better argument such as: This allows a client to reduce use of the token to a smaller window to where the signature is also valid.
That would allow us to better focus on the value that the RFC would provide, rather than getting stuck with arbitrary implementation of another RFC draft as it would apply to OAuth.

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data with IAM authorization as a service. Implement Authress<https://authress.io/>.

On Thu, Oct 7, 2021 at 11:03 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
I am not supportive of adoption of this document by the WG at this time.

Denis

/Dick

[X]ᐧ

Aaron

[X]ᐧ

 — Justin

/Dick

[X]ᐧ

- Aaron

Regards,
 Rifaat & Hannes

---

From: Warren Parad <[email-masked]>
Date: Fri, 8 Oct 2021 22:52:31 +0200

I think there are a bunch of different conversations happening here at the
same time. Individual responses arguing for/against others in the WG isn't
going to be productive over email. If the goal is to convince everyone that
there are merits despite the objections, then tracking those objections and
current discussion in another form is going to be necessary. (I recommend a
github repository, with separate issues)

We at least need to group the types of discussions we are having and then
list them out in the order of priority before continuing. We can't be
arguing against individual points in this manner and expect a good outcome.

Warren Parad

Founder, CTO

On Fri, Oct 8, 2021 at 10:44 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> We need to come up with a better argument such as: *This allows a client
> to reduce use of the token to a smaller window to where the signature is
> also valid.*
>
>
> We have one: prevent unauthorized parties from using access tokens. Since
> a client's signing key never needs to leave the client's system, requiring
> a signature over the `Authorization` header raises the bar from "read an
> access token out of a server log" to "compromise the client itself."
> Additionally, Message Signatures defines an optional `nonce` parameter that
> can be used by the recipient of the message to enforce one-time usage of a
> signature, meaning that a signature cannot be replayed in another request,
> even if the signed message components are the same as in the original
> request.
>
>
>  I reject the use of an additional header to transmit additional
> I'm not sure I follow the concern here. I agree that this adds complexity.
> While there are many use cases for which this complexity/security tradeoff
> is worth it, this will not be the case for every OAuth 2.0 deployment out
> there.
>
>
> The draft does not support multiple clients with access to the access
> Access tokens are not intended to be used by multiple clients. They *may* be
> used by multiple hosts/devices, for example if the client is a distributed
> system running on multiple hosts. Different hosts within such a client
> could use different keys, provided they are all identified in the JWKS the
> client registers with the AS.
>
>
> This forces the RS to lookup two pieces of information in the case of
> Yes, however this could be changed. For example, the AS could embed the
> client's public key in the access token JWT, so the RS only has to retrieve
> the AS key. That comes with its own set of tradeoffs, but this is likely
> not the only solution – it's just the one I came up with while writing this
> email. :)
>
> That's the thing about adopting a draft: once the Working Group adopts it,
> the Working Group gets to change it to cover all the use cases and
> requirements that the original author didn't think of. "The draft doesn't
> cover my use case" is really an argument *for* adoption.
>
> —
> [email-masked]
> On Oct 7, 2021, at 3:08 AM, Warren Parad <
> wparad=[email-masked]> wrote:
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> We need to come up with a better argument such as: *This allows a client
> to reduce use of the token to a smaller window to where the signature is
> also valid.*
>>>> To be clear, I think you are doing great work on the HTTP Sig doc, and
>>>> a number of concerns I have with HTTP signing have been addressed => I just
>>>>> Just to be clear, the HTTP Sig draft is an official adopted document
>>>>> of the HTTP Working Group since about a year ago. I would not have
>>>>> suggested we depend on it for a document within this WG otherwise.
>>>>>
>>>>>  — Justin
>>>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 8 Oct 2021 21:00:36 +0000

IE, if the success of HTTP Signing is tied to the OAuth WG adopting the draft, then Mike's arguments about the WG already doing this work is valid.

It's not the success of HTTP Message Signatures that concerns me here; that draft will reach RFC regardless of what the OAuth WG does. But I and others would like to use Message Signatures with OAuth 2.0, and would like to have some confidence that there will be a standard, interoperable way to do that.

There are other, non-OAuth 2.0 use cases for HTTP Message Signatures. I don't see the rationale behind waiting for implementations for completely unrelated use cases, or by parties that aren't using OAuth 2.0 for authorization. How are they relevant?

—

On Oct 8, 2021, at 1:33 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Oct 8, 2021 at 12:39 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

Blocking WG development of an OAuth 2.0 profile of Message Signatures behind widespread deployment of Message Signatures risks creating a deadlock where the WG is waiting for implementations from would-be implementers who are waiting for guidance from the WG. Worse, rejecting the draft is likely to further discourage these parties from implementing Message Signatures, as it suggests the WG is not interested in standardizing its usage with OAuth 2.0.

If the main use case for HTTP Signing is the OAuth WG, then effectively the OAuth WG is developing HTTP Signing and it is not really a general purpose standard.

IE, if the success of HTTP Signing is tied to the OAuth WG adopting the draft, then Mike's arguments about the WG already doing this work is valid.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=052c9f85-ef8e-44d3-aca8-40ffb9bce5ef]ᐧ

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 8 Oct 2021 21:02:32 +0000

Working Group discussions need to happen in Working Group spaces. Generally speaking, that means the mailing list.

—

On Oct 8, 2021, at 1:52 PM, Warren Parad <wparad=[email-masked]<mailto:wparad=[email-masked]>> wrote:

I think there are a bunch of different conversations happening here at the same time. Individual responses arguing for/against others in the WG isn't going to be productive over email. If the goal is to convince everyone that there are merits despite the objections, then tracking those objections and current discussion in another form is going to be necessary. (I recommend a github repository, with separate issues)

We at least need to group the types of discussions we are having and then list them out in the order of priority before continuing. We can't be arguing against individual points in this manner and expect a good outcome.

Warren Parad
Founder, CTO

On Fri, Oct 8, 2021 at 10:44 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
We need to come up with a better argument such as: This allows a client to reduce use of the token to a smaller window to where the signature is also valid.

—

Warren Parad
Founder, CTO

Denis

/Dick

[X]ᐧ

Aaron

[X]ᐧ

 — Justin

/Dick

[X]ᐧ

- Aaron

Regards,
 Rifaat & Hannes

---

From: Dick Hardt <[email-masked]>
Date: Fri, 8 Oct 2021 14:06:10 -0700

inline

On Fri, Oct 8, 2021 at 2:00 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> It's not the success of HTTP Message Signatures that concerns me here;
> that draft will reach RFC regardless of what the OAuth WG does.
>

Maybe, maybe not. And then having adoption and proving that all the other
concerns raised on the list such as canonicalization challenges are moot.

> But I and others would like to use Message Signatures with OAuth 2.0, and
> would like to have some confidence that there will be a standard,
> interoperable way to do that.
>
> There are other, non-OAuth 2.0 use cases for HTTP Message Signatures. I
> don't see the rationale behind waiting for implementations for completely
> unrelated use cases, or by parties that aren't using OAuth 2.0 for
> authorization. How are they relevant?
>

The proposal is to build upon a general purpose security mechanism. I would
like to see that general purpose security mechanism proven before building
upon it.

/Dick
ᐧ

---

From: Warren Parad <[email-masked]>
Date: Sat, 9 Oct 2021 01:05:23 +0200

We can definitely start without that general purpose security mechanism
being proven, by using other proven mechanisms to solve the same problem.
There's no reason we need to depend on nor utilize HTTPSig for solving the
problems hoped to be achieved with this draft. But we do need to stipulate
concretely what should be solved by the draft and then we can discuss
what's the right approach. If we are saying DPoP is the right approach to
solve it, we have a draft already (we would need to discuss whether an
alternative is the right approach or reusing that one/making adjustments).
Perhaps DPoP isn't the right approach, and maybe it is, but we need to
start at the beginning.

Right now it just seems we are haphazardly throwing out an implementation
for a draft standard for the sake of implementing that standard. "There are
people that want to use it" isn't productive, what is productive is
describing the core problem that they are facing, the why, and attacking it
problem-first, not solution-first.

It also sounds like we want to justify that work with an authored RFC from
the OAuth WG. Okay, we can push that work, but it needs to be focused on
core problems and solutions revolving in the OAuth space, and not done in a
way for the sole purpose of justifying the work another draft is setting up.

I don't think any one is doubting the benefits that could be gained, but we
should be doubting if this is the right way from an OAuth perspective and
the direction we want to go. We should enumerate those, work on refining
what is in scope and going from there.

The problem with the current draft, is that it doesn't give us an adequate
starting point, sure we can push everything to the WG to solve every open
point, but I for one, would like to see at least a partial draft that
attempts to outline the problem and include a solution which supports a
majority of use cases, without being a very niche collaboration with the
existing signature draft.

Warren Parad

Founder, CTO

On Fri, Oct 8, 2021 at 11:07 PM Dick Hardt <[email-masked]> wrote:

> The proposal is to build upon a general purpose security mechanism. I
> would like to see that general purpose security mechanism proven before
> building upon it.
>
> /Dick
> ᐧ

---

From: David Waite <[email-masked]>
Date: Fri, 8 Oct 2021 18:38:17 -0600

I do not support adopting this work as proposed, with the caveat that I am a co-editor of the DPoP work.

We unfortunately do not have a single approach for PoP which works for all scenarios and deployments, why we have had several proposals and standards such as Token Binding, mutual TLS, and DPoP. There have been other less generalized approaches as well, such as forming signed request and response objects on the channel when one needs end-to-end message integrity or confidentiality.

Each of these has their own capabilities and trade-offs, and their applicability to scenarios where the others falter is why multiple approaches is justified.

The preferred solution for HTTPS resource server access is to leverage MTLS. However, browsers have both poor/nonexistent API to manage ephemeral client keys and poor UX around mutual TLS in general.

DPoP was proposed to attempt a “lightest lift” to provide cryptographic evidence of the sender being involved, so that browsers could protect their tokens from exfiltration by non-exportable, ephemeral keys. In that way, we keep from having to define a completely separate security posture for resource-constraining browser apps.

The motivations for the HTTPSig specification don’t clearly state why it is essential to have another promoted PoP approach. I would expect more prescriptive text about the use case that this is proposed for. In particular, I would love to see an additional use case, outside of DPoP, not solved by MTLS but solved by this proposal.

If it turns out the target between a HTTP Message Signatures and DPoP overlap completely, I suspect we would have the issue of two competing adopted drafts in the working group. I personally do not know the ramifications of such an event. I do not believe there would be consensus on eliminating one, nor would there be a significant reduction in complexity by combining them.

Deferring until HTTPSig is interoperably implemented in the industry gives us concrete motivation in the future to support both.

-DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 00:54:23 +0000

David, Warren, Hannes and others:

The limitations of DPoP and mTLS have been discussed numerous times within the Working Group. Here is a summary of those that I am aware of; others may have additional concerns.

(Though please note first that none of this is to say that DPoP and mTLS are bad or useless – they each are targeted at certain use cases, and they serve those well. They just don't serve every use case well.)

DPoP Limitations:

  1.  Does not support symmetric keys.
  2.  Requires the same key to be used with AS and RSes.
  3.  Does not support multiple valid signing keys.
  4.  Signed content is copied into the JWT and therefore duplicated within the message. This allows for bugs where the verifier fails to check that these values match, or performs that check incorrectly. (e.g., assuming case insensitivity)
  5.  Only covers the method, scheme, host, and path. Allows for additional arbitrary content to be signed, but does not provide any guidance or support for defining interoperable extensions.
  6.  Depends on JWT, which may be a new dependency, particularly for clients that are doing OAuth 2.0 but not OIDC.

mTLS Limitations:

  1.  Requires a single end-to-end TLS connection between client and AS/RS. This often is not the case in modern distributed systems, e.g., TLS may be terminated at a load balancer, or by the hosting platform in the case of a "serverless" application. On the client side, enterprises may have TLS inspection appliances that break the TLS connection.
  2.  Abysmal user experience in the browser. (though that is what DPoP was intended to address, at least initially)

In contrast, Justin's HTTP Message Signatures-based approach:

  1.  Allows for flexibility regarding key selection.
  2.  Allows signing of as much or as little of the HTTP message as is appropriate for the request.
  3.  Does not duplicate signed content.
  4.  Does not depend on JWT, unless you want it to.
  5.  Does not depend on an end-to-end TLS connection, or any other specifics below the HTTP layer.
  6.  Allows servers to use the same signature mechanism for other HTTP signing use cases. (e.g., browser signing authorization cookies, LBs adding a signature over the `X-Forwarded-For` header field)

Note that these concerns regarding use cases not addressed by DPoP and mTLS are not new. Below are excerpts taken from WG meeting notes going back to 2019:

  *   IETF 105<https://datatracker.ietf.org/doc/minutes-105-oauth-201907261000/>:
     *   MTLS is good but not great for browser. TOKBIND has no current browser support. Need solution for browser apps.

     *   [Daniel Fett]: DPOP is hopefully a simple and concise mechanism.

     *   [Brian Campbell]: DPOP came out of a desire for a simplified concise public key mechanism at both the authz and resource server….there isn’t the overhead for symmetric keys.

     *   [Annabelle Backman]: We too find [DPoP] limiting without symmetric as asymmetric can be just too slow.

     *   [John Bradley]: The origin of [DPoP] came from the security workshop specifically focused on applications to do PoP should token binding not come to fruition. We could use web-crypto and create a non-exportable key in the browser. This is why there is no support for symmetric key.

     *   [Mike Jones]: Want to use different POP keys for AT and RT.

     *   [Justin Richer]: I really like this approach. But I agree with Hannes that having a server provided symmetric key is useful.

     *   Roman [Danyliw]: Strongly urge the equities of other groups and surface them.

  *   IETF 106<https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03.pdf>:
     *   Annabelle [Backman]: Would you consider using a HTTP signing solution and not do this
John [Bradley]: ...[DPoP] has limited aspirations than the http signing.

     *   Some discussions on symmetric vs asymmetric encryption and Annabelle is concerned about the scaling and crypto costs. So some folks want both types, this would increase the scope of the effort [for DPoP].

The scope [of DPoP] was to be able to use something with sender constraint for SPA, this is not for broader usage, so this is limited scope not doing what HTTP Signing would be used for. So this needs to be presented as a very focused effort.

     *   Mike [Jones]: The usage of TLS for sender constraint is not deployable

  *   OAuth WG Interim Meeting – 2021-03-15<https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-01-202103151200/>:
     *   Francis [Pouatcha]: DPoP should be by no way a replacement for HTTP signing.

—

On Oct 8, 2021, at 5:38 PM, David Waite <david=[email-masked]<mailto:david=[email-masked]>> wrote:

-DW

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 11:51:33 +0200

Are there things about the OAuth DPoP that are possibly problematic,
definitely, but it is still in draft. Wouldn't this be the best opportunity
to expose these problems to the authors and work through possible
solutions? This conversation has already brought some things to mind which
I'd be interested in improving, for instance *cnf *being an array, and
attempting to utilize the Authorization header more effectively, but this
isn't the thread to discuss those. Is there a reason we can't just improve
the existing DPoP draft to remove the limitations you listed above?

Warren Parad

Founder, CTO

On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> The limitations of DPoP and mTLS have been discussed numerous times within
> the Working Group. Here is a summary of those that I am aware of; others
> may have additional concerns.
>
> (Though please note first that none of this is to say that DPoP and mTLS
> are bad or useless – they each are targeted at certain use cases, and they
> serve those well. They just don't serve *every* use case well.)
>
> DPoP Limitations:
>
>    4. Signed content is copied into the JWT and therefore duplicated
>    within the message. This allows for bugs where the verifier fails to check
>    that these values match, or performs that check incorrectly. (e.g.,
>    assuming case insensitivity)
>    5. Only covers the method, scheme, host, and path. Allows for
>    additional arbitrary content to be signed, but does not provide any
>    guidance or support for defining interoperable extensions.
>    6. Depends on JWT, which may be a new dependency, particularly for
>    clients that are doing OAuth 2.0 but not OIDC.
>
>
> mTLS Limitations:
>
>    1. Requires a single end-to-end TLS connection between client and
>    AS/RS. This often is not the case in modern distributed systems, e.g., TLS
>    may be terminated at a load balancer, or by the hosting platform in the
>    case of a "serverless" application. On the client side, enterprises may
>    have TLS inspection appliances that break the TLS connection.
>    2. Abysmal user experience in the browser. (though that is what DPoP
>    was intended to address, at least initially)
>
>
>    6. Allows servers to use the same signature mechanism for other HTTP
>    signing use cases. (e.g., browser signing authorization cookies, LBs adding
>    a signature over the `X-Forwarded-For` header field)
>
>
> Note that these concerns regarding use cases not addressed by DPoP and
> mTLS are not new. Below are excerpts taken from WG meeting notes going back
> to 2019:
>
>
>    - IETF 105
>    <https://datatracker.ietf.org/doc/minutes-105-oauth-201907261000/>:
>       - MTLS is good but not great for browser. TOKBIND has no current
>       browser support. Need solution for browser apps.
>
>       - [Daniel Fett]: DPOP is hopefully a simple and concise mechanism.
>
>       - [Brian Campbell]: DPOP came out of a desire for a simplified
>       concise public key mechanism at both the authz and resource server….there
>       isn’t the overhead for symmetric keys.
>
>       - [Annabelle Backman]: We too find [DPoP] limiting without
>       symmetric as asymmetric can be just too slow.
>
>       - [John Bradley]: The origin of [DPoP] came from the security
>       workshop specifically focused on applications to do PoP should token
>       binding not come to fruition. We could use web-crypto and create a
>       non-exportable key in the browser. This is why there is no support for
>       symmetric key.
>
>       - [Mike Jones]: Want to use different POP keys for AT and RT.
>
>       - [Justin Richer]: I really like this approach. But I agree with
>       Hannes that having a server provided symmetric key is useful.
>
>       - Roman [Danyliw]: Strongly urge the equities of other groups and
>       surface them.
>
>       - IETF 106
>    <https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03.pdf>:
>
>       - Annabelle [Backman]: Would you consider using a HTTP signing
>       solution and not do this
>       - Some discussions on symmetric vs asymmetric encryption and
>       Annabelle is concerned about the scaling and crypto costs. So some folks
>       want both types, this would increase the scope of the effort [for DPoP].
>
>       The scope [of DPoP] was to be able to use something with sender
>       constraint for SPA, this is not for broader usage, so this is limited scope
>       not doing what HTTP Signing would be used for. So this needs to be
>       presented as a very focused effort.
>
>       - Mike [Jones]: The usage of TLS for sender constraint is not
>       deployable
>
>       - OAuth WG Interim Meeting – 2021-03-15
>    <https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-01-202103151200/>:
>
>       - Francis [Pouatcha]: DPoP should be by no way a replacement for
>       HTTP signing.
>
>
> —
> On Oct 8, 2021, at 5:38 PM, David Waite <
> david=[email-masked]> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not
> We unfortunately do not have a single approach for PoP which works for all
> scenarios and deployments, why we have had several proposals and standards
> such as Token Binding, mutual TLS, and DPoP. There have been other less
> generalized approaches as well, such as forming signed request and response
> objects on the channel when one needs end-to-end message integrity or
> confidentiality.
>
> Each of these has their own capabilities and trade-offs, and their
> applicability to scenarios where the others falter is why multiple
> approaches is justified.
>
> The preferred solution for HTTPS resource server access is to leverage
> MTLS. However, browsers have both poor/nonexistent API to manage ephemeral
> client keys and poor UX around mutual TLS in general.
>
> DPoP was proposed to attempt a “lightest lift” to provide cryptographic
> evidence of the sender being involved, so that browsers could protect their
> tokens from exfiltration by non-exportable, ephemeral keys. In that way, we
> keep from having to define a completely separate security posture for
> resource-constraining browser apps.
>
> The motivations for the HTTPSig specification don’t clearly state why it
> is essential to have another promoted PoP approach. I would expect more
> prescriptive text about the use case that this is proposed for. In
> particular, I would love to see an additional use case, outside of DPoP,
> not solved by MTLS but solved by this proposal.
>
> If it turns out the target between a HTTP Message Signatures and DPoP
> overlap completely, I suspect we would have the issue of two competing
> adopted drafts in the working group. I personally do not know the
> ramifications of such an event. I do not believe there would be consensus
> on eliminating one, nor would there be a significant reduction in
> complexity by combining them.
>
> Deferring until HTTPSig is interoperably implemented in the industry gives
> us concrete motivation in the future to support both.
>
> -DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 18:26:08 +0000

Those issues that could be addressed without completely redesigning DPoP have been discussed within the Working Group multiple times. (See quotes and meeting notes references in my previous message) The authors have pushed back on extending DPoP to cover additional use cases them due to a desire to keep DPoP simple and lightweight. I don't begrudge them that. I think it's reasonable to have a "dirt simple" solution, particularly for SPAs given the relative limitations of the browser environment.

Other issues are inherent to fundamental design choices, such as the use of JWS to prove possession of the key. E.g., you cannot avoid the data duplication issue since a JWS signature only covers a specific serialization of the JWT header and body.

—

On Oct 13, 2021, at 2:51 AM, Warren Parad <wparad=[email-masked]<mailto:wparad=[email-masked]>> wrote:

Are there things about the OAuth DPoP that are possibly problematic, definitely, but it is still in draft. Wouldn't this be the best opportunity to expose these problems to the authors and work through possible solutions? This conversation has already brought some things to mind which I'd be interested in improving, for instance cnf being an array, and attempting to utilize the Authorization header more effectively, but this isn't the thread to discuss those. Is there a reason we can't just improve the existing DPoP draft to remove the limitations you listed above?

Warren Parad
Founder, CTO

On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
David, Warren, Hannes and others:

DPoP Limitations:

mTLS Limitations:

—

-DW

---

From: David Waite <[email-masked]>
Date: Wed, 13 Oct 2021 12:41:21 -0600

> On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 

Agreed with keeping DPoP simple, which was why I was asking if the proposal could indicate it was targeting some of these other use cases. The current draft being proposed for adoption I believe is fixed to the same HTTP properties that DPoP leverages, and thus appears to be targeting the same use cases with a different proof expression.

The duplication within the token is also a trade-off: it allows an implementation to have a white list of acceptable internal values, if say the host and path are rewritten by reverse proxies. It also allows an implementation to give richer diagnostic information when receiving unacceptable DPoP tokens, which may very well come at runtime from an independently-operating portion of an organization reconfiguring intermediaries.

-DW

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 21:01:06 +0200

If keeping DPoP simple means we have to have come up with 10 different
variants to handle all the different cases that it doesn't support, then it
isn't keeping it simple, it is just pushing the problem forward to the
implementers to figure out which set of RFCs to implement.

I would agree with keeping DPoP simple if it meant that 99% of problems
were solved, in which case the question would be why do we need this RFC,
and if what is here is so common, then what good is the DPoP one? Simple is
useless if it is never used.

If there are really so many cases, then I think we need to focus on
recreating PoP in an extensible way that allows the DPoP to sit on top, and
other RFCs to be layered in without a bunch of RFCs to all have competing
semantics.

Here's a great example. I think having an additional header is unjustified,
DPoP, Signature, or whatever you want to call it. But the only thing more
unjustified than that is having different headers for different
implementations of PoP. We can start with a new Draft that just says, PoP
header is X, end of story, might as well call it *Authorization-Extra-Info*,
and then layer in what you want in there. Then the number of differences
through these refactoring between these two drafts becomes smaller. Surely
we can agree to a draft that contains only the semantics that are the same
between the existing two, and then reuse the same terminology and the same
implementation, header name, etc...

We definitely need a PoP RFC, there's no question there (at least I don't
think there is), so let's start with the subset of all pieces that both
sets of authors can agree to.

Is this the list of current concerning limitations?

> Can we narrow this down to the non-negotiables? For instance surely (1),
(4), (6) aren't that bad, sure they may not be optimal for every case. I
can (2) & (3) to be actually limiting and (5) to be easy to allow
extensibility. Would your concerns be at least somewhat be mitigated by
allowing for solutions regarding (2) & (3)?

Warren Parad

Founder, CTO

On Wed, Oct 13, 2021 at 8:41 PM David Waite <david=
[email-masked]> wrote:

> > Those issues that could be addressed without completely redesigning DPoP
> have been discussed within the Working Group multiple times. (See quotes
> and meeting notes references in my previous message) The authors have
> pushed back on extending DPoP to cover additional use cases them due to a
> desire to keep DPoP simple and lightweight. I don't begrudge them that. I
> think it's reasonable to have a "dirt simple" solution, particularly for
> SPAs given the relative limitations of the browser environment.
> >
> > Other issues are inherent to fundamental design choices, such as the use
> of JWS to prove possession of the key. E.g., you cannot avoid the data
> duplication issue since a JWS signature only covers a specific
> serialization of the JWT header and body.
>
> Agreed with keeping DPoP simple, which was why I was asking if the
> proposal could indicate it was targeting some of these other use cases. The
> current draft being proposed for adoption I believe is fixed to the same
> HTTP properties that DPoP leverages, and thus appears to be targeting the
> same use cases with a different proof expression.
>
> The duplication within the token is also a trade-off: it allows an
> implementation to have a white list of acceptable internal values, if say
> the host and path are rewritten by reverse proxies. It also allows an
> implementation to give richer diagnostic information when receiving
> unacceptable DPoP tokens, which may very well come at runtime from an
> independently-operating portion of an organization reconfiguring
> intermediaries.
>
> -DW

---

From: David Waite <[email-masked]>
Date: Wed, 13 Oct 2021 13:05:03 -0600

Specifically to the discussion of symmetric keys:

Adding symmetric keys implies one of a set of rather different architectures. For example, one may look (even more) close to Kerberos, with access tokens resembling service tickets, while another might negotiate a symmetric key/token local to a RS based on an RS challenge. In either case, a symmetric key basis requires resource-constrained keys and possibly tokens.

It also makes preventing exfiltration of keys (and the associated tokens) harder to prevent - you would likely want to include key derivation in grant processes. The HTTP Signature key identifier might actually be from the AS or server, and even represent a wrapped key.

I suspect adding this use case to DPoP would be more than a doubling of complexity.

IMHO past discussions around symmetric keys were more arguments over whether DPoP could be considered complete without that additional complexity, due to the computational efficiencies of symmetric keys over asymmetric ones. This comes into play when the network/computational and complexity costs of a per-RS key/token negotiation is dwarfed by the ongoing use of that token to talk to a particular RS.

This also means that it is primarily a concern when MTLS is not possible, as MTLS will negotiate a symmetric key at a lower level anyway.

-DW

> On Oct 13, 2021, at 3:51 AM, Warren Parad <[email-masked]> wrote:
> 
> Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
> 
> 
> On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]>> wrote:
> Does not support symmetric keys.
> Requires the same key to be used with AS and RSes.
> Does not support multiple valid signing keys.
> Signed content is copied into the JWT and therefore duplicated within the message. This allows for bugs where the verifier fails to check that these values match, or performs that check incorrectly. (e.g., assuming case insensitivity)
> Only covers the method, scheme, host, and path. Allows for additional arbitrary content to be signed, but does not provide any guidance or support for defining interoperable extensions.
> Depends on JWT, which may be a new dependency, particularly for clients that are doing OAuth 2.0 but not OIDC.
> 
> mTLS Limitations:
> Requires a single end-to-end TLS connection between client and AS/RS. This often is not the case in modern distributed systems, e.g., TLS may be terminated at a load balancer, or by the hosting platform in the case of a "serverless" application. On the client side, enterprises may have TLS inspection appliances that break the TLS connection.
> Abysmal user experience in the browser. (though that is what DPoP was intended to address, at least initially)
> 
> Allows for flexibility regarding key selection.
> Allows signing of as much or as little of the HTTP message as is appropriate for the request.
> Does not duplicate signed content.
> Does not depend on JWT, unless you want it to.
> Does not depend on an end-to-end TLS connection, or any other specifics below the HTTP layer.
> Allows servers to use the same signature mechanism for other HTTP signing use cases. (e.g., browser signing authorization cookies, LBs adding a signature over the `X-Forwarded-For` header field)
> 
> IETF 105 <https://datatracker.ietf.org/doc/minutes-105-oauth-201907261000/>:
> MTLS is good but not great for browser. TOKBIND has no current browser support. Need solution for browser apps.
> 
> [Daniel Fett]: DPOP is hopefully a simple and concise mechanism.
> 
> [Brian Campbell]: DPOP came out of a desire for a simplified concise public key mechanism at both the authz and resource server….there isn’t the overhead for symmetric keys.
> 
> [Annabelle Backman]: We too find [DPoP] limiting without symmetric as asymmetric can be just too slow.
> 
> [John Bradley]: The origin of [DPoP] came from the security workshop specifically focused on applications to do PoP should token binding not come to fruition. We could use web-crypto and create a non-exportable key in the browser. This is why there is no support for symmetric key.
> 
> [Mike Jones]: Want to use different POP keys for AT and RT.
> 
> [Justin Richer]: I really like this approach. But I agree with Hannes that having a server provided symmetric key is useful.
> 
> Roman [Danyliw]: Strongly urge the equities of other groups and surface them.
> 
> IETF 106 <https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03.pdf>:
> Annabelle [Backman]: Would you consider using a HTTP signing solution and not do this
> Some discussions on symmetric vs asymmetric encryption and Annabelle is concerned about the scaling and crypto costs. So some folks want both types, this would increase the scope of the effort [for DPoP].
> 
> Mike [Jones]: The usage of TLS for sender constraint is not deployable
> 
> OAuth WG Interim Meeting – 2021-03-15 <https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-01-202103151200/>:
> Francis [Pouatcha]: DPoP should be by no way a replacement for HTTP signing.
> 
> —
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
>> On Oct 8, 2021, at 5:38 PM, David Waite <david=[email-masked] <mailto:david=[email-masked]>> wrote:
>>

---

From: Warren Parad <[email-masked]>
Date: Wed, 13 Oct 2021 21:11:27 +0200

(Honestly I'm struggling to fathom a circumstance where symmetric keys not
only could be used effectively, but should be used, especially in the
context of PoP where there is more than one entity involved)

If the breaking point is symmetric keys, then I would recommend two drafts
with as close to the same semantics as possible, except name them:
* Symmetric DPoP for OAuth
* Asymmetric DPoP for OAuth

Handling key exchange is so fundamentally different as well as signature
verification steps, token and source trusting, that I agree having both in
the same document is problematic. Which is the reason I wanted to suggest
what are the non-negotiables for the authors of the new draft.

Warren Parad

Founder, CTO

On Wed, Oct 13, 2021 at 9:05 PM David Waite <[email-masked]>
wrote:

> Adding symmetric keys implies one of a set of rather different
> architectures. For example, one may look (even more) close to Kerberos,
> with access tokens resembling service tickets, while another might
> negotiate a symmetric key/token local to a RS based on an RS challenge. In
> either case, a symmetric key basis requires resource-constrained keys and
> possibly tokens.
>
> It also makes preventing exfiltration of keys (and the associated tokens)
> harder to prevent - you would likely want to include key derivation in
> grant processes. The HTTP Signature key identifier might actually be from
> the AS or server, and even represent a wrapped key.
>
> IMHO past discussions around symmetric keys were more arguments over
> whether DPoP could be considered complete without that additional
> complexity, due to the computational efficiencies of symmetric keys over
> asymmetric ones. This comes into play when the network/computational and
> complexity costs of a per-RS key/token negotiation is dwarfed by the
> ongoing use of that token to talk to a particular RS.
>
> This also means that it is primarily a concern when MTLS is not possible,
> as MTLS will negotiate a symmetric key at a lower level anyway.
>
> -DW
>
>> The limitations of DPoP and mTLS have been discussed numerous times
>> within the Working Group. Here is a summary of those that I am aware of;
>> others may have additional concerns.
>>
>> We unfortunately do not have a single approach for PoP which works for
>> all scenarios and deployments, why we have had several proposals and
>> standards such as Token Binding, mutual TLS, and DPoP. There have been
>> other less generalized approaches as well, such as forming signed request
>> and response objects on the channel when one needs end-to-end message
>> integrity or confidentiality.
>>
>> Deferring until HTTPSig is interoperably implemented in the industry
>> gives us concrete motivation in the future to support both.
>>
>> -DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 21:27:26 +0000

(Honestly I'm struggling to fathom a circumstance where symmetric keys not only could be used effectively, but should be used, especially in the context of PoP where there is more than one entity involved)

Performance of asymmetric crypto continues to improve, but there is still enough of a difference for it to be significant in services with extremely high volume and extremely low latency requirements.

Handling key exchange is so fundamentally different as well as signature verification steps, token and source trusting, that I agree having both in the same document is problematic.

This is precisely why we chose to push HTTP Message Signatures through HTTPbis. Provide a single, generic solution for message component signing at the HTTP layer, and let higher level protocols (e.g., OAuth 2.0) solve the key exchange problem.

—

On Oct 13, 2021, at 12:11 PM, Warren Parad <wparad=[email-masked]<mailto:wparad=[email-masked]>> wrote:

(Honestly I'm struggling to fathom a circumstance where symmetric keys not only could be used effectively, but should be used, especially in the context of PoP where there is more than one entity involved)

If the breaking point is symmetric keys, then I would recommend two drafts with as close to the same semantics as possible, except name them:
* Symmetric DPoP for OAuth
* Asymmetric DPoP for OAuth

Handling key exchange is so fundamentally different as well as signature verification steps, token and source trusting, that I agree having both in the same document is problematic. Which is the reason I wanted to suggest what are the non-negotiables for the authors of the new draft.

Warren Parad
Founder, CTO

On Wed, Oct 13, 2021 at 9:05 PM David Waite <[email-masked]<mailto:[email-masked]>> wrote:
Specifically to the discussion of symmetric keys:

-DW

On Oct 13, 2021, at 3:51 AM, Warren Parad <[email-masked]<mailto:[email-masked]>> wrote:

Warren Parad
Founder, CTO

DPoP Limitations:

mTLS Limitations:

—

-DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 21:55:04 +0000

If keeping DPoP simple means we have to have come up with 10 different variants to handle all the different cases that it doesn't support, then it isn't keeping it simple, it is just pushing the problem forward to the implementers to figure out which set of RFCs to implement.

I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has use cases that aren't covered by one or more of those, they should bring those up so we can discuss them and decide what changes are warranted. (Either here, or in HTTPbis if changes should be made to Message Signatures) My preference would've been to stop at 2, but the consensus has not been in favor of expanding the scope of use cases served by DPoP.

If there are really so many cases, then I think we need to focus on recreating PoP in an extensible way that allows the DPoP to sit on top, and other RFCs to be layered in without a bunch of RFCs to all have competing semantics.

This is what we are doing with Message Signatures. We're providing a general purpose signature mechanism, which higher-level protocols can build on.

Here's a great example. I think having an additional header is unjustified, DPoP, Signature, or whatever you want to call it. But the only thing more unjustified than that is having different headers for different implementations of PoP. We can start with a new Draft that just says, PoP header is X, end of story, might as well call it Authorization-Extra-Info, and then layer in what you want in there.

I can see the argument for DPoP including the proof in the `Authorization` header field, since the proof is intrinsically related to the access token and request authorization – not making a judgement on that, as this is the wrong thread and I don't have a horse in that race. Packing everything into a single header field doesn't make sense for Message Signatures, since they may or may not have anything to do with request authorization, access tokens, or anything of the sort. Additionally, the use of separate `Signature-Input` and `Signature` header fields allows us to have a very simple field syntax using Structured Field Values for HTTP<https://datatracker.ietf.org/doc/html/rfc8941>, and makes it easy for intermediaries to chain signatures. (E.g., a reverse proxy might add an `X-Forwarded-For` header field, and add a Message Signature covering that header field plus the PoP signature included by the client.) …and I'll stop there lest we dive into topics for the HTTPbis WG.

—

On Oct 13, 2021, at 12:01 PM, Warren Parad <[email-masked]<mailto:[email-masked]>> wrote:

If keeping DPoP simple means we have to have come up with 10 different variants to handle all the different cases that it doesn't support, then it isn't keeping it simple, it is just pushing the problem forward to the implementers to figure out which set of RFCs to implement.

I would agree with keeping DPoP simple if it meant that 99% of problems were solved, in which case the question would be why do we need this RFC, and if what is here is so common, then what good is the DPoP one? Simple is useless if it is never used.

If there are really so many cases, then I think we need to focus on recreating PoP in an extensible way that allows the DPoP to sit on top, and other RFCs to be layered in without a bunch of RFCs to all have competing semantics.

Here's a great example. I think having an additional header is unjustified, DPoP, Signature, or whatever you want to call it. But the only thing more unjustified than that is having different headers for different implementations of PoP. We can start with a new Draft that just says, PoP header is X, end of story, might as well call it Authorization-Extra-Info, and then layer in what you want in there. Then the number of differences through these refactoring between these two drafts becomes smaller. Surely we can agree to a draft that contains only the semantics that are the same between the existing two, and then reuse the same terminology and the same implementation, header name, etc...

We definitely need a PoP RFC, there's no question there (at least I don't think there is), so let's start with the subset of all pieces that both sets of authors can agree to.

Can we narrow this down to the non-negotiables? For instance surely (1), (4), (6) aren't that bad, sure they may not be optimal for every case. I can (2) & (3) to be actually limiting and (5) to be easy to allow extensibility. Would your concerns be at least somewhat be mitigated by allowing for solutions regarding (2) & (3)?

Warren Parad
Founder, CTO

On Wed, Oct 13, 2021 at 8:41 PM David Waite <david=[email-masked]<mailto:[email-masked]>> wrote:

> On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
>

-DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Oct 2021 22:20:15 +0000

Agreed with keeping DPoP simple, which was why I was asking if the proposal could indicate it was targeting some of these other use cases.

It's clear from the feedback that the current draft does not clearly express these use cases. There is overlap with DPoP – on a technical level, Message Signatures ought to be able to handle DPoP's use cases, albeit complexity in different places. But not vice-versa.

The current draft being proposed for adoption I believe is fixed to the same HTTP properties that DPoP leverages, and thus appears to be targeting the same use cases with a different proof expression.

This is a misconception that should get clarified in the draft. One of the core concepts behind Message Signatures is that it defines a standard mechanism for signature components of an HTTP message and for communicating which components are signed, but it does not dictate which components need to be signed. That will vary from deployment to deployment, based on which components are semantically meaningful. E.g., an RS that accepts POST requests and receives parameters in the request body may require that the `Digest` header field be signed, whereas one that only accepts GET requests may only need the URL to be signed. The draft defines an `Accept-Signature` header field that can be included in a message to indicate which components need to be signed.

Justin's draft introduces a requirement that signatures intended to provide PoP for OAuth MUST sign the `Authorization` header field, since that's where the access token is. Beyond that, RSes can indicate their API-specific signing requirements via `Accept-Signature`. (And/or through out-of-band documentation)

The duplication within the token is also a trade-off: it allows an implementation to have a white list of acceptable internal values, if say the host and path are rewritten by reverse proxies.

I agree, there are trade-offs. For some, especially those already using JWTs all over the place, the simplicity of using a format and libraries they are already familiar with may outweigh the risk I described.

FWIW, the Message Signatures approach to the situation you described would be for the reverse proxy to add an `X-Forwarded-Host` or similar header field, and add a signature over that, the `Host` header field, and the client's signature. (Message Signatures supports multiple signatures on one message) I like this approach as the signatures are guaranteed to be validated against the same data the application uses. (Since there's only one copy of the data)

—

On Oct 13, 2021, at 11:41 AM, David Waite <[email-masked]<mailto:[email-masked]>> wrote:

-DW

---

From: Warren Parad <[email-masked]>
Date: Thu, 14 Oct 2021 14:47:20 +0200

I feel like there are a bunch of pieces of the implementation fundamentally
missing here, so we are back to, as it is right now, the draft isn't
sufficient. What prevents the signature from being used without this RFC?
How do you do expect the symmetric key exchange to be oauth compliant? How
does the RS know that there is supposed to be a signature, if the client
doesn't provide it?

Warren Parad

Founder, CTO

On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
>
> This is what we are doing with Message Signatures. We're providing a
> general purpose signature mechanism, which higher-level protocols can build
> on.
>
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
>
>
> I can see the argument for DPoP including the proof in the `Authorization`
> header field, since the proof is intrinsically related to the access token
> and request authorization – not making a judgement on that, as this is the
> wrong thread and I don't have a horse in that race. Packing everything into
> a single header field doesn't make sense for Message Signatures, since they
> may or may not have anything to do with request authorization, access
> tokens, or anything of the sort. Additionally, the use of separate
> `Signature-Input` and `Signature` header fields allows us to have a very
> simple field syntax using Structured Field Values for HTTP
> <https://datatracker.ietf.org/doc/html/rfc8941>, and makes it easy for
> intermediaries to chain signatures. (E.g., a reverse proxy might add an
> `X-Forwarded-For` header field, and add a Message Signature covering that
> header field plus the PoP signature included by the client.) …and I'll stop
> there lest we dive into topics for the HTTPbis WG.
>
> —
> On Oct 13, 2021, at 12:01 PM, Warren Parad <[email-masked]> wrote:
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
> Then the number of differences through these refactoring between these two
> drafts becomes smaller. Surely we can agree to a draft that contains only
> the semantics that are the same between the existing two, and then reuse
> the same terminology and the same implementation, header name, etc...
>
>> > Those issues that could be addressed without completely redesigning
>> DPoP have been discussed within the Working Group multiple times. (See
>> quotes and meeting notes references in my previous message) The authors
>> have pushed back on extending DPoP to cover additional use cases them due
>> to a desire to keep DPoP simple and lightweight. I don't begrudge them
>> that. I think it's reasonable to have a "dirt simple" solution,
>> particularly for SPAs given the relative limitations of the browser
>> environment.
>> >
>> > Other issues are inherent to fundamental design choices, such as the
>> use of JWS to prove possession of the key. E.g., you cannot avoid the data

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Oct 2021 10:46:56 -0400

> On Oct 14, 2021, at 8:47 AM, Warren Parad <wparad=[email-masked]> wrote:
> 
> I feel like there are a bunch of pieces of the implementation fundamentally missing here, so we are back to, as it is right now, the draft isn't sufficient.

Of course the draft isn’t sufficient for  publication — that’s what the call for adoption is all about! It’s not meant to say “this is done, let’s ship it”, it’s meant  to say “this is an idea, let’s finish it in the WG”.

> What prevents the signature from being used without this RFC?

I’m not sure what you’re asking here. HTTP Message Signatures  can be  used without the OAuth-specific RFC. Someone could also use HTTP Signatures with OAuth tokens without following anything from the OAuth WG. There are people doing that today in the wild, using the  predecessors  of the  HTTP Message Signatures draft and their own grafting.

> How do you do expect the symmetric key exchange to be oauth compliant?

I can think of a number of approaches that would work: Pre-registration of keys, key derivation functions, cloud key escrow systems — these are things that the OAuth profile of HTTP Signatures would have to answer, as I laid out in my presentation.

> How does the RS know that there is supposed to be a signature, if the client doesn't provide it?

The same way that it knows there’s supposed to be a particular MTLS certificate or DPoP Proof today — the token metadata. The RS can get that through introspection, through something in the token itself (like the JWT “cnf” claim), or some other internal system. 

 — Justin

> On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> I can see the argument for DPoP including the proof in the `Authorization` header field, since the proof is intrinsically related to the access token and request authorization – not making a judgement on that, as this is the wrong thread and I don't have a horse in that race. Packing everything into a single header field doesn't make sense for Message Signatures, since they may or may not have anything to do with request authorization, access tokens, or anything of the sort. Additionally, the use of separate `Signature-Input` and `Signature` header fields allows us to have a very simple field syntax using Structured Field Values for HTTP <https://datatracker.ietf.org/doc/html/rfc8941>, and makes it easy for intermediaries to chain signatures. (E.g., a reverse proxy might add an `X-Forwarded-For` header field, and add a Message Signature covering that header field plus the PoP signature included by the client.) …and I'll stop there lest we dive into topics for the HTTPbis WG.
> 
> —
>> On Oct 13, 2021, at 12:01 PM, Warren Parad <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Wed, Oct 13, 2021 at 8:41 PM David Waite <david=[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> > On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> >

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Oct 2021 10:51:01 -0400

I wanted to jump back to the top of the thread to point out something that seems to be getting missed:

This is not a call for adoption of HTTP Message Signatures. That document already exists in the HTTP WG and will be published as an RFC from that group. If you want to have discussions  about  how the HTTP Message Signatures specification works, come  to the HTTP working group for those  discussions.

This is a call for adoption of an OAuth application of the HTTP Message Signatures spec. Signatures will exist with or without the OAuth WG’s use of it, and I would argue that people are going to attach OAuth access  tokens to requests  using HTTP Message Signatures whether or not  the OAuth WG picks up the work. The question is whether those  applications are going to be isolated profiles and silos, like they are today, or whether there can be one way to use them together across different systems.

My recommendation is that  the OAuth WG define how exactly HTTP Message Signatures should be  used  with OAuth, which is what  this proposal is  for.

 — Justin

---

From: Warren Parad <[email-masked]>
Date: Thu, 14 Oct 2021 17:18:53 +0200

I'm glad you brought this up, since Signatures can already be used with
OAuth, the question is exactly that. What are the ways using these together
without an explicit RFC would cause a problem? I'm not totally sure that
makes sense, so let me give an example. If the draft says "we need to
exchange keys, but it isn't part of the draft" and we have that for every
section, what's the benefit of the RFC in the first place. Sure PoP needs a
solution, is it solved without an RFC for anyone using OAuth and the
Signature draft as is, or is there something meaningful that needs to be
documented?

Without providing author recommendations in the form of filling in at least
part of the draft, instead of the question being *is this the right way to
solve this part of the problem* it becomes *should we even have a draft.*

The one part of the draft that does exist is "Introduction of a new token
type", which if we say:

> The RS can get that through introspection, through something in the token
> itself (like the JWT “cnf” claim)

Then the obvious conclusion should be: we don't need a new token type. So
if we remove that from that draft, it brings me back to the original point,
what problem does this particular draft solve as part of PoP, other than
saying we should have PoP via message signatures because message signatures
can provide PoP.

We could say things like "Key exchange needs to be defined so that..." or
"a new claim needs to be added so that...", but I fear we haven't done that
with the draft so far.

Obviously this is only my perspective, which isn't saying let's not do
this, it is "sure let's do this as long as we can answer these questions".
Right now I'm not convinced of this actually solving the PoP situation for
me, while it is a valid argument, it isn't a sound one, due to its
implementation relying on Signatures and how Signatures is constructed at
this moment.

So rather than "this is PoP", let's focus on the problems needed to solve
for PoP Signatures to work.

Warren Parad

Founder, CTO

On Thu, Oct 14, 2021 at 4:51 PM Justin Richer <[email-masked]> wrote:

> This is not a call for adoption of HTTP Message Signatures. That document
> already exists in the HTTP WG and will be published as an RFC from that
> group. If you want to have discussions  about  how the HTTP Message
> Signatures specification works, come  to the HTTP working group for those
>  discussions.
>
> This is a call for adoption of an OAuth application of the HTTP Message
> Signatures spec. Signatures will exist with or without the OAuth WG’s use
> of it, and I would argue that people are going to attach OAuth access
>  tokens to requests  using HTTP Message Signatures whether or not  the
> OAuth WG picks up the work. The question is whether those  applications are
> going to be isolated profiles and silos, like they are today, or whether
> there can be one way to use them together across different systems.
>
> My recommendation is that  the OAuth WG define how exactly HTTP Message
> Signatures should be  used  with OAuth, which is what  this proposal is
>  for.
>
>  — Justin
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 21 Oct 2021 08:56:42 -0400

All,

Based on the feedback on this call for adoption request, it seems that this
document does *not* have enough support to adopt it as a WG document at
this stage.

Regards,
 Rifaat & Hannes

On Thu, Oct 14, 2021 at 11:19 AM Warren Parad <[email-masked]> wrote:

> Without providing author recommendations in the form of filling in at
> least part of the draft, instead of the question being *is this the right
> way to solve this part of the problem* it becomes *should we even have a
> draft.*
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 22 Oct 2021 15:08:33 -0700

I have a use case for a self contained request that can be
independently verified by multiple parties. IE, not just have PoP at HTTP
endpoint, but by components doing processing further down the line. It also
provides non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and
the access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value
in standardization effort, but I wanted to call out a use case not solved
by the current efforts.

/Dick

---

From: Justin Richer <[email-masked]>
Date: Sat, 23 Oct 2021 23:55:11 +0000

Dick, you would probably be interested in the Oblivious HTTP effort that has recently been chartered to solve similar encapsulation problems in HTTP. 

- Justin
________________________________________
From: OAuth [[email-masked]] on behalf of Dick Hardt [[email-masked]]
Sent: Friday, October 22, 2021 6:08 PM
To: Richard Backman, Annabelle
Cc: David Waite; oauth
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

I have a use case for a self contained request that can be independently verified by multiple parties. IE, not just have PoP at HTTP endpoint, but by components doing processing further down the line. It also provides non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and the access token.

It is not clear if others have similar requirements, or if there is value in standardization effort, but I wanted to call out a use case not solved by the current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
If keeping DPoP simple means we have to have come up with 10 different variants to handle all the different cases that it doesn't support, then it isn't keeping it simple, it is just pushing the problem forward to the implementers to figure out which set of RFCs to implement.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Wed, 27 Oct 2021 09:56:20 -0700

Thanks for pointing out the Oblivious draft Justin. It is interesting, but
looks to be focussed on privacy rather than non-repudiation. Was I missing
non-repudiation aspects?
ᐧ

On Sat, Oct 23, 2021 at 4:55 PM Justin Richer <[email-masked]> wrote:

> Dick, you would probably be interested in the Oblivious HTTP effort that
> has recently been chartered to solve similar encapsulation problems in
> HTTP.
>
> - Justin
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth
> Proof of Possession Tokens with HTTP Message Signature
>
> I have a use case for a self contained request that can be independently
> verified by multiple parties. IE, not just have PoP at HTTP endpoint, but
> by components doing processing further down the line. It also provides
> non-repudiation.
>
> [email-masked]<mailto:[email-masked]>> wrote:
> [
> https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ
> <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]%E1%90%A7>
>