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
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
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
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
(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
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
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
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
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
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
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
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
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
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
wly 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
>
n’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
> *Subje
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
-- 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
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
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
> 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
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
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,
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
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
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
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
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
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
> 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
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,
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:
>
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
33 matches
Mail list logo
