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
- [OAUTH-WG] oauth assertions plan Stephen Farrell
- Re: [OAUTH-WG] oauth assertions plan Mike Jones
- Re: [OAUTH-WG] oauth assertions plan Stephen Farrell
- Re: [OAUTH-WG] oauth assertions plan Mike Jones
- Re: [OAUTH-WG] oauth assertions plan Stephen Farrell
- Re: [OAUTH-WG] oauth assertions plan John Bradley
- Re: [OAUTH-WG] oauth assertions plan Barry Leiba
- Re: [OAUTH-WG] oauth assertions plan Stephen Farrell
- Re: [OAUTH-WG] oauth assertions plan John Bradley
- Re: [OAUTH-WG] oauth assertions plan Mike Jones
- Re: [OAUTH-WG] oauth assertions plan Barry Leiba
- Re: [OAUTH-WG] oauth assertions plan Mike Jones
- Re: [OAUTH-WG] oauth assertions plan Barry Leiba
- Re: [OAUTH-WG] oauth assertions plan Barry Leiba
- Re: [OAUTH-WG] oauth assertions plan Brian Campbell
- Re: [OAUTH-WG] oauth assertions plan John Bradley
- [OAUTH-WG] Mandatory to implement (was: oauth ass… SM
- Re: [OAUTH-WG] Mandatory to implement (was: oauth… John Bradley
- Re: [OAUTH-WG] Mandatory to implement Stephen Farrell
- Re: [OAUTH-WG] Mandatory to implement Barry Leiba
- Re: [OAUTH-WG] Mandatory to implement Mike Jones
- Re: [OAUTH-WG] Mandatory to implement John Bradley