IETF Logo Mail Archive

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

Derek Atkins <derek@ihtfp.com> Mon, 16 April 2012 19:07 UTC

Return-Path: <derek@ihtfp.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 BD9DE21F85D8; Mon, 16 Apr 2012 12:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.936
X-Spam-Level:
X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
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 6ME3Af3heGFZ; Mon, 16 Apr 2012 12:07:14 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E021F85CE; Mon, 16 Apr 2012 12:07:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6FBA52602A6; Mon, 16 Apr 2012 15:07:13 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16559-07; Mon, 16 Apr 2012 15:07:12 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5BCC92602A5; Mon, 16 Apr 2012 15:07:12 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GJ79Ha012606; Mon, 16 Apr 2012 15:07:09 -0400
From: Derek Atkins <derek@ihtfp.com>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>
Date: Mon, 16 Apr 2012 15:07:08 -0400
In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> (Murray S. Kucherawy's message of "Fri, 13 Apr 2012 17:45:32 +0000")
Message-ID: <sjm1unn338j.fsf@mocana.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: "oauth@ietf.org WG" <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: Mon, 16 Apr 2012 19:07:14 -0000

"Murray S. Kucherawy" <msk@cloudmark.com> writes:

> Thank you Stephen, I think.  :-)
>
> So the discussion on apps-discuss now should be focused on which of the two should be the basis for forward progress.  I've placed both documents in "Call for Adoption" state in the datatracker for appsawg.

>From an OAUTH perspective I believe that we should help define the
requirements of what this protocol needs to provide (be it webfinger,
swd, or yadp (Yet Another Discovery Protocol) -- whatever it's named!)

I think there are two main differerences between webfinger and swd:

a) whole-document vs. individual attributes
b) a perceived authorization model to control access to said attributes

In particular I feel there are some specific security requirements that
must be bet by the protocol, but I think it's easily accomplished by
a small amount of text that effectively says:

1) requestors of the service should authenticate (or be treated as an
   anonymous user)
2) content returned must be dynamic and dependent on the authorization
   of the authenticated user.

This leaves only the perceived issue of "whole document" vs "individual
attribute".  If a client ever wants more than one attribute then a whole
document approach reduces the number of round trips.  However if
documents get large that could also affect performance.  We might, then,
need a way to specify which attributes are requested, but allow for a
wildcard to return "everything I am authorized to see".

> Let the games begin.

Heh.  Play ball!

> -MSK
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

v2.23.0 | Report a Bug | By Email