> > We do not consider the relay mode. The relay mode is motivated by the use > of the implicit grant which is discouraged nowadays.
Motivation aside, if my memory serves right (and that's a big IF in this case), the relay mode was not limited to implicit responses and was useful regardless of the response type, e.g. in cases where the authorization request was triggered from an eTLD+1 top level window but the target was authenticating a service that ran on its subdomain, a landing page with a CTA to login sort of setup. S pozdravem, *Filip Skokan* On Wed, 10 Jan 2024 at 09:47, Filip Skokan <panva...@gmail.com> wrote: > our draft covers and is compatible to what's called "simple mode" (both >> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01. > > > So a client that's using a simple mode with web_message today could, > without change, utilize your draft as well? That doesn't seem likely given > the message structure is not the same as in draft-sakimura-oauth-wmrm. Is > that an omission or intentional? > > S pozdravem, > *Filip Skokan* > > > On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen | Hackmanit < > karsten.meyerzuselhau...@hackmanit.de> wrote: > >> Hello Filip, >> >> our draft covers and is compatible to what's called "simple mode" (both >> with and without prompt) in draft-sakimura-oauth-wmrm-00/-01. >> >> We do not consider the relay mode. The relay mode is motivated by the use >> of the implicit grant which is discouraged nowadays. >> >> The main differences to draft-sakimura-oauth-wmrm-01 can be summarized >> as follows: >> >> - In general we do not focus on "modes" but instead on the actual >> communication using the postMessage API. Our draft contains examples for >> the format/structure for the messages sent using the postMessage API. >> - Our draft enables iframe flows with user interaction while >> draft-sakimura-oauth-wmrm-01 >> only covers iframe flows without user interaction. >> - Our draft contains security considerations describing threats and >> giving recommendations to address them. >> - Our draft briefly discusses the implications of the 3rd party >> cookie phaseout for iframes. >> >> Our main motivation is the belief that there is a need for a >> specification defining how to securely use the postMessage API for OAuth >> auth. responses. The research of my co-authors underlines this need [1]. >> >> As I said, at the last OSW there was agreement that it would be a good >> idea to write an RFC for a postMessage-based response mode. >> draft-sakimura-oauth-wmrm-00 >> was expired years ago and seemed to be inactive when we started to work on >> our own draft. In our opinion it is not a great option to rely on an >> expired draft. As for customers I work with this is not an option at all; >> they want to implement and use final RFCs whenever possible. >> >> We are looking for feedback from the WG and are open to collaborate with >> the authors of draft-sakimura-oauth-wmrm if they want to join the efforts. >> >> >> Best regards, >> Karsten >> >> [1] https://distinct-sso.com/ >> On 04.01.2024 12:10, Filip Skokan wrote: >> >> Hello Karsten, >> >> Can you summarize in what ways is your draft compatible >> with draft-sakimura-oauth-wmrm-00? Which of the described modes in Nat's >> document does it cover? >> >> There are existing implementations (both partial and full) >> of draft-sakimura-oauth-wmrm-00 so if your draft is not compatible I would >> recommend not using the same response mode name/identifier in your proposal. >> >> What prompted you to start a new draft rather than >> using draft-sakimura-oauth-wmrm-00? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen | Hackmanit < >> karsten.meyerzuselhau...@hackmanit.de> wrote: >> >>> Hi all, >>> >>> we would like to ask again for feedback on our draft for the >>> "web_message" response mode: >>> *https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/ >>> <https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/> >>> * >>> >>> We think it would be very helpful for implementers and developers to >>> specify a secure standard for a postMessage API-based response mode. >>> >>> Best regards, >>> Karsten >>> On 23.11.2023 10:11, Karsten Meyer zu Selhausen | Hackmanit wrote: >>> >>> Hi everyone, >>> >>> at the last OSW the topic of a response mode based on the postMessage >>> API came up. This approach is already used by multiple parties (e.g., >>> Google) but lacks standardization. >>> >>> There was some sense of agreement that it would be a good idea to create >>> an RFC defining this response mode to counter security flaws in individual >>> implementations and improve interoperability. >>> >>> Because the efforts in the past were long expired (draft -00 of >>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/ expired in >>> 2016) we took the initiative and started to work on a new ID for the >>> "web_message" response mode. >>> >>> *We would like to to ask the members of the working group for feedback >>> on our draft: >>> https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/ >>> <https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/>* >>> >>> >>> I see that "draft-sakimura-oauth-wmrm" has been recently updated. >>> However, there have not been any changes to its contents. What are the >>> plans of the authors for this draft? >>> >>> Best regards >>> Karsten >>> >>> -- >>> Karsten Meyer zu Selhausen >>> Senior IT Security Consultant >>> Phone: +49 (0)234 / 54456499 >>> Web: https://hackmanit.de | IT Security Consulting, Penetration >>> Testing, Security Training >>> >>> Multi-Factor Authentication (MFA) significantly increases the security of >>> your accounts. >>> Learn in our blog posts what the best MFA options are and how FIDO2 goes >>> one step further to solve the world’s password >>> problem:https://www.hackmanit.de/en/blog-en/162-what-is-mfahttps://www.hackmanit.de/en/blog-en/165-what-is-fido2 >>> >>> Hackmanit GmbH >>> Universitätsstraße 60 (Exzenterhaus) >>> 44789 Bochum >>> >>> Registergericht: Amtsgericht Bochum, HRB 14896 >>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. >>> Christian Mainka, Prof. Dr. Marcus Niemietz >>> >>> -- >>> Karsten Meyer zu Selhausen >>> Senior IT Security Consultant >>> Phone: +49 (0)234 / 54456499 >>> Web: https://hackmanit.de | IT Security Consulting, Penetration >>> Testing, Security Training >>> >>> Multi-Factor Authentication (MFA) significantly increases the security of >>> your accounts. >>> Learn in our blog posts what the best MFA options are and how FIDO2 goes >>> one step further to solve the world’s password >>> problem:https://www.hackmanit.de/en/blog-en/162-what-is-mfahttps://www.hackmanit.de/en/blog-en/165-what-is-fido2 >>> >>> Hackmanit GmbH >>> Universitätsstraße 60 (Exzenterhaus) >>> 44789 Bochum >>> >>> Registergericht: Amtsgericht Bochum, HRB 14896 >>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. >>> Christian Mainka, Prof. Dr. Marcus Niemietz >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> Karsten Meyer zu Selhausen >> Senior IT Security Consultant >> Phone: +49 (0)234 / 54456499 >> Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, >> Security Training >> >> Multi-Factor Authentication (MFA) significantly increases the security of >> your accounts. >> Learn in our blog posts what the best MFA options are and how FIDO2 goes one >> step further to solve the world’s password >> problem:https://www.hackmanit.de/en/blog-en/162-what-is-mfahttps://www.hackmanit.de/en/blog-en/165-what-is-fido2 >> >> Hackmanit GmbH >> Universitätsstraße 60 (Exzenterhaus) >> 44789 Bochum >> >> Registergericht: Amtsgericht Bochum, HRB 14896 >> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. >> Christian Mainka, Prof. Dr. Marcus Niemietz >> >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
