Thanks for the questions, Ed! I'll respond below. Scott
> -----Original Message----- > From: Edward Shryane [mailto:[email protected]] > Sent: Monday, July 18, 2016 11:05 AM > To: Hollenbeck, Scott > Cc: [email protected] > Subject: Re: [regext] Implementation Status for RDAP Federated > Authentication > > Hi Scott, > > firstly, thanks for your work on this draft RFC. Authenticated access > to RDAP would be very useful, not just for access control, but also for > rate limiting for example. > > I have some questions, apologies if these are OpenID specific rather > than your draft. > > - Section 3.1.2. (Overview) > > Q. Are all steps performed per-request, or can the RDAP client re-send > the Authorization Code on subsequent requests (i.e., can any steps be > skipped) ? I would ask my implementers to provide more detail if asked, but my understanding is that it is indeed possible to ship some of the steps once the needed tokens have been acquired. > Q. Is any other information from the OpenID Provider (OP) visible to > the client? For example, the Access Token or ID Token (again for use in > subsequent requests). A client using a web browser won't normally see the tokens. We've added a path segment to the draft to expose the tokens so they can be used and reused as appropriate, or exposed for use by a non-browser client. > Q. Is the Subject Identifier contained in the response from the Token > Endpoint? Or is it retrieved using a separate request to the UserInfo > Endpoint? It's contained in the ID Token received from the Token Endpoint: http://openid.net/specs/openid-connect-core-1_0.html#IDToken > - Section 3.1.3.4. > > Q. "the OP will send a response to the RP" - is this done indirectly, > by returning a HTTP redirect to to the RDAP client, back to the RP? It's a direct response: http://openid.net/specs/openid-connect-core-1_0.html#AuthResponse > - Section 3.1.4 > > Q. To be clear, the OpenID provider needs to be "RDAP aware", so needs > to ask the user's consent, and return the "Purpose" claim to the RDAP > server? This would be the desired state for Ops used to provide more detailed information to RPs. You can, however, make access control and authorization decisions based on OP responses that don't included (for example) a stated purpose. End users using these providers will likely not have access to more privileged information. This is one of the reasons Verisign is running an identity provider as part of our experiment. We want to modify the code to add support for the concepts included in the draft. > Q. Since the Purpose Claim is optional, can the RDAP server use an > existing (standard) OpenID provider claim instead? Yes. Receiving software can do what they wish with such claims. > - Section 4.2. (Token Request and Response) > > Q. Is an RDAP client required to request a token, in order to maintain > a session with the RDAP server? Versus the process in Section 3.1.2. Required? Not necessarily, but they behavior would depend on your client implementation and if or how it stores such information in a storage device like an HTTP cookie. The text in 4.2 is there to explain how the tokens can be acquired and managed manually, so to speak. > - Section 5 (Non-Browser Clients) > > I'm interested in any way to make non-browser client access easier, is > an initial browser session required to grant consent and obtain a > token? Based on my understanding of the OAuth and OpenID Connect protocols, yes. There was some discussion of a "Device Flow" in yesterday's OAuth WG meeting: https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 https://developers.google.com/identity/protocols/OAuth2ForDevices It sounds promising because the described clients include "devices which do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs)" (and perhaps CLIs?). Read further, though, and you'll note that this flow requires a secondary device that has access to a browser. I don't yet think we have a good solution that doesn't require a browser. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
