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
