Hi folks,
I think the first point we need to discuss is if we should introduce two
conformance tags for this extension:
- "rdap_openidc_level_0" used by RDAP servers to signal that they
implement SSO through the OIDC services provided by a local OP
- "rdap_federation_level_0" used by RDAP servers to signal that they
implement SSO through the OIDC services provided by a set of trusted
external OPs
To start a SSO session with a server that is rdap_openidc_level_0
conformant, an end user operating through a web browser:
- sends a query to /tokens endpoint of the RDAP server without the id
parameter
- is authenticated by the local OP (i.e. by filling out the login form)
- receives the access_token and uses it as either bearer or query
parameter for submitting requests towards standard endpoints of the RDAP
server
- requests for token refreshment and revoking without including the id
parameter
In this scenario, the id parameter is ignored.
To start a SSO session with a server that is rdap_federation_level_0
conformant, an end user operating through a web browser:
- sends a query to /tokens endpoint of the RDAP server including the id
parameter
- is authenticated by the OP discovered through the OpenID Discovering
process (i.e. by filling out the login form)
- receives the access_token and uses it as either bearer or query
parameter for submitting requests towards standard endpoints of the RDAP
server
- requests for token refreshment and revoking including the id parameter
In this scenario, the id parameter is required.
Some futher considerations support my proposal of splitting the
conformance in two:
1) AFAIK, the available OPs provide built-in OIDC features supporting
the implementation of the Authorization Code Flow. But this doesn't
apply for the features required to implement federation such as OP
discovery and dynamic client registration. Therefore, while SSO could be
implemented without knowing OIDC in depth, RDAP developers on server
side should tackle the implementation of a federation at a lower level.
2) Joining a federation doesn't only imply the implementation of such
additional OIDC features but also an agreement between all the parties
involved as it is described in
https://openid.net/specs/openid-connect-federation-1_0.html
<https://openid.net/specs/openid-connect-federation-1_0.html>. For this
reason, it seems to me that a federation represents a layer upon the
implementaion of OIDC to support authentication and SSO.
3) Currently, some OPs provide support external authentication through
other mechanisms (e.g identity brokering, social login). Briefly,
instead of discovering the OP from a user identifier, the user is
directly requested to select in a list of trusted OPs the one which will
be in charge of the authentication.
Hope it could be helpful to move the discussion forward.
Best,
Mario
Il 08/11/2021 13:54, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: I-D-Announce <i-d-announce-boun...@ietf.org> On Behalf Of
internet-dra...@ietf.org
Sent: Monday, November 8, 2021 7:45 AM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-08.txt
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.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the
IETF.
Title : Federated Authentication for the Registration Data
Access
Protocol (RDAP) using OpenID Connect
Author : Scott Hollenbeck
Filename : draft-ietf-regext-rdap-openid-08.txt
Pages : 25
Date : 2021-11-08
Abstract:
The Registration Data Access Protocol (RDAP) provides "RESTful" web
services to retrieve registration metadata from domain name and
regional internet registries. RDAP allows a server to make access
control decisions based on client identity, and as such it includes
support for client identification features provided by the Hypertext
Transfer Protocol (HTTP). Identification methods that require
clients to obtain and manage credentials from every RDAP server
operator present management challenges for both clients and servers,
whereas a federated authentication system would make it easier to
operate and use RDAP without the need to maintain server-specific
client credentials. This document describes a federated
authentication system for RDAP based on OpenID Connect.
[SAH] Folks, this update includes some significant changes that were designed
to align the specification more closely with both OpenID Connect and the web
services architecture. For example, the ID of the query requestor can now be
sent to the server in an HTTP authorization header OR a query parameter. The
token management bits were also changed to include a refresh token in the
/tokens response. Thanks to Mario Loffredo for the suggestions included in this
update.
Mario had some other suggestions that I haven't yet implemented. I encouraged
him to share them with the list so we could have a broader discussion. Mario,
please start that discussion at your convenience.
Direct link to diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-openid-08
Scott
_______________________________________________
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
