Subject: [regext] Implementation Status for RDAP Federated Authentication

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Jul 2016 11:15:46 +0000

Folks, with the just-announced publication of RFC 7942/BCP 205, I'm planning to add an "Implementation Status" section to my RDAP federated authentication draft*. If you've implemented the protocol specified in the draft and would like to be listed among the known implementations, please send (private email is fine) me the information described in Section 2 of RFC 7942. I'll update the draft after IETF-96. I'll be available in Berlin to talk to anyone who might be interested in talking about federated authentication for RDAP.

Scott

* https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/

---

From: Edward Shryane <[email-masked]>
Date: Mon, 18 Jul 2016 17:05:02 +0200

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

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

- 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?
Q. Since the Purpose Claim is optional, can the RDAP server use an existing (standard) OpenID provider claim instead?

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

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

Finally, I look forward to seeing implementations of this draft.

Regards
Ed Shryane
RIPE NCC

> On 12 Jul 2016, at 13:15, Hollenbeck, Scott <[email-masked]> wrote:
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 19 Jul 2016 13:11:26 +0000

Thanks for the questions, Ed! I'll respond below.

Scott

> -----Original Message-----
> From: Edward Shryane [mailto:[email-masked]]
> Sent: Monday, July 18, 2016 11:05 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> 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.
> 
> 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.

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

> 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