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
