Subject: [weirds] REST-pect-ful

From: Olaf Kolkman <[email-masked]>
Date: Wed, 11 Jul 2012 22:11:47 +0200

(Also see mail with subject: "Setting the WEIRDS IETF 84 agenda")

Colleagues,

I believe that sorting out how to do service differentiation during an early stage of protocol development is useful.

What I can see is that at some point there is a resource, an object with several elements, for which a local policy of a data provider is that some of its clients are required to have access to that information while others are required to not gain access. A typical example being Contact information whereby a telephone number needs to be made available to law-enforcement, while in general that sort of information is considered privacy sensitive and is not to be shipped to the general public. Note this is an example of a local policy that is not unlikely.

The premise is that we want the protocol to support these sort of policy choices (Who sets the policy is not within scope of the working group).

The other premise is that we "use standard features of HTTP to support differential service levels to different classes of user." [Charter]

The question is what approach do we take, in general, in order to respect the RESTful approach and still differentiate.

It seems that draft-kong-dnrd-ap-response-json section 3.3 uses a mechanism that we can base a straw-man on: 

The resource that is returned as for a query for a contact returns a general identifier with elements that contain URIs for the address, phone number and other person information. If you want to resolve those elements in more detail you will have to do a new query. That query might be refused based on authentication.

I wonder if this approach makes sense, and whether there are better alternatives being considered.

Anther method I thought of is serve up all elements but fill in 'REFUSED', or another magic string or code that indicates the client is not allowed to see those elements. But that doesn't seem very RESTful and I dismissed it.

Questions to the group.

Is the approach as described above (and worked out in Kong et al.'s Internet Draft) an approach we can consent on? Are there alternatives? Are there issues with this approach that need further thought.

Since the answer to this question sets direction

--Olaf

The output of this discussion could end up in draft-designteam-weirds-using-http

_______________________________________________________ 
Olaf Kolkman -- NLnet Labs
http://www.nlnetlabs.nl/

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2012 20:17:34 -0000

The resource that is returned as for a query for a contact returns a
 general identifier with elements that contain URIs for the address,
 phone number and other person information. If you want to resolve
 those elements in more detail you >will have to do a new query. That
 query might be refused based on authentication.

That could certainly work, but what was one query could now be a
dozen, which seems like a poor idea.

 Anther method I thought of is serve up all elements but fill in
 'REFUSED', or another magic string or code that indicates the client
 is not allowed to see those elements. But that doesn't seem very
 RESTful and I dismissed it.

It's not as elegant, but it seems more practical.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 20:39:18 +0000

> dozen, which seems like a poor idea.

I agree with this. Not only does it add load to the service, but experience has shown people don't like requiring for the same information.

> It's not as elegant, but it seems more practical.

I lean more toward this approach as well. Though filling strings with "REFUSED" just leads some to think that a persons last name might be "REFUSED", a notice somewhere in the response noting information has been redacted and pointing toward a policy document is fairly helpful.

-andy

---

From: James Mitchell <[email-masked]>
Date: Thu, 12 Jul 2012 13:06:45 +1000

+1 to the notice concept for the reasons Andy raised.

Using .au whois as an example, only registrant and technical contact name
and email are available via whois-like interfaces (port-43 and web),
however email is withheld to port-43 clients. Administrative and billing
contacts are never returned, nor is any specific data relating to the
registrant or tech contacts (phone, fax, address etc).

There a distinction between data that is never available and data has been
withheld from a specific interface. DENIC also has similar behaviours IIRC.

James

On 12/07/12 6:39 AM, "Andy Newton" <[email-masked]> wrote:

>I agree with this. Not only does it add load to the service, but
>experience has shown people don't like requiring for the same information.
>
>I lean more toward this approach as well. Though filling strings with
>"REFUSED" just leads some to think that a persons last name might be
>"REFUSED", a notice somewhere in the response noting information has been
>redacted and pointing toward a policy document is fairly helpful.
>
>-andy
>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: Patrick Vande Walle <[email-masked]>
Date: Thu, 12 Jul 2012 08:19:50 +0200

Agree with Andy   and others that multiple queries may  cause additional
load that could possibly be avoided. 

On 11/07/12 22:39, Andy Newton wrote:
> "REFUSED",

Indeed. Especially if that person's name happens to be "Refused", which
could happen.  I do not like the idea of having magic strings in lieu of
field data. 
In the case of a field whose content should be hidden by policy, I
suggest the field data should  be empty, but we could add an optional
sub-structure related to policy.

I just made up the example below for the purpose of demonstration: 

{
    "BillingTelNum": {
        "Description": "Billing Contact phone number",
        "TelNum":
              "Data": "",    
            "Policy": {
                "Status": "REDACTED",
                "Info": "See http://www.example.org/weirds-policy"
                }}}}}

