Re: [OAUTH-WG] oauth assertions plan

Barry Leiba <barryleiba@computer.org> Mon, 18 February 2013 19:09 UTC

Return-Path: <barryleiba@gmail.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 27EF721F8AED for <oauth@ietfa.amsl.com>; Mon, 18 Feb 2013 11:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.933
X-Spam-Level:
X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ELKdhg2L4JW for <oauth@ietfa.amsl.com>; Mon, 18 Feb 2013 11:09:52 -0800 (PST)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id BC37821F8B07 for <oauth@ietf.org>; Mon, 18 Feb 2013 11:09:51 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id q12so4459341lbc.39 for <oauth@ietf.org>; Mon, 18 Feb 2013 11:09:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n24yvjEZaDiag62uo78VdOmIdwTPqLnQtpAS2YsmNrc=; b=iw9QKjAoyvGC07n8BszH5hSRgydm15VhfclJNws7ifxwt4wJ5kq+uqkCIwfIOEVQeA JD6iq0JiJZmnYBCcHs3D0jv5/yCsTUAnupSgtUDc1FjjFmaHNKcnnWS25RVuzJkb2vGV on1UuzAkozT8wzJNxD53Gk7KYEPyfZNi5F8NhiXIbN5CjMh7vCb+wJfnR8I4seJFWPYG 6N7+zogDnjI5Z9zaRrjJ/KG6VtXuZg2kw/b8hsxT3dR6JAgqJ0n2HX4Prbu5FTjAfqc2 mXBiqUFZagGYdfdZwbex/4s/lQFb6h1KURAxhA1el7lWZqlyvK9dzETthVc74KtLSeND Bn+A==
MIME-Version: 1.0
X-Received: by 10.152.111.67 with SMTP id ig3mr4851811lab.41.1361214590617; Mon, 18 Feb 2013 11:09:50 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.76.98 with HTTP; Mon, 18 Feb 2013 11:09:50 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747063A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com> <CALaySJ+YM9_DJ5KB1AnF+D-_1=jMhCdsxrgB3jQaaCLsB7w1Kg@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com> <CAC4RtVAKUAQosF=tJQLB6FExUriY-WhBv+R_0uX6aP1gegR=QQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739436747063A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 18 Feb 2013 14:09:50 -0500
X-Google-Sender-Auth: 2UMhM8WNv8s0xcAqxOmT-Ph40HQ
Message-ID: <CALaySJKFkHtPiZ-u43vFShqgQ4__rC8E7hAXyjZ4jTaZ72tEag@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="f46d04088f172306c904d6047856"
Cc: "oauth-chairs@tools.ietf.org" <oauth-chairs@tools.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] oauth assertions plan
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, 18 Feb 2013 19:09:53 -0000

>
> "Dynamically declaring," in what sense?  Where are those mechanisms
> documented?****
>
> ** **
>
> Many of them are documented in draft-ietf-oauth-dyn-reg.****
>
> ** **
>
> One profile (an outer doll J) that enables fully interoperable
> implementations is documented in draft-hardjono-oauth-umacore.
>
> ...

> Another related profile that enables fully interoperable implementations
> is documented in http://openid.net/specs/openid-connect-messages-1_0.html.
>
>
It's possible, then, that this isn't an issue of major changes needed in
this document, but one of document ordering.  It's possible (I'm still not
sure, but maybe) that if some of these other documents came out before or
at the same time as this one, they would all fit together and all would be
clear.

So maybe that's one way through this.

In the end, all I'm saying is that if I hear that everyone is using oauth
to peel bananas, and I want put my banana-peeling application on the market
by adding oauth to it, I need to be able to read a set of specs that say
how to do that, and that's all.  And if I do that, my application will work
when it's slotted into any oauth-based banana-peeling system.

Barry