> Le 9 nov. 2022 à 18:39, Pawel Kowalik <kowa...@denic.de> a écrit : > > Hi Marc, > > Great point about the mobile app. This was not yet discussed and I must admit > I don't have a lot of practical experience in this area. > > I don't think the CLI use-case would be the fitting one, as you won't get the > best experience with the device flow in the web app, unless you are fine with > your user copy-pasting the code in the authorization flow to the IdP page. > Of course no. that was not obvious to me reading the slides.
> There was a very good presentation today in the OAuth group about it, along > the lines "don't use multi-device flows on the same device" and I think there > is a point about it. > > In my eyes a mobile app is more like a web app. > Yes. It is an http client, and can do whatever with its http connections: cookies, sessions, etc... > If I understand how the mobile app can be built, it would trigger the > authorization flow either with a built-in browser widget, or trigger the > OS-default browser for that. > Both are possible. > Not 100% sure about the first scenario, but for the second it would be > absolutely given that the app won't get access to the cookies set in the > browser session, therefore breaking the flow. The only exception are the apps > being actually SPAs running in a browser > Yeah, not those kind of « apps ». I was talking about « pure » mobile apps. One can also think of a mobile app like a desktop app. No difference to me. Both are http clients. Regards, Marc. > , then it's the same as a browser app - just no clue how the cookies are > handled: same-site or cross-site, but likely you can control it in your app. > > Kind Regards, > > Pawel > > Am 09.11.22 um 18:26 schrieb Marc Blanchet: >> Sorry I was not able to attend. But reading the slides, I just want to make >> sure the mobile app RDAP client is properly taken into account. I think this >> is the « CLI » use case described, but just want to make sure we properly >> cover the mobile app RDAP client (I wrote one… and intend to implement >> openid) >> >> Regards, Marc. >> >>> Le 9 nov. 2022 à 18:09, Pawel Kowalik <kowa...@denic.de> >>> <mailto:kowa...@denic.de> a écrit : >>> >>> Hi, >>> >>> >>> >>> Thanks for the participation in the meeting today. >>> >>> There are not yet any conclusions, which would be discussed in the WG >>> meeting tomorrow and likely after in the mailing list. >>> >>> Slides with the current status and possibilities to move forward are >>> attached. >>> >>> >>> >>> Kind Regards, >>> >>> Pawel >>> >>> >>> >>> >>> >>> Am 07.11.22 um 13:33 schrieb Pawel Kowalik: >>>> Hi Mario, >>>> >>>> Am 07.11.22 um 11:27 schrieb Mario Loffredo: >>>>> I'm very busy Wednesday but, hopefully, I should be free for that time. >>>> Great you can make it. >>>> >>>>> After a quick reading, a first big doubt from my side is about what is >>>>> stated in section 4 regarding "redirect URIs". >>>>> Browser-based applications: >>>>> * MUST Register one or more redirect URIs, and use only exact >>>>> registered redirect URIs in authorization requests >>>>> >>>>> Now, it's clear to me that, in the OpenID model we are working on, the >>>>> RDAP server acts as an RP and is the one submitting requests to th AS but >>>>> it can't use a fixed set if redirect_uri values. >>>> Yes, the security considerations part is still open. Applicability mostly >>>> depends on whether there are confidential and/or registered clients or >>>> not. If clients are anonymous there are certain risks >>>> related to the redirect_uri, which can only to some degree be mitigated. >>>> >>>> Kind Regards, >>>> >>>> Pawel >>>> >>> <IETF 115 Side Meeting RDAP OpenID >>> Status.pdf>_______________________________________________ >>> regext mailing list >>> regext@ietf.org <mailto:regext@ietf.org> >>> https://www.ietf.org/mailman/listinfo/regext >> >> >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