Patrick Vande Walle

---

From: Jim Galvin <[email-masked]>
Date: Thu, 12 Jul 2012 09:29:33 -0400

-- On July 11, 2012 8:17:34 PM +0000 John Levine <[email-masked]> 
wrote regarding Re: [weirds] REST-pect-ful --

> It's not as elegant, but it seems more practical.

While I agree that forcing people to make more than one query is 
undesirable if not impractical, I see a practical purpose for doing 
exactly that.

If you just say "REFUSED" then you're done.  There's no opportunity for 
further attempts when it's possible you're entitled to the information. 
How about doing both?

The use case I'm imagining is as follows.  You have a "public" service 
that offers whatever information any random visitor is entitled to. 
For other information it is tagged in some way as "REFUSED" but in 
addition you get the "redirect" for where to get that information. 
Implicit in the redirect is that there will be authentication required, 
which means if you're entitled to the information you'll know how to 
authenticate.  If you're not then you're wasting your time querying.

This seems both practical and elegant to me.

Jim

---

From: "\"Michele Neylon :: Blacknight\"" <[email-masked]>
Date: Thu, 12 Jul 2012 13:38:36 +0000

A lot of ccTLDs do this
.eu only provides minimal data via port 43. To get more data via port 80 you have to get past a catcha and you have limited access to data of private individuals (which is good thing (tm) )

Mr. Michele Neylon
Blacknight
http://Blacknight.tel

Via iPhone so excuse typos and brevity

---

From: Andy Newton <[email-masked]>
Date: Thu, 12 Jul 2012 14:07:56 +0000

On Jul 12, 2012, at 2:19 AM, Patrick Vande Walle wrote:

> Agree with Andy   and others that multiple queries may  cause additional load that could possibly be avoided.  
> 
>> I lean more toward this approach as well. Though filling strings with "REFUSED" just leads some to think that a persons last name might be "REFUSED",
> 
> Indeed. Especially if that person's name happens to be "Refused", which could happen.  I do not like the idea of having magic strings in lieu of field data.  
> In the case of a field whose content should be hidden by policy, I suggest the field data should  be empty, but we could add an optional sub-structure related to policy.
> 

>From the soon-to-be draft-designteam-weirds-using-http-01

9.  Common Data Structures

   This section defines two common data structures to be used by
   DNRD-AP, NRRD-AP, and other RD-AP protocols.  As such, the names
   identifying these data structures are not to be redefined by any
   registry specific RD-AP specifications.  Each of these datatypes MAY
   appear within any other data object of a response, but the intended
   purpose is that they will be mostly used in the top-most data object
   of a response.

   The first data structure is named "rdapConformance" and is simply an
   array of strings, each providing a hint as to the specifications used
   in the construction of the response.

   An example rdapConformance data structure.

     "rdapConformance" : [
       "nrrdap_level_0"
     ]

                                 Figure 9

   The second data structure is named "notices" and is an array of
   "notice" objects.  Each "notice" object contains a "title" string
   representing the title of the notice object, an array of strings
   named "description" for the purposes of conveying any descriptive
   text about the notice, and a "uri" string holding a URI referencing
   any a service that may provide additional information about the
   notice.

   An exmaple of the notices data structure.

     "notices" : [
       "notice" : {
         "title" : "Terms of Use",
         "description" : [
           "This service is subject to The Registry of the Moons",
           "terms of service."
         ],
         "uri" : "http://example.com/our-terms-of-use"
       }
     ]

                                 Figure 10

   This is an example response with both rdapConformance and notices
   embedded.

     {
       "rdapConformance" : [
         "nrrdap_level_0"
       ]
       "notices" : [
         "notice" : {
           "title" : "Content Redacted",
           "description" : [
             "Without full authorization, content has been redacted.",
             "Sorry, dude!"
           ],
           "uri" : "http://example.com/our-redaction-policies"
         }
       ]
       "startAddress" : "10.0.0.0",
       "endAddress" : "10.0.0.255",
       "remarks" : [
         "she sells seas shells",
         "down by the seashore"
       ],
       "uris" : [
         {
           "type" : "source",
           "uri" : "http://whois-rws.net/network/xxxx"
         },
         {
           "type" : "parent",
           "uri" : "http://whois-rws.net/network/yyyy"
         }
       ]
     }

-andy

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2012 17:42:09 -0000

>This seems both practical and elegant to me.

Why would that be better than sending your credentials along with the
initial request so you get all the data on the first try?

R's,
John

---

From: "Ning Kong" <[email-masked]>
Date: Mon, 16 Jul 2012 14:57:32 +0800

> Why would that be better than sending your credentials along with the
initial
> request so you get all the data on the first try?
I wonder how you can make sure what credentials are needed on your first
try. Furthermore, in some cases maybe you don't have the appropriate
credential on your first try, but you can acquire one according to the
response. For example, the response might tell you that if you want to
access the non-public data, you MUST register an account from a specific
service provider.

Cheers,
Ning

---

From: "John R Levine" <[email-masked]>
Date: 16 Jul 2012 03:08:59 -0400

> try.

I'd send whatever credentials I had for that server.  Do you expect an 
individual user to have multiple sets of credentials for a single WEIRDS 
server?

> Furthermore, in some cases maybe you don't have the appropriate

In that case, you could register the account, then make the same request 
with the account's credentials.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Ning Kong" <[email-masked]>
Date: Mon, 16 Jul 2012 16:13:43 +0800

> > I wonder how you can make sure what credentials are needed on your
> > first try.
> 
server?
I'm just afraid that maybe the different data within a single WEIRDS server
require different credentials. For example, the billing contact name is only
opened to the registered users, but the billing contact phone is only opened
to the specific users who have signed a special agreement or who have gotten
a grant by the domain owner.

There is another possible scenario. WEIRDS service A you are querying has
set up alliances with WEIRDS service B and a famous authentication service
C. So the non-public data within WEIRDS service A might be opened to
registered users of WEIRDS service A, WEIRDS service B, or authentication
service C.

I'm not sure the above use cases are likely or not. IMO, the requirements of
WEIRDS authentication needs to be confirmed at first.

> > access the non-public data, you MUST register an account from a
> > specific service provider.
> 
with
> the account's credentials.
The "specific service provider" I mentioned above is not the same WEIRDS
service you queried. So it might be another WEIRDS service within an
alliance or a specific authentication service. In that case, you have to
make the first request in order to know what credential for the requested
data is needed.

Cheers,
Ning

---

From: Arturo Servin <[email-masked]>
Date: Mon, 16 Jul 2012 05:55:02 -0300

Ning,

	I think that your scenarios are valid. e.g. a weirds operator using open-id to provide access to its data.

	IMHO it would depend on the local policy of the weirds sever to decide what data to serve.

	The first step I think would be to decide which authentication and authorization methods we would like to have in this protocol.

Cheers,
as

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 16 Jul 2012 11:22:26 +0200

[This warrants a new thread]

> WEIRDS authentication needs to be confirmed at first.

