Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

John Bradley <ve7jtb@ve7jtb.com> Fri, 20 April 2012 17:23 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100B621F84D6 for <oauth@ietfa.amsl.com>; Fri, 20 Apr 2012 10:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhBsNZwIOPJ2 for <oauth@ietfa.amsl.com>; Fri, 20 Apr 2012 10:23:16 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2C0021F84CD for <oauth@ietf.org>; Fri, 20 Apr 2012 10:23:15 -0700 (PDT)
Received: by werb10 with SMTP id b10so7650853wer.31 for <oauth@ietf.org>; Fri, 20 Apr 2012 10:23:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=etiJOJpNjoXe52drxGhqUZ4L+p51A0a3MwpL08du11M=; b=lu5p+IIXaC15qbvG/Rza2+lzUgHNkc+0yHlVEWEbFZcsf2wTyoN5u7MG+RVmwAE/Zp 2jUcSSRzsXvbCU7k/ngKrDXdZ3MIzq95wJ0cYFA38PIuJBA2GAFiPXDe/0uJXtxY1mas m58ghcapSuVSn6VIycR/8ANlqBLlglUeDtMWBmjbCI7UE4j1zlxjCzLfbB8epX1CghLe TrIm4saC3fmkCtds2f9y0h9Hp5P2+qmGO6xECJAtdg4HI/qI0V040+bStyrPO0Xm/jzS XYFAhLqrX7Z8OaU4aUXattUJxzp0wbW1BbVLFZq9ZSEOh1cpdhD0NlRQOopOqeWa1NdB nQsw==
Received: by 10.180.105.194 with SMTP id go2mr16941696wib.22.1334942592921; Fri, 20 Apr 2012 10:23:12 -0700 (PDT)
Received: from [10.140.224.153] ([80.187.201.110]) by mx.google.com with ESMTPS id fz9sm6854920wib.3.2012.04.20.10.23.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:23:11 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com>
Date: Fri, 20 Apr 2012 19:23:06 +0200
Message-Id: <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <sjm1unn338j.fsf@mocana.ihtfp.org> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <CAHBU6it3ZmTdK-mTwydXSRvGvZAYuv0FFR2EWLwdfTxQh4XV5g@mail.gmail.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <sjmbommzdv4.fsf@mocana.ihtfp.org> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com>
To: Gonzalo Salgueiro <gsalguei@cisco.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmabno3NMZgeXksbONTK37EptoyzSpMRNPPIvkHU1mhQrt4EfRHhLHPY5Gywah3siXyhBXX
Cc: Derek Atkins <derek@ihtfp.com>, oauth@ietf.org, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 17:23:17 -0000

I would be OK with optional XML support in the server,  that way existing endpoints will continue to work, but new ones are not required to add something some people feel is cruft.

As one of the XRD authors, I do understand the advantages of it.

However I don't want to be sentimental, and force people to carry forward things that won't be used, and may hamper adoption.

And Yes I am one of the hard hatred basters that decided to redo  openID on OAuth rather than trying to graft OAuth functionality onto openID 2.   

Keeping what's working working is fine,  but not forcing people to carry it forward.

John B.

On 2012-04-20, at 7:09 PM, Gonzalo Salgueiro wrote:

> Derek - 
> 
> On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote:
> 
>> Paul,
>> 
>> "Paul E. Jones" <paulej@packetizer.com> writes:
>> 
>>> Tim,
>>> 
>>> I do not agree that it's harmful. If I removed the WF discussion off the
>>> table, I'm still having a hard time buying into everything you said in the
>>> blog post.
>>> 
>>> I implement various web services, largely for my own use.  Usually, I
>>> implement all of them in XML, JSON, plain text (attribute/value pairs), AND
>>> JavaScript (for JSONP).  For simple services, it's not hard.  I do it
>>> because I sometimes have different wants/desires on the client side.  (For
>>> more complex ones, I use XML.)
>> 
>> As an individual (and not the chair of OAUTH) I believe that the server
>> should be allowed, no encouraged, to support multiple formats for data
>> retrieval.  I also believe that clients should be allowed to choose only
>> one.  I am fine with JSON being Mandatory to Implement.  I am NOT okay
>> with making it the only one, and I am even less okay with mandating it
>> is the ONLY one.  I would say MUST JSON, MUST (or possibly SHOULD -- you
>> can convince me either way) XML, and MAY for anything else that people
>> feel stronly about (although I feel in 2012 XML and JSON are the two
>> best).  I also feel it is okay to say that a client MUST implement one
>> of JSON or XML, and MAY implement more.
>> 
>> <OAUTH Chair Hat>
>> 
>> Note that this is a replay of the historical "MUST Implement" versus
>> "MUST Use" arguments.  Just because the server MUST IMPLEMENT JSON and
>> XML does not mean that a Client must use both (or even that a client
>> must implement both).  It is perfectly reasonable and generally
>> acceptable to have a server that provides data in multiple formats
>> whereas the client only supports a subset and specifies which format(s)
>> are acceptable.
>> 
>> </OAUTH Char Hat>
>> 
> 
> This is the most sensible path forward.  A MUST for JSON and XML (I'm going with a MUST for XML to maintain backwards compatibility with RFC 6415) on the server side and a client can choose whatever format it wants. This is the approach taken in the current WebFinger draft. If we reach consensus that we must mandate a client format (Note: I don't personally think we need to), then so be it.
> 
> Cheers,
> 
> Gonzalo
> 
>> -derek
>> 
>> -- 
>>      Derek Atkins                 617-623-3745
>>      derek@ihtfp.com             www.ihtfp.com
>>      Computer and Internet Security Consultant
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth