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). 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