Can we work from the assumption that authentication is through features offered by HTTP?

What would we be closing the door on if we require that we only rely on features offered by HTTP?

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands

---

From: "Ning Kong" <[email-masked]>
Date: Mon, 16 Jul 2012 17:24:22 +0800

> 	I think that your scenarios are valid. e.g. a weirds operator using
open-id
> to provide access to its data.
Good to know.

> 	IMHO it would depend on the local policy of the weirds sever to
decide
> what data to serve.
I agree.

> 	The first step I think would be to decide which authentication and
> authorization methods we would like to have in this protocol.
I hope the "A.2. Service Differentiation in a REST-pect-ful way" of the
coming WEIRDS meeting can help us make sure the authentication requirements
and feasible mechnisms.

Cheers,
Ning

> >> I'd send whatever credentials I had for that server.  Do you expect
> >> an individual user to have multiple sets of credentials for a single
> >> WEIRDS
> > server?
> > I'm just afraid that maybe the different data within a single WEIRDS
> > server require different credentials. For example, the billing contact
> > name is only opened to the registered users, but the billing contact
> > phone is only opened to the specific users who have signed a special
> > agreement or who have gotten a grant by the domain owner.
> >
> > There is another possible scenario. WEIRDS service A you are querying
> > has set up alliances with WEIRDS service B and a famous authentication
> > service C. So the non-public data within WEIRDS service A might be
> > opened to registered users of WEIRDS service A, WEIRDS service B, or
> > authentication service C.
> >
> > I'm not sure the above use cases are likely or not. IMO, the
> > requirements of WEIRDS authentication needs to be confirmed at first.
> >
> >>> credential on your first try, but you can acquire one according to
> >>> the response. For example, the response might tell you that if you
> >>> want to access the non-public data, you MUST register an account
> >>> from a specific service provider.
> >>
> > The "specific service provider" I mentioned above is not the same
> > WEIRDS service you queried. So it might be another WEIRDS service
> > within an alliance or a specific authentication service. In that case,
> > you have to make the first request in order to know what credential
> > for the requested data is needed.
> >
> > Cheers,
> > Ning
> >

---

From: SM <[email-masked]>
Date: Mon, 16 Jul 2012 05:10:53 -0700

>coming WEIRDS meeting can help us make sure the authentication requirements

There are different ways, e.g. OAuth2, for authentication.  The 
initial requirements, from what I understand, is to offer different 
information if the client is authorized to access the 
information.  The questions would be:

   (a) which authentication mechanism must be implemented

   (b) which response codes, for example, to send

   (c) whether the client should be able to request a different class
       of service

John Levine mentioned doing the authentication on the first query 
instead of having more than one query [1].  In terms of access to the 
resource there isn't much of an argument to prohibit that.   If a 
client can access a resource anonymously it does not make sense not 
to prohibit that if the client is authenticated.

It seems to me that it may provide alternatives to resolve 
non-technical problems if the people want to solve them (in other 
venues).  Item (3) is not a requirement [2].  John Levine mentions 
that "Not if our goal is to produce something useful" in a comment 
about supporting objects [3].  All of the above can be done with MAYs 
if the objective is design a paper tiger.  Some people might disagree 
that it is not a real tiger.  If RESTful is useful people will use it [4].

Regards,
-sm

1. I am ignoring some details.
2. If authorization is determined in other venues
3. http://www.ietf.org/mail-archive/web/weirds/current/msg01306.html
4. http://www.ietf.org/mail-archive/web/weirds/current/msg01045.html

---

From: Jim Galvin <[email-masked]>
Date: Mon, 16 Jul 2012 08:23:21 -0400

-- On July 16, 2012 11:22:26 AM +0200 Olaf Kolkman <[email-masked]> 
wrote regarding [weirds] Authentication Methods --

> features offered by HTTP?

Yes.

> on features offered by HTTP?

