Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard
zhou.sujing@zte.com.cn Fri, 14 December 2012 00:30 UTC
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63C21F8BE4; Thu, 13 Dec 2012 16:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.364
X-Spam-Level:
X-Spam-Status: No, score=-98.364 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 sEm+bk7RoK6E; Thu, 13 Dec 2012 16:30:18 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29D21F8BDF; Thu, 13 Dec 2012 16:30:17 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A50AB125EA; Fri, 14 Dec 2012 08:30:07 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E7774174C771; Fri, 14 Dec 2012 08:19:15 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBE0U1Do020840; Fri, 14 Dec 2012 08:30:01 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <18F98790-E67A-44AD-83C6-51118716C9DA@salesforce.com>
To: Chuck Mortimore <cmortimore@salesforce.com>
Subject: Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFE9540EB0.6D71176A-ON48257AD4.00025F53-48257AD4.0002DDC1@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Fri, 14 Dec 2012 08:29:47 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 08:29:53, Serialize complete at 2012-12-14 08:29:53
Content-Type: multipart/alternative; boundary="=_alternative 0002DDBE48257AD4_="
X-MAIL: mse02.zte.com.cn qBE0U1Do020840
X-Mailman-Approved-At: Fri, 14 Dec 2012 09:26:48 -0800
Cc: "oauth-bounces@ietf.org" <oauth-bounces@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 00:30:22 -0000
From the language, I got an impression that assertion is only generated by token service after clients presenting some credentials, there are may be some cases that "assertion" don't need client's credential. e.g., Resource owner as a token service could generate "assertion" to a client he trusts, bu signing a statement that "This delegation is given to a client called clinet-id for doing something for me". Chuck Mortimore <cmortimore@salesforce.com> 写于 2012-12-14 00:39:03: > The language is simply meant to help illustrate how the framework > might be used. How do you think it will restrict usage? How > could it be improved? > > -cmort > > On Dec 12, 2012, at 11:04 PM, <zhou.sujing@zte.com.cn> wrote: > > > In "section 3 > The token service is the assertion issuer; its > role is to fulfill requests from clients, which present various > credentials, and mint assertions as requested, fill them with > appropriate information, and sign them." > > > As I understand, an assertion generated by a STS, is done flollowing > thess steps: > 1. Client presents credential and requests an assertion > 2. STS generates assertion and sends to Client > Correct? > > That may restrict the use cases that this assertion framework could support, > is it a must? > > > > > oauth-bounces@ietf.org 写于 2012-12-11 02:33:57: > > > > > The IESG has received a request from the Web Authorization Protocol WG > > (oauth) to consider the following document: > > - 'Assertion Framework for OAuth 2.0' > > <draft-ietf-oauth-assertions-08.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2012-12-24. Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This specification provides a framework for the use of assertions > > with OAuth 2.0 in the form of a new client authentication mechanism > > and a new authorization grant type. Mechanisms are specified for > > transporting assertions during interactions with a token endpoint, as > > well as general processing rules. > > > > The intent of this specification is to provide a common framework for > > OAuth 2.0 to interwork with other identity systems using assertions, > > and to provide alternative client authentication mechanisms. > > > > Note that this specification only defines abstract message flows and > > processing rules. In order to be implementable, companion > > specifications are necessary to provide the corresponding concrete > > instantiations. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-asser… zhou.sujing
- Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-a… zhou.sujing
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-asser… Chuck Mortimore
- Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-a… zhou.sujing
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-asser… Nat Sakimura
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-asser… Chuck Mortimore
- Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-a… zhou.sujing
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-asser… Chuck Mortimore
- Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-a… zhou.sujing