Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt

From: Ning Kong <[email-masked]>
Date: Wed, 5 Dec 2012 11:48:44 +0800

Hi Edward,

Thanks for your comments. Please see my feedbacks to Item #2 inline.

> Item #2
> 
> Section 3.1.1, federated authentication, seems to be an ill-fit in a requirements document.  The possible approaches are fine descriptions as far as they go, but, they aren't requirements.  It's not bad to place hold them here until there's a document detailing a solution or a solution approach, but - well, they aren't requirements.
> 
> But it's the requirement that is there that seems flakey.  I understand the utility of a federated authentication model but don't see how it is germane to the definition of this protocol.  I mean - authentication is merely the task of proving I am who I claim to be.  If this is done via a trusted third party that is trusted by many servers (in the sense that there are clients, servers and third parties), that is fine.
> 
> It's a good discussion to have, but I don't see it as a requirement.  I can see 3.1.1. being labeled as a note on how to build the authentication system.

IMHO, the sec draft is more than just a requirements document. So in this draft, we try to capture related everything, including not only requirements but also approaches, as discussed in the mailing list and IETF meeting.

Based on the related discussion, I think there are potential requirements on federated authentication and this topic might be in the scope of the sec draft. I agree that there would be some uncertain issues (e.g. detailed requirements and approaches) on this topic. I hope we can have further discussion based on the section 3.1.1 in order to make sure these uncertain issues. If necessary, I'm also fine to detail this topic in another document in future.

Cheers,
Ning

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2012 14:59:53 -0500

Hi Ning,

Continuing my preference for top posting.  (An old issue.):

Well, moving or reserving the text for another document isn't desirable - because that just gets messy.

And it is true that any document can discuss whatever it needs to - there's no need to restrict requirements documents to just requirements.

What I would float for comment is this -

Add a new header called Security Policy Options and move 3.1.1 under that.  The reason is that I don't see federated authentication as a necessity, i.e., not as a requirement per se.  There's nothing wrong with the idea of federated authentication, but in working through my use cases I don't see it as a part of my plans now.  (I'm only saying this to give you my frame of mind, others will likely disagree and I respect those differences.)

In my opinion, "federated" authentication is a statement about policy, which is one layer up in terms of protocol development.  We've been steering clear of policy in other parts of the protocol definition and I think consistency is good.

On the other hand, if one were to participate in a federated authentication method, then there is a natural requirement that the method be compatible with what is available in HTTP - so I get that there's a requirement to consider.  But that is on the federation method, not the "rest" of the protocol.

The way it (3.1.1) reads now, with a requirement in the section, makes it seem like a federated authentication method is itself a requirement.  And that is why I called the section an "ill fit."

On Dec 4, 2012, at 22:48, Ning Kong wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2012 22:36:41 -0000

>Continuing my preference for top posting.  (An old issue.):

top posting hate hate hate die die die

Now that we have that out of the way ...

>Add a new header called Security Policy Options and move 3.1.1 under that.  The
>reason is that I don't see federated authentication as a necessity, i.e., not
>as a requirement per se.

I added the federated thing in the first place, and it does seem to
have gotten a bit out of control.  All I proposed to say is that the
authentication schemes should not preclude federated auth, e.g., don't
do something that requires a unique credential for each server.

R's,
John

---

From: Ning Kong <[email-masked]>
Date: Sat, 15 Dec 2012 11:28:34 +0800

Hi Ed,

As I mentioned before, the reason why we added 3.1.1 to discuss federated authentication is there were discussions about this issue. Based on these discussions, IMHO, federated authentication may be a possible requirement. If WEIRDS WG can get a definitely conclusion that federated authentication is not a requirement in future, I'd like to accept omitting this topic.

But if we agree that federated authentication should be considered as a requirement in future, I don't think we should only discuss it as a policy issue. I do think the protocol issues related with federated authentication needs to be considered, just like the traditional authentication in Section 3.1. 

Cheers,
Ning