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

[Rifaat Shekh-Yusef]

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  wrote:

> 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
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Thu, Oct 14, 2021 at 4:51 PM Justin Richer  wrote:
>
>> 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
>>
>>
>> On Oct 6, 2021, at 5:01 PM, Rifaat Shekh-Yusef 
>> 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/
>>
>> Please, provide your feedback on the mailing list by* October 20th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Thu, Oct 14, 2021 at 4:51 PM Justin Richer  wrote:

> 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
>
>
> On Oct 6, 2021, at 5:01 PM, Rifaat Shekh-Yusef 
> 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/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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


> On Oct 6, 2021, at 5:01 PM, Rifaat Shekh-Yusef  
> 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/ 
> 
> 
> Please, provide your feedback on the mailing list by October 20th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

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  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
> Secure your user data with IAM authorization as a service. Implement Authress 
> .
> 
> 
> On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle 
> mailto:40amazon@dmarc.ietf.org>> 
> wrote:
> 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:
> 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)
> 
> In contrast, Justin's HTTP Message Signatures-based approach:
> 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)
> 
> 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 :
> 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 

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

[Warren Parad]

(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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 9:05 PM David Waite 
wrote:

> 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  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
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
>> 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 

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

[Warren Parad]

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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle  wrote:

> 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
>:
>   - 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
>
> :
>
>   - 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 

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

[David Waite]

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Fri, Oct 8, 2021 at 11:07 PM Dick Hardt  wrote:

>
> inline
>
> On Fri, Oct 8, 2021 at 2:00 PM Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
>
>> 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.
>>
>
> 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
> ᐧ
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

inline

On Fri, Oct 8, 2021 at 2:00 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> 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.
>

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
ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Richard Backman, Annabelle]

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?

—
Annabelle Backman (she/her)
richa...@amazon.com




On Oct 8, 2021, at 1:33 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> 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.


On Fri, Oct 8, 2021 at 12:39 PM Richard Backman, Annabelle 
mailto:richa...@amazon.com>> 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=zerocontent=052c9f85-ef8e-44d3-aca8-40ffb9bce5ef]ᐧ

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Fri, Oct 8, 2021 at 10:44 PM Richard Backman, Annabelle  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
> 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.
>
> —
> Annabelle Backman (she/her)
> richa...@amazon.com
>
>
>
>
> On Oct 7, 2021, at 3:08 AM, Warren Parad <
> wparad=40rhosys...@dmarc.ietf.org> 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.
>
> 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 

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

[Richard Backman, Annabelle]

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.

—
Annabelle Backman (she/her)
richa...@amazon.com




On Oct 7, 2021, at 3:08 AM, Warren Parad 
mailto:wparad=40rhosys...@dmarc.ietf.org>> 
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.


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.

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

[Mike Jones]

I understand the layering that you’re describing, Justin.  That said, all the 
complexity of OAuth 1 and draft-ietf-oauth-signed-http-request are still there 
*and more*.  The complexity is just moved to a different draft in the HTTP 
working group that the proposed OAuth draft in question has taken a dependency 
upon.  The HTTP working group draft is a fully general, all-singing, 
all-dancing HTTP signing draft that will be even more difficult to obtain 
interop on than OAuth 1 or draft-ietf-oauth-signed-http-request were.

Just like canonicalization schemes inhibit interoperation due to their sheer 
complexity, HTTP signing schemes do the same.  We should discourage realistic 
systems from taking dependencies on them.  Therefore, we should not adopt this 
draft.

   -- Mike

From: Justin Richer 
Sent: Friday, October 8, 2021 12:23 PM
To: Mike Jones 
Cc: rifaat.s.i...@gmail.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens 
with HTTP Message Signature

Hi Mike,

One of the major benefits of this proposed draft is that it does not try to 
solve the problem of HTTP message signing — which is a huge problem unto 
itself. When I wrote the original draft-ietf-oauth-signed-http-request, I 
wasn’t able to write it to depend on a general-purpose HTTP signing spec and so 
it had to invent a mechanism. OAuth 1 worked on signing just query parameters 
and lots of things in the front-channel, and so invented its own mechanism.

Now that the HTTP working group is well on the way to standardizing the HTTP 
Message Signatures draft as a general-purpose RFC, the OAuth working group 
doesn’t need to solve that problem anymore, and that’s a really, really good 
thing. We aren’t the right community to get that right, and the two previous 
failed attempts you point to prove that better than anything. That’s exactly 
why this draft is NOT going to do that, at all. HTTP Message Signing exists, 
people are implementing it and using it. It makes sense for the OAuth working 
group to define a way to use that work in an OAuth context. We are not and 
should not try again to define a way to sign HTTP messages.

