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

[Warren Parad <[e-mail]>]

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 <https://authress.io/>.


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

>
> inline
>
> On Fri, Oct 8, 2021 at 2:00 PM Richard Backman, Annabelle <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>