Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-08.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 8 Dec 2021 18:26:12 +0000

Mario, I've been thinking about this a bit and I have a slightly different 
proposal to suggest. See below.

> -----Original Message-----
> From: Mario Loffredo <[email-masked]>
> Sent: Monday, November 8, 2021 3:58 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [regext] 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.
>
> 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

[SAH] I'd like to keep these values aligned to note the distinction between 
support for a local OP and eternal Ops. What about something like this?

rdap_openidc_local_level_0 (or maybe "internal" instead of "local")
rdap_openidc_remote_level_0 (or maybe "external" instead of "remote")

A server could support one or both of these. If only one is supported, the 
client will need to send queries a certain way as described below. If both are 
supported, the client can send queries without the id parameter to use the 
local OP, and with the id parameter to use a remote OP.

Note that this means that a server that supports rdap_openidc_local_level_0 
can't distinguish between a query for which authentication is requested and a 
query without an authentication request. A query without the id parameter will 
look like a "standard" RDAP query. Is that a feature or a bug?

> 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.

[SAH] I think this can work.

> 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://secure-
> web.cisco.com/1AiNimHMRDqyGq6nNCI91cEqZf7PLMIrmUHbkI4btU0sRrip4
> AW1qNN_YMODP0CmNuliOoJ7fuyFIt-GQ1SZP7p1L-
> pqtnzM1xJYVW_aCjmgpkGv1-
> Dj85TSQZJMGwN5sC8HJlSeSS6oBGm2h8CrdP3bNwyJ9ZQKLJfyNRQctjUEcD7f
> RVjau74HIK0rYw1IiHgeEZKnkcxMjLbPfga7539mKjrKC9kja7iZ6Lbc4L0T65N_2y
> OHh_KEvyY-0y2KRNHM-VqtNhnJZGtu0c-WXTzHdQR5fZyIe-
> Av7LnwuHuk/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
> federation-1_0.html
> <https://secure-
> web.cisco.com/1AiNimHMRDqyGq6nNCI91cEqZf7PLMIrmUHbkI4btU0sRrip4
> AW1qNN_YMODP0CmNuliOoJ7fuyFIt-GQ1SZP7p1L-
> pqtnzM1xJYVW_aCjmgpkGv1-
> Dj85TSQZJMGwN5sC8HJlSeSS6oBGm2h8CrdP3bNwyJ9ZQKLJfyNRQctjUEcD7f
> RVjau74HIK0rYw1IiHgeEZKnkcxMjLbPfga7539mKjrKC9kja7iZ6Lbc4L0T65N_2y
> OHh_KEvyY-0y2KRNHM-VqtNhnJZGtu0c-WXTzHdQR5fZyIe-
> Av7LnwuHuk/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-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.

[SAH] Agreed. What do others think?

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 9 Dec 2021 15:09:05 +0100

Hi Scott,

please find my comments inline.

> rdap_openidc_remote_level_0 (or maybe "external" instead of "remote")
Sounds good.
> look like a "standard" RDAP query. Is that a feature or a bug?

What does it mean "standard"? If it means coming from an anonymous user, 
the response is no; it wouldn't look like an anonymous request as the 
draft states that using the id parameter is only one method to submit an 
authenticated request according the draft.

The other (the reference method in OIDC) is including a valid access 
token in the request.

Otherwise, the same request provided as an example in section 4.2 should 
be considered anonymous but it isn't.

The difference in dealing with an authenticated/anonymous request mainly 
depends on two factors:

- if the request is directed towards a protected endpoint or not

- if the request includes an access token or not

If an endpoint is considered protected, to submit an authenticated 
request you need to include an access token in the request or to be 
previously authenticated by the OP and then redirected back to the endpoint.

In .it implementation, the standard endpoints are all considered 
protected. If you want to access one of them as an authenticated user, 
you need to include an access token otherwise you are marked as anonymous.

The /tokens endpoint is the only one requiring an authentication by the 
OP. So the logic is: firstly take an access token after being 
authenticated by the OP and then use it to submit authenticated requests 
to the standard endpoints.

This is also the logic of SSO.

The requests towards /tokens used for refreshing and /tokens/revoke are 
transformed in requests coming from an anonymous user because, in these 
cases, the server needs only to check for the tokens' validity.

In your model, the server also accepts (let's call them) one-shot 
authenticated requests. Such requests always make the OP authenticate 
the user before they are redirected to the server.

Best,

Mario

> _______________________________________________
> regext mailing list
> [email-masked]
> 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