That said, we know that DPoP invents its own way to sign an HTTP message, in a 
limited fashion. It has clear limitations — it doesn’t sign query parameters 
(which are likely to be important to many API types), it doesn’t sign headers, 
it doesn’t sign the body, etc. Even with these limitations, DPoP is useful, and 
I still argue that instead of trying to extend DPoP with a bunch of other 
things, we should let it exist as the clean point solution that it is.

This draft is actually significantly simpler than DPoP precisely because it is 
not defining an HTTP signing mechanism.

 — Justin


On Oct 8, 2021, at 2:24 PM, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

I do not support adoption of this draft.  OAuth 1 failed because of the 
complexity of HTTP Signing and the resulting difficulty of achieving interop.  
draft-ietf-oauth-signed-http-request was abandoned by the working group 
recognizing that it was resurrecting equivalent complexity to OAuth 1.  The 
proposed new draft is a third crack at the same thing that’s not sufficiently 
differentiated from the previous failed efforts in my mind to warrant us 
spending time on it.

Also, note we do have draft-ietf-oauth-dpop, which solves the actual 
proof-of-possession problem for OAuth in a narrowly targeted, focused manner.  
That draft is active and in good shape.  We don’t need a more general, more 
complicated draft solving the same problem.

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, October 6, 2021 2:02 PM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with 
HTTP Message Signature

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

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

On Fri, Oct 8, 2021 at 12:39 PM Richard Backman, Annabelle <
richa...@amazon.com> 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.



ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

>
> HTTP Message Signing exists, people are implementing it and using it.


Token Binding existed as well.

HTTP Message Signing is not yet an RFC, and in my opinion it only makes
sense for OAuth to build on top of it if it is successful with lots of
interoperable deployments.
ᐧ

On Fri, Oct 8, 2021 at 12:23 PM Justin Richer  wrote:

> Hi Mike,
>
> One of the major benefits of this proposed draft is that it does not try
> to solve the problem of HTTP message signing — which is a huge problem unto
> itself. When I wrote the original draft-ietf-oauth-signed-http-request, I
> wasn’t able to write it to depend on a general-purpose HTTP signing spec
> and so it had to invent a mechanism. OAuth 1 worked on signing just query
> parameters and lots of things in the front-channel, and so invented its own
> mechanism.
>
> Now that the HTTP working group is well on the way to standardizing the
> HTTP Message Signatures draft as a general-purpose RFC, the OAuth working
> group doesn’t need to solve that problem anymore, and that’s a really,
> really good thing. We aren’t the right community to get that right, and the
> two previous failed attempts you point to prove that better than anything.
> That’s exactly why this draft is NOT going to do that, at all. HTTP Message
> Signing exists, people are implementing it and using it. It makes sense for
> the OAuth working group to define a way to use that work in an OAuth
> context. We are not and should not try again to define a way to sign HTTP
> messages.
>
> That said, we know that DPoP invents its own way to sign an HTTP message,
> in a limited fashion. It has clear limitations — it doesn’t sign query
> parameters (which are likely to be important to many API types), it doesn’t
> sign headers, it doesn’t sign the body, etc. Even with these limitations,
> DPoP is useful, and I still argue that instead of trying to extend DPoP
> with a bunch of other things, we should let it exist as the clean point
> solution that it is.
>
> This draft is actually significantly simpler than DPoP precisely because
> it is not defining an HTTP signing mechanism.
>
>  — Justin
>
> On Oct 8, 2021, at 2:24 PM, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> *I do not support adoption* of this draft.  OAuth 1 failed because of the
> complexity of HTTP Signing and the resulting difficulty of achieving
> interop.  draft-ietf-oauth-signed-http-request was abandoned by the working
> group recognizing that it was resurrecting equivalent complexity to OAuth
> 1.  The proposed new draft is a third crack at the same thing that’s not
> sufficiently differentiated from the previous failed efforts in my mind to
> warrant us spending time on it.
>
> Also, note we do have draft-ietf-oauth-dpop, which solves the actual
> proof-of-possession problem for OAuth in a narrowly targeted, focused
> manner.  That draft is active and in good shape.  We don’t need a more
> general, more complicated draft solving the same problem.
>
>        -- Mike
>
> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Wednesday, October 6, 2021 2:02 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Call for Adoption - OAuth Proof of Possession
> Tokens with HTTP Message Signature
>
> 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
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Domingos Creado]

"This draft is actually significantly simpler than DPoP precisely because
it is not defining an HTTP signing mechanism. "
that is my understanding as well, but I was afraid to start a flame war :D

On Fri, Oct 8, 2021 at 4:23 PM Justin Richer  wrote:

