Re: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-assertions-08.txt> (Assertion Framework for OAuth 2.0) to Proposed Standard

Yep, could do it soon later. 

Currently, I suggest a modification for 

 "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."  (in  section 3 )

into 

 "The token service is the assertion issuer, it could be implemented in 
any entity besides client, e.g., Resource Owner, Authorization Server; 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." 

Chuck Mortimore <cmortimore@salesforce.com> 写于 2012-12-14 10:44:05:

> Correct.   That said no one has yet profiled it for holder of key
> 
> - cmort
> 
> On Dec 13, 2012, at 6:39 PM, "zhou.sujing@zte.com.cn" 
<zhou.sujing@zte.com.cn
> > wrote:

> 
> Oh, But the description of assertion generation in the document 
> should not be limited by bear assertion, right? 
> 
> 
> Chuck Mortimore <cmortimore@salesforce.com> 写于 2012-12-14 10:34:13:
> 
> > 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" <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> 写于 2012-12-14 10:08:34:
> > 
> > > On Dec 13, 2012, at 4:30 PM, "zhou.sujing@zte.com.cn" <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> 写于 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 
authenticationmechanism
> > > > >    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 