> Le 15 nov. 2022 à 10:50, Pawel Kowalik <[email protected]> a écrit : > > Hi Scott, > > Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott: >> [SAH] Based on the testing you and I've been doing, we already know that web >> service clients require token processing features that aren't currently >> specified. That's fixable; earlier versions of the draft included text that >> was demonstrated to work. However, we also know that login processing will be >> a problem if the client-side application can't process third-party cookies. >> That might be more difficult to overcome. What do you have in mind? > > I think for web clients we need to let the clients do the OAuth2 flow on > their own, receive tokens from the IdP directly and then use the token to > interact with the RDAP server. > RDAP server would remain stateless and session-less in the role of OAuth2 > resource server when tokens are in use. > The draft would be limited to defining profile of the OAuth2 protocol to > maintain interoperability (scopes / claims or flows / endpoints that need to > be supported etc.) as well as the discovery part of the IdP (likely just a > property add to what we have in /help already).
A "pure OAuth2" solution is probably way more warrant of future, IMHO. Marc. > This is different to our approach so far, when we tried to maintain > cookie-based session, letting RDAP server to act as Relying Party, and same > time operate with tokens as if it were a Resource Server. > > Kind Regards, > > Pawel > > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
