>
> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>
I agree, and therefore I think what it really ought to b
It may not be exactly the same issue Warren but it's definitely related.
"whether an AS knows about the client" is related to what Brian pointed out
about the AS identifying the client, which comes back to what I said
originally about how credentialed is currently defined in two parts:
a) Clients t
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
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
> On Oct 14, 2021, at 8:47 AM, Warren Parad
> wrote:
>
> I feel like there are a bunch of pieces of the implementation fundamentally
> missing here, so we are back to, as it is right now, the draft isn't
> sufficient.
Of course the draft isn’t sufficient for publication — that’s what the ca
I feel like there are a bunch of pieces of the implementation fundamentally
missing here, so we are back to, as it is right now, the draft isn't
sufficient. What prevents the signature from being used without this RFC?
How do you do expect the symmetric key exchange to be oauth compliant? How
does
I'm not sure this is exactly the issue, but I also found the naming of
*credentialed
client* to be confusing. It would seem to me we have an enum whose values
do not form an orthonormal basis. In other words, whether or not a client
is credentialed is independent from whether an AS knows about the
Hi Brian,
I'm all for pivoting, as long as the original concerns raised are addressed
or even acknowledged, but since they weren't, here is the original message
again in its entirety.
Cheers,
Ash
===
Referring to the latest draft (
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html)
