[OAUTH-WG] Last Call: (OAuth 2.0 Authorization Server Issuer Identification) to Proposed Standard

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 action.

Re: [OAUTH-WG] AD review of draft-ietf-oauth-iss-auth-resp-02

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

[OAUTH-WG] AD review of draft-ietf-oauth-iss-auth-resp-02

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 a

[OAUTH-WG] DPoP Interim Meeting Minutes

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 https://www.ietf.org/mailman/

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

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 eff

Re: [OAUTH-WG] DPoP and OAuth2 extensions

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 being

Re: [OAUTH-WG] DPoP - access token hash format

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

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

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 natural

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

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 pr

[OAUTH-WG] DPoP and OAuth2 extensions

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 Ex

[OAUTH-WG] DPoP - access token hash format

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 use

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

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 "invalid_dpo