On Fri, Apr 11, 2025 at 12:18:14PM +0200, Filip Skokan wrote:
>
>
> Back to a general "freshness" mechanism. What if we designated an HTTP
> Response Header parameter applicable to *any* AS HTTP response that carries
> a currently accepted value? A client that regularly communicates with the
> AS
On Fri, Apr 25, 2025 at 5:49 AM Denis wrote:
>
> Hi Christian and Watson,
>
> Hi Watson,
>
>
>
> Sorry for the late response. I would fully agree that challenge would be the
> better term here and there is a bit of ambiguity for the term nonce in OAuth
> imho.
>
> +1 Yes, for a nonce sent by th
Hi Christian and Watson,
Hi Watson,
Sorry for the late response. I would fully agree that challenge would
be the better term here and there is a bit of ambiguity for the term
nonce in OAuth imho.
+1 Yes, for a nonce sent by the authorization server, the term
"challenge" would be a better
Hi Watson,
Sorry for the late response. I would fully agree that challenge would be the
better term here and there is a bit of ambiguity for the term nonce in OAuth
imho.
While a nonce generally speaking would usually mean a random input, in the
context of OAuth, it is afaik interpreted as an
Hi Filip,
answers are inline:
On 4/11/25 12:18, Filip Skokan wrote:
Hello Christian,
I've deployed the following optimization for DPoP on the AS in the
past that we may get inspired by. Given the DPoP "nonce" mechanism,
much like what we're talking about in the attestation based client
auth
Hello Paul,
For now, we haven't heard any blockers to the proposed solution using HTTP
> OPTIONS and no better solutions were proposed either.
I've mentioned in the meeting that using OPTIONS on endpoints which already
have CORS handlers is problematic because their OPTIONS HTTP method
handling
(Note that when endpoint responses are being cached of course a challenge
cannot be indicated in its headers, but we'd still have the "do the request
without credentials" when you don't have a value to use option available as
well as being able to indicate the current challenge in all other
non-cac
Hello Christian,
I've deployed the following optimization for DPoP on the AS in the past
that we may get inspired by. Given the DPoP "nonce" mechanism, much like
what we're talking about in the attestation based client authentication
context here, is to ensure freshness and not be a real "number u
Since Christian raised an issue on github 5 days ago, I have provided a
detailed response at:
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104
I took a quick look at: draft-demarco-oauth-nonce-endpoint-00
*"Nonce*:
A random or pseudo-random number th
On Sat, Apr 5, 2025, 8:17 AM Christian Bormann wrote:
> Hi All,
>
>
>
> We had a discussion about a nonce fetching mechanism for the
> Attestation-Based Client Authentication draft at the
>
> IETF 122 session. Since we didn’t really reach a consensus there, we’d
> like to continue the discussion
Bormann
Cc: oauth
Betreff: [OAUTH-WG] Re: Nonce fetching mechanism for Attestation-Based Client
Authentication
Giuseppe and Orie have a draft that might be relevant to this discussion, as it
describes a dedicated nonce endpoint:
https://www.ietf.org/archive/id/draft-demarco-oauth-nonce
Giuseppe and Orie have a draft that might be relevant to this discussion,
as it describes a dedicated nonce endpoint:
https://www.ietf.org/archive/id/draft-demarco-oauth-nonce-endpoint-00.html
Regards,
Rifaat
On Sat, Apr 5, 2025 at 11:16 AM Christian Bormann wrote:
> Hi All,
>
>
>
> We had a
12 matches
Mail list logo
