ZhouSuJing00132831/user/zte_ltd 写于 2012-12-04 13:52:30:

> How about the following use cases: 
> 1. Direct Delegation 
> 
>    Description:
> 
>    Company GoodPay prepares the employee payrolls for the company
>    GoodWork.  In order to do that the application at www.GoodPay.example
>    gets authenticated access to the employees' attendance data stored at
>    www.GoodWork.example.
> 
>    Pre-conditions:
> 
>    o  The application at www.GoodPay.example has obtained an
>       authentication delegation from a party that is trusted by the
>       application at www.GoodWork.example
> 
>    o  The scope of the access by the application at www.GoodPay.example
>       to the data stored at www.GoodWork.example has been defined
> 
>    o  The application at www.GoodPay.example is not capable of 
validating
>       its delegation.
> 
>    Post-conditions:
> 
>    A successful procedure results in the application at
>    www.GoodPay.example receiving an access token after authenticating to
>    the authorization or the application running at www.GoodWork.
> example by presenting an
> delegation. 
> 
>    Requirements:
> 
>    o  Authentication of the application at www.GoodPay.example to the
>       authorization server or the application at www.GoodWork.
> example is required
> 
>    o  The authorization or the application running at www.GoodWork.
> example must be capable of
>       validating delegation  presented by the application running at
>       www.GoodPay.example
> 
> 
> 
> 2. Proxy delegation 
> 
>    Description:
> 
>    Alice has her financial data stored at a financial company www.
> financial.com, her lawyer needs to 
>    obtain authenticated access to some of her financial data to run 
> applications at www.lawyer.example. 
>    Alice and the lawyer have rather long term trust relationship, 
> but still Alice is not willing to leak her secret credential to the 
> 
>  lawyer. The applications at www.lawyer.example may change over the 
> time, Alice is not willing to be bothered by generating assertion 
>  each time a new application comes out. 
> 
>    Pre-conditions:
> 
>      o Alice has a secret private key and corresponding public key 
>      o Alice could generate a proxy private key for her lawyer 
>      o Lawyer could generate proxy signature based on his proxy 
> private key for any application at www.lawyer.examplethat is in the 
> 
> scope (the scope could be as broad as any application at the website
> www.lawyer.example) of the proxy private key. 
> 
>    Post-conditions:
> 
>    A successful procedure results in the application at
>    www.lawyer.examplereceiving an access token after presenting a 
> proxy signature to 
>    the authorization server specified by Alice.
> 
>    Requirements:
> 
>    o  Authentication of the application at www.lawyer.exampleto the
>       application at www.financial.example is required
> 
>    o  The authorization server must be capable of
>       validating proxy signature presented by the application running at
>       www.lawyer.example
> 
> John Bradley <ve7jtb@ve7jtb.com> 写于 2012-12-03 21:17:38:
> 
> > That may relate more to the proof of possession discussion.
> > 
> > You may want to submit that as a use case.
> > 
> > John B.
> > On 2012-12-03, at 6:01 AM, zhou.sujing@zte.com.cn wrote:
> > 
> > 
> > 
> > And another difference is my use case could be that "assertion" be 
> > generated sequentially by resource owner and client. 
> > For example, resource owner delegates a client to generate signature
> > on behalf of it, client generates a signature using the private 
> key of itself,
> > which is called proxy signature in cryptography. 
> > 
> > 
> > 
> > > My use case is indeed similar to  assertion flow "section 6.3. 
> > > Client Acting on Behalf of a User". 
> > > Differences are: 
> > > 1.  if my use case is carried out in assertion framework, "pricipal"
> > > should be client, while assertion document does not 
> > > include client as an option when client is acting on behalf of a 
> > > user(resource owner), it says  " an authorized accessor for which 
the 
> > > access token is being requested (typically the resource owner, or 
> > > an authorized delegate)." 
> > > 2.  if my use case is carried out in assertion framework, "issuer" 
> > > should be resource owner, while assertion document only includes 
> > > client and token service 
> > > 
> > > In my use case the "assertion" is more like a private output, while 
> > > in assertion flow "assertion " is generated by a thrid party token 
> > > service or by client itself. 
> > > 
> > > Nat Sakimura <sakimura@gmail.com> 
> > > 2012-12-03 14:44 
> > > 
> > > 收件人 
> > > 
> > > zhou.sujing@zte.com.cn 
> > > 
> > > 抄送 
> > > 
> > > "oauth@ietf.org WG" <oauth@ietf.org> 
> > > 
> > > 主题 
> > > 
> > > Re: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth? 
> > > 
> > > Your usecase sounds a little bit like the assertion flow. 
> > > The RO issues an assertion and the rest goes. 
> > > Is there reasons that an assertion flow cannot do? 
> > > 
> > > Nat
> > 
> > > On Mon, Dec 3, 2012 at 3:35 PM, <zhou.sujing@zte.com.cn> wrote: 
> > > my use case(RO-initiated delegation): 
> > > -I deposit my child(precious resource) at kindergarden(Resource 
Server) 
> > > -I delegate a few persons,e.g., grandparents of my child, to pick up
> > > my child at the kindergarden 
> > > -when someone tries to take him outside of the kindergarden,  the 
> > > teacher will ask him/her to show my delegation 
> > >  statement, no statement, no taking my child. 
> > > 
> > 
> > > 
> > > -- 
> > > Nat Sakimura (=nat) 
> > > Chairman, OpenID Foundation
> > > http://nat.sakimura.org/
> > > @_nat_en _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth