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 <ve7...@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.suj...@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 <sakim...@gmail.com> > > > 2012-12-03 14:44 > > > > > > 收件人 > > > > > > zhou.suj...@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.suj...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
