Hello Filip, my bad, you are right. "Compatible" was the wrong word to use.
Yes, a client implementing draft-sakimura-oauth-wmrm-01 would expect a different message structure than defined in our draft.
We are not fixed to the message structure in our current draft and are open to discuss adjusting it. That's the type of feedback we are asking for.
We would be very interested in the implementations of draft-sakimura-oauth-wmrm you mentioned. Can you point us to these implementations?
Best regards, Karsten On 10.01.2024 09:47, Filip Skokan 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:-- Karsten Meyer zu SelhausenHello 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/ * 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/* 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 SelhausenSenior 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-mfa https://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 SelhausenSenior 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-mfa https://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/oauthSenior 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-mfa https://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-mfa https://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
OpenPGP_0x4535C0E7DB16F148.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
