Hi Scott,
Il 15/11/2022 17:54, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Marc Blanchet <marc.blanc...@viagenie.ca>
Sent: Tuesday, November 15, 2022 10:57 AM
To: Pawel Kowalik <kowa...@denic.de>
Cc: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115
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.
Le 15 nov. 2022 à 10:50, Pawel Kowalik <kowa...@denic.de> 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.
[SAH] ...but it's not OpenID Connect, which is the focus of the current draft.
Incorporating these concepts into the current draft could mean significant
change to generalize from "Federated Authentication for the Registration Data
Access Protocol (RDAP) using OpenID Connect" to "Federated Authentication for
the Registration Data Access Protocol (RDAP)" or "Federated Authentication for
the Registration Data Access Protocol (RDAP) using <something else>". I'm not
opposed to generalization if it produces a more complete specification, BUT:
OAuth doesn't do identification and authentication [1]. A "pure OAuth2"
solution would require *something else* to provide identification and
authentication. What can we use?
[1] https://oauth.net/articles/authentication/
Scott
Why wouldn't it be OpenID? On the contrary, I would say (as a matter of
fact have always said) that it's the classic OpenID scheme where the
RDAP server acts only as a Resource Server and the RDAP client as a
Relying Party.
We all know that OpenID is built on top of OAuth, hence it's absolutely
normal to talk about OAuth flow between the RDAP client and the RDAP
server because the authentication services are requested by the client
before submitting any request to the server. At that stage of OpenID
flow, authentication is over and only the authorization services (i.e
the OAuth flow) are needed.
Up to now, in order to address the use case of browser operating as RDAP
clients, we have forcefully requested the RDAP server to play two roles,
namely RS and RP, but it's unusual in the OpenID context.
In addition, the UserInfo endpoint (that the RDAP server can always
access) has been introduced by OpenID.
Best,
Mario
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. 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