If there is a redirection there is the question of what responsibility 
we have for the services at that destination.  I think it's out of 
scope but I wanted to mention it for completeness.

Jim

---

From: "Ning Kong" <[email-masked]>
Date: Tue, 17 Jul 2012 15:56:58 +0800

> If there is a redirection there is the question of what responsibility we
have
> for the services at that destination.  I think it's out of scope but I
wanted to
> mention it for completeness.

I wonder whether the OAuth 2.0 can be considered as a possible
authentication method for WEIRDS based on the assumption that we only rely
on features offered by HTTP.

Cheers,
Ning

---

From: Ray Bellis <[email-masked]>
Date: Wed, 18 Jul 2012 08:53:16 +0000

> Can we work from the assumption that authentication is through features offered by HTTP?

Yes, please!

Ray

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2012 14:26:57 -0000

>> Can we work from the assumption that authentication is through features

So long as that includes stuff like a cookie set by some earlier login
negotiations, I don't see any problem with that.

I presume it also includes the authentication schemes in RFC 2617, oauth
in rfc 5849, and client SSL certs.

What all of these have in common is that we don't have to say anything
about them other than to refer people to the existing definitions.

R's,
John

---

From: Peter Koch <[email-masked]>
Date: Wed, 18 Jul 2012 16:36:05 +0200

> negotiations, I don't see any problem with that.

indeed.  While this is strictly about authorization rather than authentication,
in the context of single object vs. basket of objects there might be
scenarios where a, say, person object, should only be retrievable
as a followup to an inet or domain object, to avoid personal data hervesting.
Cookies might help there, even though they'd not necessarily
identify the requestor.

-Peter

---

From: Andy Newton <[email-masked]>
Date: Wed, 18 Jul 2012 15:52:01 +0000

> about them other than to refer people to the existing definitions.

What are we saying here? That ALL weirds clients and servers must support cooking passing, OAuth, client SSL, etc.. even though no policy may ever be passed by any operator or community that uses them?

-andy

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2012 12:17:52 -0400

> What are we saying here? That ALL weirds clients and servers must 
> support cooking passing, OAuth, client SSL, etc.. even though no policy 
> may ever be passed by any operator or community that uses them?

Servers don't have to support any auth at all, if they're willing to give 
the same answer to everyone.  Clients have to support whatever auth is 
needed to persuade the server to give up the goods.

It would be fine with me to limit the set that servers can use, but I 
suspect you'll find consitutuencies for all of them.  OAuth is too 
complex, but it has the valuable ability to validate referrals, i.e., if 
you're authenticated to server A, and it refers you to server B, then B 
can consult A to find out what you're allowed to do without A giving B 
your credentials.

These are all widely implemented. Even the horrors of OAuth are buried in 
perl, PHP, and python libraries.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Andy Newton <[email-masked]>
Date: Wed, 18 Jul 2012 16:26:33 +0000

On Jul 18, 2012, at 12:17 PM, John R Levine wrote:

> Servers don't have to support any auth at all, if they're willing to give the same answer to everyone.  Clients have to support whatever auth is needed to persuade the server to give up the goods.

Let me ask this a different way. Will this working group produce RFCs that say OAuth, client SSL, etc.. is a MUST to implement? Keep in mind there are people intending to write generic weirds clients and there is a project to write a generic weirds server for the names registries.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2012 12:37:15 -0400

> Let me ask this a different way. Will this working group produce RFCs that say OAuth, client SSL, etc.. is a MUST to implement? Keep in mind there are people intending to write generic weirds clien…

Good question.  I suppose that as a strawman we can pick one or two and 
see who objects.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Jul 2012 12:44:39 -0400

On Wed, Jul 18, 2012 at 12:37:15PM -0400, John R Levine wrote:
> 
> Good question.  I suppose that as a strawman we can pick one or two
> and see who objects.

Why isn't the right answer to say that they're all MAY and then see
what people actually implement?  I think being prescriptive here is a
waste of time.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2012 22:03:40 -0000

>what people actually implement?  I think being prescriptive here is a

That doesn't strike me as a very good way to get things to
interoperate.  You write a client and decide that nobody uses client
certs, I write a server that expects client certs.  Now what?

R's,
John

---

From: Avri Doria <[email-masked]>
Date: Wed, 18 Jul 2012 21:28:21 -0400

Hi,

I suggest a SHOULD.    

Not quite a MUST because there might be a set of good reasons for not doing OAuth, client SSL, etc.. that could be listed in the rfc, but that in the absence of a good reason for not doing so, yes one SHOULD.

avri

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Jul 2012 21:44:49 -0400

> Not quite a MUST because there might be a set of good reasons for not doing OAuth, client SSL, etc.. that could be listed in the rfc, but that in the absence of a good reason for not doing so, yes…

That doesn't address Andy's (quite reasonable) observation that many
clients won't want to implement all that.  What interoperability
problem are we trying to solve with SHOULD?  MAY permits people to do
this, makes it clear what the methods would be, and then lets both
ends work out what they mutually support.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 19 Jul 2012 09:47:14 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Andy Newton
> Sent: Wednesday, July 18, 2012 11:52 PM
> To: John Levine
> Cc: <[email-masked]>
> Subject: Re: [weirds] Authentication Methods
> 
> 
> > I presume it also includes the authentication schemes in RFC 2617,
> > oauth in rfc 5849, and client SSL certs.
> >
> What are we saying here? That ALL weirds clients and servers must support
> cooking passing, OAuth, client SSL, etc.. even though no policy may ever
be
> passed by any operator or community that uses them?
> 

I think we should define which authentication scenarios are included in the
scope of this working group. Then select authentication mechanisms that are
suitable for corresponding scenarios. 
Some may not supported or implemented, but reasons and explanations are
listed.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Jul 2012 08:06:20 +0000

On 19 Jul 2012, at 02:47, Linlin Zhou wrote:

The trouble with (HTTP authentication) standards is that there's _so_ many of them to choose from;-)

Ray

---

From: Andy Newton <[email-masked]>
Date: Thu, 19 Jul 2012 15:20:17 +0000

> The trouble with (HTTP authentication) standards is that there's _so_ many of them to choose from;-)

We need to be careful here. If we define so many MUSTs (or even MAYs), there will be push back that this is a heavyweight specification and some will use that to avoid implementation.

I think the question ought to be asked, does any Whois operator today have differentiated access, either via port 43 or other Whois-type services, or does any Whois operator have plans in the works to implement some type of differentiated access. Getting answers to such questions would limit the scope.

-andy

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2012 15:55:18 -0000

>I think the question ought to be asked, does any Whois operator today
>have differentiated access, either via port 43 or other Whois-type
>services, ...

On the numbers side, you can probably answer that as well as anyone.

On the names side, I can report from experience that every WHOIS
server does rate limiting, and there is usually some secret way to get
the limit for your IP raised if you know who to ask.

When you hit the limit, different providers do different things.  Some
redact the data (Godaddy notably).  Some return a message saying
you're over your limit.  Some just don't accept connections, or accept
and don't respond.

So, yes, on the names side at least, differentiated access is universal.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Jul 2012 11:56:12 -0400

On Thu, Jul 19, 2012 at 03:20:17PM +0000, Andy Newton wrote:
> 
> I think the question ought to be asked, does any Whois operator
> today have differentiated access, either via port 43 or other
> Whois-type services

Yes.  Almost all the name registries have a special non-rate-limited
address you can talk to.  Most of them require the IP address from
which you are coming to get to it, and it's available to you at their
discretion.  This is normally offered to registrars, who frequently
need the full non-rate-limited access in order to comply with various
requirements of ICANN agreements, or as part of their business logic.

Moreover, a significant justification for this work was differential
access.  If we're not going to offer it, we're not in keeping with our
charter.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Jul 2012 14:00:45 -0400

On Jul 18, 2012, at 9:44 PM, Andrew Sullivan wrote:

