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

[Warren Parad <[e-mail]>]

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


On Thu, Oct 14, 2021 at 4:51 PM Justin Richer <[e-mail]> 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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>