The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Authorization Server
Issuer Identification'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this
Would making it even simpler also work? (and is more consistent with the
6749 language)
>
> The decision of whether to accept such responses is beyond the scope of
> this specification.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress
Hi!
I performed an AD review of draft-ietf-oauth-iss-auth-resp-02. Thanks for
documenting this mitigation.
The document is in good shape so I am advancing it to IETF LC. Please treat
these minor comments as part of that feedback:
** Section 2.4. Editorial.
The decision of whether to
All,
Thanks to *Hannes* and *Dick* for taking the following notes during the
DPoP Interim meeting today.
https://notes.ietf.org/s/notes-ietf-interim-2021-oauth-14-oauth
Regards,
Rifaat
___
OAuth mailing list
OAuth@ietf.org
Thanks for pointing out the Oblivious draft Justin. It is interesting, but
looks to be focussed on privacy rather than non-repudiation. Was I missing
non-repudiation aspects?
ᐧ
On Sat, Oct 23, 2021 at 4:55 PM Justin Richer wrote:
> Dick, you would probably be interested in the Oblivious HTTP
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html#name-dpop-access-token-request
is pretty clear (I think?) that DPoP is applicable with all token endpoint
requests of any grant type.
I don't know what would be said about Token Revocation.
I'm not seeing the UserInfo endpoint as
There's discussions around this in the mail and meeting archives, if you
want to dig into it. But generally the "at_hash" approach has proven to be
complicated while not really achieving the algorithm agility it aims for.
We opted for something more straightforward with "ath" in DPoP.
On Wed, Oct
I would express a mild preference for “invalid_token” taking priority in this
case. It seems pointless for the client to generate a new DPoP proof (in
response to invalid_dpop_proof) if they are then going to get an invalid_token
on the next request anyway. If they get a new AT they will
It's really just an implementation choice, I think.
On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin wrote:
> Any updates on this one? As of -04 we have a clear distinction between
> "error=invalid_token" and "error=invalid_dpop_proof", so the question could
> be reworded like this:
> - if DPoP
The draft currently focuses on DPoP support in Authorization endpoint and
Token endpoint (authorization code grant + refresh token grant). The
concept, however, could be extrapolated to several other endpoints, grant
types and OAuth2 extensions:
- ROPC (RFC 6749 section 1.3.3);
- OAuth 2.0 Token
As of -03, the "ath" DPoP proof claim has been introduced:
ath: hash of the access token (REQUIRED). The value MUST be the result of a
> base64url encoding (with no padding) the SHA-256 hash of the ASCII encoding
> of the associated access token's value.
>
OpenID Connect has a similar concept
Any updates on this one? As of -04 we have a clear distinction between
"error=invalid_token" and "error=invalid_dpop_proof", so the question could
be reworded like this:
- if DPoP proof is used in combination with access token, and both are
invalid, which one of the "invalid_token" and
12 matches
Mail list logo