> Hi Mike,
>
> One of the major benefits of this proposed draft is that it does not try
> to solve the problem of HTTP message signing — which is a huge problem unto
> itself. When I wrote the original draft-ietf-oauth-signed-http-request, I
> wasn’t able to write it to depend on a general-purpose HTTP signing spec
> and so it had to invent a mechanism. OAuth 1 worked on signing just query
> parameters and lots of things in the front-channel, and so invented its own
> mechanism.
>
> Now that the HTTP working group is well on the way to standardizing the
> HTTP Message Signatures draft as a general-purpose RFC, the OAuth working
> group doesn’t need to solve that problem anymore, and that’s a really,
> really good thing. We aren’t the right community to get that right, and the
> two previous failed attempts you point to prove that better than anything.
> That’s exactly why this draft is NOT going to do that, at all. HTTP Message
> Signing exists, people are implementing it and using it. It makes sense for
> the OAuth working group to define a way to use that work in an OAuth
> context. We are not and should not try again to define a way to sign HTTP
> messages.
>
> That said, we know that DPoP invents its own way to sign an HTTP message,
> in a limited fashion. It has clear limitations — it doesn’t sign query
> parameters (which are likely to be important to many API types), it doesn’t
> sign headers, it doesn’t sign the body, etc. Even with these limitations,
> DPoP is useful, and I still argue that instead of trying to extend DPoP
> with a bunch of other things, we should let it exist as the clean point
> solution that it is.
>
> This draft is actually significantly simpler than DPoP precisely because
> it is not defining an HTTP signing mechanism.
>
>  — Justin
>
> On Oct 8, 2021, at 2:24 PM, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> *I do not support adoption* of this draft.  OAuth 1 failed because of the
> complexity of HTTP Signing and the resulting difficulty of achieving
> interop.  draft-ietf-oauth-signed-http-request was abandoned by the working
> group recognizing that it was resurrecting equivalent complexity to OAuth
> 1.  The proposed new draft is a third crack at the same thing that’s not
> sufficiently differentiated from the previous failed efforts in my mind to
> warrant us spending time on it.
>
> Also, note we do have draft-ietf-oauth-dpop, which solves the actual
> proof-of-possession problem for OAuth in a narrowly targeted, focused
> manner.  That draft is active and in good shape.  We don’t need a more
> general, more complicated draft solving the same problem.
>
>        -- Mike
>
> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Wednesday, October 6, 2021 2:02 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Call for Adoption - OAuth Proof of Possession
> Tokens with HTTP Message Signature
>
> 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
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Richard Backman, Annabelle]

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.


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

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.

—
Annabelle Backman (she/her)
richa...@amazon.com




On Oct 6, 2021, at 2:55 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> 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.


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=zerocontent=220e8879-1cf9-481e-804c-a9ca9622d19e]ᐧ

On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki 
mailto:aa...@parecki.com>> 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 
mailto:dick.ha...@gmail.com>> wrote:
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.


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

On Wed, Oct 6, 2021 at 2:20 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
> 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 
mailto:dick.ha...@gmail.com>> wrote:

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

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

[Justin Richer]

Hi Mike,

One of the major benefits of this proposed draft is that it does not try to 
solve the problem of HTTP message signing — which is a huge problem unto 
itself. When I wrote the original draft-ietf-oauth-signed-http-request, I 
wasn’t able to write it to depend on a general-purpose HTTP signing spec and so 
it had to invent a mechanism. OAuth 1 worked on signing just query parameters 
and lots of things in the front-channel, and so invented its own mechanism.

Now that the HTTP working group is well on the way to standardizing the HTTP 
Message Signatures draft as a general-purpose RFC, the OAuth working group 
doesn’t need to solve that problem anymore, and that’s a really, really good 
thing. We aren’t the right community to get that right, and the two previous 
failed attempts you point to prove that better than anything. That’s exactly 
why this draft is NOT going to do that, at all. HTTP Message Signing exists, 
people are implementing it and using it. It makes sense for the OAuth working 
group to define a way to use that work in an OAuth context. We are not and 
should not try again to define a way to sign HTTP messages.

That said, we know that DPoP invents its own way to sign an HTTP message, in a 
limited fashion. It has clear limitations — it doesn’t sign query parameters 
(which are likely to be important to many API types), it doesn’t sign headers, 
it doesn’t sign the body, etc. Even with these limitations, DPoP is useful, and 
I still argue that instead of trying to extend DPoP with a bunch of other 
things, we should let it exist as the clean point solution that it is.

This draft is actually significantly simpler than DPoP precisely because it is 
not defining an HTTP signing mechanism. 

 — Justin

