Subject: [weirds] Comments on draft-ietf-weirds-rdap-sec

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 00:03:27 -0700

Hi,

I've reviewed this draft.  It looks pretty much ready to go.

My only question is about Section 3.1.1 which talks about federated
authentications.  All of the 3.x sections except this one are of the form
"RDAP needs to do X, so here's how you do X".  This one describes federated
authentication and says that an RDAP server might do it if it wants to, and
lists a few ways to do so (OAuth, OpenID).  I'm not totally familiar with
these, so this might be a naive question: Is there any need for us to
include a mechanism by which an RDAP server can be discovered to be part of
such a federation?  For example, should an RDAP client be able to contact,
say, rdap.arin.net and discover that it's federated with LACNIC's server
via an arrangement using OAuth?  Or is that sort of thing arranged and
discovered completely out of band?

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Sep 2014 12:54:43 +0000

From: weirds [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, September 15, 2014 3:03 AM
To: [email-masked]
Subject: [weirds] Comments on draft-ietf-weirds-rdap-sec

Hi,
I've reviewed this draft.  It looks pretty much ready to go.
My only question is about Section 3.1.1 which talks about federated authentications.  All of the 3.x sections except this one are of the form "RDAP needs to do X, so here's how you do X".  This one describes federated authentication and says that an RDAP server might do it if it wants to, and lists a few ways to do so (OAuth, OpenID).  I'm not totally familiar with these, so this might be a naive question: Is there any need for us to include a mechanism by which an RDAP server can be discovered to be part of such a federation?  For example, should an RDAP client be able to contact, say, rdap.arin.net<http://rdap.arin.net> and discover that it's federated with LACNIC's server via an arrangement using OAuth?  Or is that sort of thing arranged and discovered completely out of band?
[SAH]  I’m not familiar enough with automated service discovery to say for sure, but the searching I did right now seems to imply that manual steps are required. The OAuth 2.0 authorization framework specified in RFC 6749 says that “this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery)”. Ning, you were the proponent for adding this section. Can you answer Murray’s question definitively?

Scott

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2014 21:09:51 -0000

>such a federation?

Short answer: yes;

Longer answer: whatever the answer is for RDAP would be the same
answer for every other service that uses federated authentication.

The whole federated thing is in major flux.  It was my idea in the
first place to mention it, but I don't think it would be a good idea
for us to get ahead of the people who are working on the underlying
technologies.  Hence the unsatisfying language that says it would be
nice, but not how to do it.

R's from Bucharest,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 15:01:08 -0700

> nice, but not how to do it.

So we have to hand-wave on this because it's not currently possible to give
a more definite answer?

That's fine if it's the case; I just want to have the back story in case we
get asked.

-MSK

---

From: Ning Kong <[email-masked]>
Date: Tue, 16 Sep 2014 22:35:40 +0800

> My only question is about Section 3.1.1 which talks about federated authentications.  All of the 3.x sections except this one are of the form "RDAP needs to do X, so here's how you do X".  This one describes federated authentication and says that an RDAP server might do it if it wants to, and lists a few ways to do so (OAuth, OpenID).  I'm not totally familiar with these, so this might be a naive question: Is there any need for us to include a mechanism by which an RDAP server can be discovered to be part of such a federation?  For example, should an RDAP client be able to contact, say, rdap.arin.net and discover that it's federated with LACNIC's server via an arrangement using OAuth?  Or is that sort of thing arranged and discovered completely out of band?

Hi Murray, I think this kind of mechanism you supposed is useful but it is now out of scope for the current federated authentication protocols (OAuth, OpenID). As far as I know, this kind of mechanism is usually implemented by current web applications through some out of band ways.

Cheers,
Ning

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Sep 2014 09:17:01 -0700

On Tue, Sep 16, 2014 at 7:35 AM, Ning Kong <[email-masked]> wrote:

> Hi Murray, I think this kind of mechanism you supposed is useful but it is
> now out of scope for the current federated authentication protocols (OAuth,
> OpenID). As far as I know, this kind of mechanism is usually implemented by
> current web applications through some out of band ways.
>
>
Is it worth adding a sentence or two indicating this in the document?
Something like "At the time of this document's publication, negotiation or
advertisement of federated authentication services is a developing
mechanism and is therefore not discussed here."

It's not critical that this be added, just a suggestion.  I just feel like
we point to this cool idea and then say absolutely nothing further about
how to use it with RDAP.  If that's the best we can do right now, it might
be useful to say so.

Thanks,
-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 16 Sep 2014 17:10:26 +0000

From: weirds [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, September 16, 2014 12:17 PM
To: Ning Kong
Cc: [email-masked]
Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-sec

On Tue, Sep 16, 2014 at 7:35 AM, Ning Kong <[email-masked]<mailto:[email-masked]>> wrote:
My only question is about Section 3.1.1 which talks about federated authentications.  All of the 3.x sections except this one are of the form "RDAP needs to do X, so here's how you do X".  This one describes federated authentication and says that an RDAP server might do it if it wants to, and lists a few ways to do so (OAuth, OpenID).  I'm not totally familiar with these, so this might be a naive question: Is there any need for us to include a mechanism by which an RDAP server can be discovered to be part of such a federation?  For example, should an RDAP client be able to contact, say, rdap.arin.net<http://rdap.arin.net/> and discover that it's federated with LACNIC's server via an arrangement using OAuth?  Or is that sort of thing arranged and discovered completely out of band?
Hi Murray, I think this kind of mechanism you supposed is useful but it is now out of scope for the current federated authentication protocols (OAuth, OpenID). As far as I know, this kind of mechanism is usually implemented by current web applications through some out of band ways.

Is it worth adding a sentence or two indicating this in the document?  Something like "At the time of this document's publication, negotiation or advertisement of federated authentication services is a developing mechanism and is therefore not discussed here."
It's not critical that this be added, just a suggestion.  I just feel like we point to this cool idea and then say absolutely nothing further about how to use it with RDAP.  If that's the best we can do right now, it might be useful to say so.

[SAH] That seems reasonable.

Scott

---

From: Ning Kong <[email-masked]>
Date: Wed, 17 Sep 2014 10:23:26 +0800

> [SAH] That seems reasonable.
+1

IMO, although the OAUTH WG is still developing several working group documents (e.g. draft-ietf-oauth-dyn-reg-20, draft-ietf-oauth-dyn-reg-management-05), these working group documents don’t actually cover the mechanism we’re discussing. It seems to me that such mechanism is out of scope of the current charter of the OAUTH WG. So I’m afraid the word “developing” is appropriate.

So, if we’d like to add some text on this issue, I prefer the following modified text based on Murray’s.

At the time of this document's publication, negotiation or advertisement of federated authentication services is still an undefined mechanism by the above federated authentication protocols. Developing this mechanism is beyond the scope of this document. 

Any comments or suggestions to update the above text are welcome.

Cheers,
Ning

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Sep 2014 19:32:39 -0700

On Tue, Sep 16, 2014 at 7:23 PM, Ning Kong <[email-masked]> wrote:

>
> At the time of this document's publication, negotiation or advertisement
> of federated authentication services is still an undefined mechanism by the
> above federated authentication protocols. Developing this mechanism is
> beyond the scope of this document.
>
>
>
Works for me, thanks!

-MSK