> clients won't want to implement all that.  

And that is perfectly fine -- my shiny web-browser implements digest auth, TLS and the ability to see dancing hamsters ( http://www.webhamster.com/ ) not because of any MUST or SHOULD, but because that is what the users are (apparently) asking for.
If I connect to a web server that doesn't require these things I am free to use a much simpler client (AKA "telnet to port 80"!).

Both ways have their pros and cons, but if I need to connect to a system that needs "advanced" features, I go pull out an "advanced" client. As long as the specification is clear on how the base functionality works, how the optional features work , and which are which, client developers can support what they need to...

> What interoperability

Well, sort of -- clients that don't implement $foo obviously won't be able to get content that requires $foo. Unless both sides announce their capabilities[0] it may be tricky (short of probing / testing) to know what all capabilities are supported. 

W
[0]: I'm not suggesting this!

-- 
No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.

---

From: Peter Koch <[email-masked]>
Date: Thu, 19 Jul 2012 20:05:42 +0200

> withheld from a specific interface. DENIC also has similar behaviours IIRC.

true. The admin contact is unavailable over port 43 and some contact details
may only be visible as instructed by the registrant.  And there is overall
rate limiting.

In those cases where an object or an attribute is withheld I do not
think it would be either proper protocol design to add a magic string
(as opposed to an extra alphabetical token) or within the purpose
of the limited visibility to disclose the presence of the data.

-Peter

---

From: Ray Bellis <[email-masked]>
Date: Fri, 20 Jul 2012 06:39:42 +0000

> We need to be careful here. If we define so many MUSTs (or even MAYs), there will be push back that this is a heavyweight specification and some will use that to avoid implementation.

IMHO we should restrict our stronger 2119 keywords for those authentication methods that are universally supported in HTTP library APIs (e.g. basic auth, TLS client certs) and none of those new-fangled end-user-centric methods (e.g. OpenID).

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 20 Jul 2012 10:18:29 +0000

> of the limited visibility to disclose the presence of the data.

+1 - I see no benefit in informing the client about data that exists but has been omitted.

Ray

---

From: Jim Galvin <[email-masked]>
Date: Fri, 20 Jul 2012 08:38:51 -0400

-- On July 19, 2012 3:20:17 PM +0000 Andy Newton <[email-masked]> wrote 
regarding Re: [weirds] Authentication Methods --

> services, or does any Whois operator have plans in the works to
> implement some type of differentiated access. Getting answers to such
> questions would limit the scope.

Could the differentiated access be one of two things: here's some 
public information I'll give to anybody versus if you want complete or 
specific information you have to provide the right credentials.

If I'm the server motivated by the policies that manage the information 
I'm making available, I simply do whatever I have to do.  If all 
authentication methods are "MAY" I choose the one or more that works 
best for me.  Any client who wants my information will need to meet my 
requirements.

If I'm the user behind the client, I have to choose to use a client 
that supports the credentials I need to have available.  That could be 
no authentication is supported, in which case I get only the "public" 
information.

It was Ray Bellis who pointed out that there are so many HTTP 
Authentication Methods to choose from.  Why is it our job to fix that? 
If we're building this on top of HTTP then let's leave that problem for 
HTTP "to fix".

I agree with Andrew Sullivan who said make everything a "MAY".  I think 
our energy is better directed towards being able to respond with 
minimal information at all times or perhaps a "standard" response of 
some sort that includes a referral or at least a designation of the 
credentials you need and where you can go to get instructions on 
obtaining them.

Jim

---

From: Ray Bellis <[email-masked]>
Date: Fri, 20 Jul 2012 13:01:36 +0000

On 20 Jul 2012, at 13:38, Jim Galvin wrote:

> 
> It was Ray Bellis who pointed out that there are so many HTTP Authentication Methods to choose from.

It was :)

> Why is it our job to fix that? If we're building this on top of HTTP then let's leave that problem for HTTP "to fix".