> On Oct 8, 2021, at 2:24 PM, Mike Jones 
>  wrote:
> 
> I do not support adoption of this draft.  OAuth 1 failed because of the 
> complexity of HTTP Signing and the resulting difficulty of achieving interop. 
>  draft-ietf-oauth-signed-http-request was abandoned by the working group 
> recognizing that it was resurrecting equivalent complexity to OAuth 1.  The 
> proposed new draft is a third crack at the same thing that’s not sufficiently 
> differentiated from the previous failed efforts in my mind to warrant us 
> spending time on it.
>  
> Also, note we do have draft-ietf-oauth-dpop, which solves the actual 
> proof-of-possession problem for OAuth in a narrowly targeted, focused manner. 
>  That draft is active and in good shape.  We don’t need a more general, more 
> complicated draft solving the same problem.
>  
>-- Mike
>  
> From: OAuth mailto:oauth-boun...@ietf.org>> On 
> Behalf Of Rifaat Shekh-Yusef
> Sent: Wednesday, October 6, 2021 2:02 PM
> To: oauth mailto:oauth@ietf.org>>
> Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with 
> HTTP Message Signature
>  
> 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
>  
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://www.ietf.org/mailman/listinfo/oauth>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

I do not support adoption of this draft.  OAuth 1 failed because of the 
complexity of HTTP Signing and the resulting difficulty of achieving interop.  
draft-ietf-oauth-signed-http-request was abandoned by the working group 
recognizing that it was resurrecting equivalent complexity to OAuth 1.  The 
proposed new draft is a third crack at the same thing that’s not sufficiently 
differentiated from the previous failed efforts in my mind to warrant us 
spending time on it.

Also, note we do have draft-ietf-oauth-dpop, which solves the actual 
proof-of-possession problem for OAuth in a narrowly targeted, focused manner.  
That draft is active and in good shape.  We don’t need a more general, more 
complicated draft solving the same problem.

   -- Mike

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, October 6, 2021 2:02 PM
To: oauth 
Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with 
HTTP Message Signature

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Richard Backman, Annabelle]

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)
richa...@amazon.com




On Oct 6, 2021, at 2:01 PM, Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> 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,

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

> 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 
wrote:

> 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 
> 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.
>>
>> 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 
>> 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/
>>
>> Please, provide your feedback on the mailing list by* October 20th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> Manage My Preferences , Unsubscribe
>> 
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Ash Narayanan]

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 
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.
>
> 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 
> 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/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Manage My Preferences , Unsubscribe
> 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

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  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/
> 
> Please, provide your feedback on the mailing list by October 20th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences , Unsubscribe 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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 .


On Thu, Oct 7, 2021 at 11:03 AM Denis  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
>
> ᐧ
>
> On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki  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  wrote:
>>
>>> 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  

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

[Denis]

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 > 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 mailto:dick.ha...@gmail.com>> wrote:

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 mailto:jric...@mit.edu>> wrote:

> 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
mailto:dick.ha...@gmail.com>> wrote:

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
mailto:aa...@parecki.com>> wrote:

I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef
mailto:rifaat.s.i...@gmail.com>> 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 

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

[Dick Hardt]

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  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  wrote:
>
>> 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  wrote:
>>
>>> > 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  wrote:
>>>
>>> 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  wrote:
>>>
 I support adoption of this document.

 - Aaron

 On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <
 rifaat.s.i...@gmail.com> 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/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

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  wrote:

> 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  wrote:
>
>> > 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  wrote:
>>
>> 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  wrote:
>>
>>> I support adoption of this document.
>>>
>>> - Aaron
>>>
>>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> 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/

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

 Regards,
  Rifaat & Hannes

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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  wrote:
> 
> 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  > wrote:
> > 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 > > wrote:
>> 
>> 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 > > wrote:
>> I support adoption of this document.
>> 
>> - Aaron
>> 
>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef > > 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/ 
>> 
>> 
>> Please, provide your feedback on the mailing list by October 20th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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  wrote:

> > 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  wrote:
>
> 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  wrote:
>
>> I support adoption of this document.
>>
>> - Aaron
>>
>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> 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/
>>>
>>> Please, provide your feedback on the mailing list by* October 20th*.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

> 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  wrote:
> 
> 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  > wrote:
> I support adoption of this document.
> 
> - Aaron
> 
> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef  > 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/ 
> 
> 
> Please, provide your feedback on the mailing list by October 20th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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  wrote:

> I support adoption of this document.
>
> - Aaron
>
> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef 
> 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/
>>
>> Please, provide your feedback on the mailing list by* October 20th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef 
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/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth