Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

o revoke the tokens when not agreed upon. If any malicious party would get hold of my tokens, I wish they would only use them to revoke them. A leaked token should be revoked anyway. One could even argue that the grant for the original client should also be revoked in this case as well, because it

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

Revoking the token seems to be the least harmful one can do with a token. For more information see: https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I/ Best regards, Emond Papegaaij > > On Aug 22, 2021, at 5:14 AM, RFC Errata System < > rfc-edi...@rfc-editor

Re: [OAUTH-WG] Client authentication on token revocation

bearer tokens, we will simply skip the validation of the client credentials. Best regards, Emond Papegaaij On Thu, Aug 20, 2020 at 12:52 PM Torsten Lodderstedt wrote: > > Hi Emond, > > I tend to agree with your assessment. Revoking bearer tokens without client > authenticat

[OAUTH-WG] Client authentication on token revocation

regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt

should NOT be allowed (inline scripting, eval). This was already mentioned by Dominick Baier. Also, it could benefit from a few examples (correct and wrong). Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

changed as well. It is complex due to so little > existing token lifetime/policy guidance to reference. Previous > conversations went a bit circular IMHO because of a lack of ground rules. I can understand. This also highly depend on your use case. Something that might work for one application might be totally inappropriate for another. Best regards, Emond Papegaaij ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Exchange status and Resource Indicators

the general form of a client identifier. Many of the client identifiers we use are UUIDs. There is no way to put this in the resource parameter on the authorize request. The library we use to implement our OAuth2 endpoints is very strict in this. Best regards, Emond Papegaaij

Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

Hi, Thanks for your detailed reply. I've replied inline. On maandag 6 mei 2019 22:42:09 CEST David Waite wrote: > On May 6, 2019, at 1:42 PM, Emond Papegaaij wrote: > > For a browser-based app, we try to follow the recommendations set in > > draft- > > ietf-oauth-b

[OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

achieving this? As I cannot believe we are the only ones facing this issue, maybe a recommendation can be put in the spec? Best regards, Emond Papegaaij ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Exchange status and Resource Indicators

On zondag 5 mei 2019 15:54:48 CEST you wrote: > On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij > > To summarize, I have to following questions: > > - Is the 'OAuth 2.0 Token Exchange' specification still active? > > Yes with the caveats mentioned above. I will sa

[OAUTH-WG] Token Exchange status and Resource Indicators

on still active? - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? - Can 'OAuth 2.0 Token Exchange' be updated to build on 'Resource Indicators for OAuth 2.0' rather than redefining the same parameters? Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Device flow error response

Hi Filip, Yes, this was exactly what I was thinking about. Good to know I'm working in the right direction. I must say that the spec reads really well and is fairly straightforward to implement. Best regards, Emond Papegaaij Topicus KeyHub On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan

[OAUTH-WG] Typo in Device flow 5.2

Hi all, It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 Device flow: As the device code is not displayed to the user and thus there are *NO* usability considerations on the length, a very high entropy code SHOULD be used. Best regards, Emond Papegaaij Topi

Re: [OAUTH-WG] OAuth 2.0 Device flow error response

s that may be useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. Best regards, Emond Papegaaij Topicus KeyHub On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell wrote: > > While probably

[OAUTH-WG] OAuth 2.0 Device flow error response

se. I would have expected a standard OAuth 2.0 error response, probably with the following error codes: invalid_request, invalid_client and invalid_scope. Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.iet