But I didn't intend to propose that we fix that.

I do think (as I posted later) that we should actively avoid any authentication method that involves multiple interactions between client and server, i.e. cookies, OpenID, etc.

Those methods are designed for authenticating end users (i.e. someone sat at a browser).  They are not intended for "machine to machine" authentication.

I am slightly puzzled by Andy's observation of the high number of browser generated queries at the ARIN server.  I can only surmise that those are "proof of concept" implementations.

For the kinds of differentiated access we have in mind here, I'm fairly sure that authorising individual end users sat at a browser talking directly to the server via AJAX are not amongst them.  Those users will just get the default minimum view.

Ray

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 14:47:05 -0000

> IMHO we should restrict our stronger 2119 keywords for those
> authentication methods that are universally supported in HTTP library
> APIs (e.g. basic auth, TLS client certs) and none of those new-fangled
> end-user-centric methods (e.g. OpenID).

OK.  How do you feel about oauth?

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Fri, 20 Jul 2012 14:54:33 +0000

> OK.  How do you feel about oauth?

I'm not experienced in OAuth.  Is it suited for machine-to-machine authentication?

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jul 2012 11:31:45 -0400

> I'm not experienced in OAuth.  Is it suited for machine-to-machine authentication?

Why is that the only criterion?  For the kinds of problems law
enforcement people keep bringing up, they don't need
machine-to-machine things to work.  They need for a person to be able
to get all the information necessarty. OAuth would be an excellent
mechanism for that, because the WEIRDS provider could negotiate with
some law-enforcement authenticator, which would then hand the
necessary credentials to the WEIRDS service when a request was
inbound.  This puts the onus for vouching that a particular law
enforcement request is legitimate (along with the relevant paperwork,
logs, &c) onto the parties who can make that determination.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 16:16:37 -0000

>I'm not experienced in OAuth.  Is it suited for machine-to-machine authentication?

That's all I've ever used it for, doing tweets from perl scripts.

R's,
John

---

From: Peter Koch <[email-masked]>
Date: Fri, 20 Jul 2012 19:00:37 +0200

> best for me.  Any client who wants my information will need to meet my 

this seems to confuse advice to implementers (opportunity to interoperate)
with advice to operators/service providers (operational/policy decision).

-Peter

---

From: SM <[email-masked]>
Date: Fri, 20 Jul 2012 13:02:05 -0700

At 05:38 20-07-2012, Jim Galvin wrote:
>public information I'll give to anybody versus if you want complete 
>or specific information you have to provide the right credentials.
>
>If I'm the server motivated by the policies that manage the 
>information I'm making available, I simply do whatever I have to 
>do.  If all authentication methods are "MAY" I choose the one or 
>more that works best for me.  Any client who wants my information 
>will need to meet my requirements.
>
>that supports the credentials I need to have available.  That could 
>be no authentication is supported, in which case I get only the 
>"public" information.
>
>Authentication Methods to choose from.  Why is it our job to fix 
>that? If we're building this on top of HTTP then let's leave that 
>problem for HTTP "to fix".
>
>I agree with Andrew Sullivan who said make everything a "MAY".  I 
>think our energy is better directed towards being able to respond 
>with minimal information at all times or perhaps a "standard" 
>response of some sort that includes a referral or at least a 
>designation of the credentials you need and where you can go to get 
>instructions on obtaining them.

In an ideal world one would use a "MAY" and leave it to people to go 
and write code and come back.    Options and Recommendations are then 
fine tuned and you end with a standard.  That line may also apply for 
"differential service levels to different classes of users".  The 
questions one might ask are:

   (a) Does differential service levels require interoperability?

   (b) Does different classes of users require interoperability?

The above does not preclude applying different policies.  A server 
gets to do whatever it wants to do.  If client X has to meet 
different requirements for servers D to Z, one might as well forget 
about interoperability.  It might require less energy to sort out the 
minimal information than to find answers to the above questions.

Regards,
-sm