> -----Original Message----- > From: Pawel Kowalik <[email protected]> > Sent: Friday, December 2, 2022 9:45 AM > To: Hollenbeck, Scott <[email protected]>; [email protected]; > [email protected] > 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 30.11.22 um 17:39 schrieb Hollenbeck, Scott: > >> -----Original Message----- > >> From: Pawel Kowalik <[email protected]> > >> Sent: Wednesday, November 30, 2022 11:15 AM > >> To: Hollenbeck, Scott <[email protected]>; > >> [email protected]; [email protected] > >> 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, > >> > >> I have a bit of difficulty with those definitions. > >> > >> I think this starts with the definition of a client. > >> > >> RFC 2616 defines it as follows: > >> > >> client > >> A program that establishes connections for the purpose of sending > >> requests. > >> > >> user agent > >> The client which initiates a request. These are often browsers, > >> editors, spiders (web-traversing robots), or other end user tools. > > [SAH] The draft inherits a definition of "client" from RFC 7480. > > That's spelled out in the "terminology" section. > > [PK2] Indeed I overlooked that. The definition in RFC 7480 actually refers to > HTTP user agent, so RFC 2616 definition. > > > >> RFC 6749 has a different definition: > >> > >> An application making protected resource requests on behalf of the > >> resource owner and with its authorization. The term "client" does > >> not imply any particular implementation characteristics (e.g., > >> whether the application executes on a server, a desktop, or other > >> devices). > >> > >> > >> When we now talk of "session-oriented" clients, we actually mean "user > >> agent" > >> as per RFC 2616 which supports cookies for session management, whereas > >> "token-oriented" clients are in fact clients in sense of RFC 6749. > > [SAH] OK, so what's the best way to identify these two types of clients in > > the > > draft given the RDAP definition of "client" found in RFC 7480? > > [PK2] My proposal: > > Clients that want to delegate OIDC Authentication to RDAP server as part of > session-oriented interactions and can accept and process HTTP cookies > [RFC6265] to maintain the session are known as "session-oriented" clients. > This > type of RDAP client performs the role of user agent [RFC2616]. An RDAP server > performs the role of an OpenID Connect Core Relying Party (RP). A web > browser used to send queries directly to an RDAP server is an example of a > session-oriented client. > > Clients that perform OIDC Authentication directly taking the role of an RP in > interactions with an OP and send access tokens [RFC6749] to an RDAP server to > authorize RDAP queries are known as "token-oriented" clients. An RDAP server > performs resource server functions [RFC6749] to verify the tokens received > from the client and RP functions to retrieve information from the OP as > necessary to make access control decisions. A web browser running JavaScript > received from a web service that sends queries to an RDAP server directly or > through its backend web service is an example of a token-oriented client.
[SAH] Thanks, this works for me. I'll get it into -20. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
