> -----Original Message----- > From: Pawel Kowalik <kowa...@denic.de> > Sent: Monday, November 21, 2022 6:22 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; mario.loffr...@iit.cnr.it; > regext@ietf.org > Subject: [EXTERNAL] Re: [regext] Web Service Client Flow > > 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 Scott, > > Am 18.11.22 um 14:01 schrieb Hollenbeck, Scott: > >> [...] > >>> I would strongly opt for this scenario, as most of the frameworks > >>> for resource server do not go well with multiple token issuer > >>> schema, so the implementation would be a way more complex RDAP > server side. > >> + 1 > > [SAH] Me too. This is MUCH easier if we don't have to worry about remote > OPs. > > [PK] Great, this simplifies a lot of things down the line. > > > > > Revised flow: > > > > The RDAP Web Service Client sends an RDAP "help" query to an RDAP > > server to determine the type and capabilities of the OpenID Providers > > (OPs) that are used by the RDAP server. > > The RDAP Web Service Client determines the End-User's OP and confirms > > that it's supported by the RDAP server. > > The RDAP Web Service Client sends an Authentication Request to the OP. > > The OP authenticates the End-User. > > The OP obtains End-User consent/authorization. > > The OP returns an Authorization Code to the RDAP Web Service Client. > > The RDAP Web Service Client requests tokens using the Authorization > > Code at the OP's Token Endpoint. > > The RDAP Web Service Client receives a response that contains an ID > > Token and an Access Token in the response body. > > The RDAP Web Service Client monitors the token validity period and > > either refreshes the token or requests new tokens as necessary. > > The RDAP Web Service Client sends queries that require user > > identification, authentication, and authorization to an RDAP server > > that include a JWT Access Token [RFC9068] in an HTTP bearer authorization > header. > [PK] In this scenario the access token does not need to be always "JWT Access > Token" > if the assumptions is that it is up to RDAP server to integrate with their > local > OP. > > The RDAP server validates the Access Token and retrieves the claims > > associated with the End-User's identity from the Access Token or the local > > OP. > [PK] Just a remark not to limit the text to JWT access token. Opaque tokens > can > also carry data obtainable through token introspection. This is again local > integration issue RDAP server - local OP which I see out of scope for our > draft. > > The RDAP server determines the End-User's authorization level and > > processes the query in accordance with the End-User's authorization level.
[SAH] Yes, you're right on both points. I'm taking a few vacation days this week, but I plan to work this into the next version of the draft and hope to publish that next week. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
