Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard
Chuck Mortimore <cmortimore@salesforce.com> Fri, 14 December 2012 02:34 UTC
Return-Path: <cmortimore@salesforce.com>
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 D38D821F89C6; Thu, 13 Dec 2012 18:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.327
X-Spam-Level:
X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 e6tBPlC28Aqg; Thu, 13 Dec 2012 18:34:20 -0800 (PST)
Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with SMTP id 80C6121F8974; Thu, 13 Dec 2012 18:34:20 -0800 (PST)
Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKUMqQLBUfMS/fhUq0BBeLMO4SfiMPFjP0@postini.com; Thu, 13 Dec 2012 18:34:20 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 13 Dec 2012 18:34:20 -0800
From: Chuck Mortimore <cmortimore@salesforce.com>
To: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
Date: Thu, 13 Dec 2012 18:34:13 -0800
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard
Thread-Topic: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard
Thread-Index: Ac3Zo4Q/pWOl49zpRlOxQ1aeV6bIWg==
Message-ID: <D6F62E88-1656-4951-A206-FC6E20EBBAB5@salesforce.com>
References: <OFB336BD6F.D58307B1-ON48257AD4.000C51F0-48257AD4.000D954A@zte.com.cn>
In-Reply-To: <OFB336BD6F.D58307B1-ON48257AD4.000C51F0-48257AD4.000D954A@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D6F62E8816564951A206FC6E20EBBAB5salesforcecom_"
MIME-Version: 1.0
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>, "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 02:34:22 -0000
You want a holder of key pattern. The draft touches on it The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need to be specified. So - if you want this, you should put forth a holder of key profiling of this draft and see if there are any issues. The only profiles we have thus far are saml and jwt bearer assertions. - cmort On Dec 13, 2012, at 6:27 PM, "zhou.sujing@zte.com.cn<mailto:zhou.sujing@zte.com.cn>" <zhou.sujing@zte.com.cn<mailto:zhou.sujing@zte.com.cn>> wrote: I am not sure if the following usecase http://www.ietf.org/mail-archive/web/oauth/current/msg10233.html could be supported by assertion framework, We have some discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html http://www.ietf.org/mail-archive/web/oauth/current/msg10198.html In my use case or in some other cases, assertions don't need confidential protection, basically STS don't have to authenticate a client before issueing "assertion", if it could be called assertion here. Example,I trust my laywer, I may issue an "assertion" stating delegation in advance, and send to the lawyer when it is needed, it could be I give the assertion to a false lawyer, but it does not matter, because the lawyer has to prove he knows some credential corresponding to his ID, who is delegated some rights. If assertion framework want to support this use case, then generation of assertion should be relaxed, otherwise new work is required to support the use case. Chuck Mortimore <cmortimore@salesforce.com<mailto:cmortimore@salesforce.com>> 写于 2012-12-14 10:08:34: > On Dec 13, 2012, at 4:30 PM, "zhou.sujing@zte.com.cn<mailto:zhou.sujing@zte.com.cn>" <zhou.sujing@zte.com.cn<mailto:zhou.sujing@zte.com.cn> > > wrote: > > 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". > > So how does the STS trust the client? Presumably if it is trusted > it has some level of authentication, yes? > > -cmort > > > > > > Chuck Mortimore <cmortimore@salesforce.com<mailto: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<mailto: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<mailto: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<mailto:ietf@ietf.org> mailing lists by 2012-12-24. Exceptionally, comments may be > > > sent to iesg@ietf.org<mailto: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<mailto:OAuth@ietf.org> > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org<mailto: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