Hi Scott, Pavel and everyone else,
my humble opinion is that this document shouldn't deal with any kind of
RDAP client other than a browser.
One reason is for consistency with the choice of omitting the automatic
clients which will likely be significantly more than the clients based
on a web interface.
Another one is that we should address the registered clients
separately. Indeed, these clients comply with the classic OpendID
scheme where registered applications, acting as RPs, request OPs for
access tokens and, then, attach those tokens as bearer in their requests
to a resource server. Since such a scheme can hardly be applied when an
end user interacts with an RDAP server through a browser, this document
provides a feasible and user-friendly solution based on sessions.
That said, for the sake of simplicity, I would trace all the cases where
the RDAP client is an application back to that classic scheme.
After all, the registration with the OPs would be needed for the RDAP
clients as is for the RDAP servers in this OpenID implementation.
Obviously, as a result, the servers should be able to handle both
sessions and bearer tokens.
Best,
Mario
Il 07/10/2022 15:47, Pawel Kowalik ha scritto:
Am 07.10.2022 um 14:49 schrieb Hollenbeck, Scott
<shollenb...@verisign.com>:
*From:* regext <regext-boun...@ietf.org> *On Behalf Of *Pawel Kowalik
*Sent:* Thursday, October 6, 2022 7:24 PM
*To:* Andrew Newton <a...@hxr.us>
*Cc:* regext@ietf.org
*Subject:* [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17
*Caution:*This email originated from outside the organization. Do not
click links or open attachments unless you recognize the sender and
know the content is safe.
Comment inline
On Thu, Oct 6, 2022 at 8:22 AM Pawel Kowalik <kowa...@denic.de>
<mailto:kowa...@denic.de> wrote:
In my opinion the WG shall get the consensus around whether
these web
application related use-cases shall be supported in order to
move
forward with the WGLC.
Can you elaborate on what you mean by "web application"? Do you mean
an application that is not the user-agent?
Either an application running directly in the browser, like SPA, or
the application running on the server side and just rendered in the
browser.
*/[SAH] Let me try to check my understanding: what you’re describing
is a situation in which the RDAP client is software running on a web
server, right? If so, the RDAP-client-side web server (call it WS1)
needs to manage sessions for its users, and the web server that’s
running the RDAP server (call it WS2) needs to manage sessions for
its clients. The challenge here is that the only “client” the RDAP
server sees is WS1, and it has no knowledge of WS1’s users. To
identify, authenticate, and authorize the users of WS1, we need
features that support definition of sessions for those users on both
WS1 and WS2. Is that correct?/*
*//*
Not exactly. The users (or the user agent they use to be exact) of WS2
have both the session with WS1 and WS2, just that WS1 cannot access
WS2 with the same session because of the isolation by the user agent.
The user agent won’t send the session cookie it has with WS2 to WS1
because it would be cross domain.
Kind regards
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
