More differences:
Assertions are classified into two types:
1. Bearer Assertions: Any entity in possession of a bearer assertion
(e.g. the bearer) can use it to get access to the associated
resources (without demonstrating possession of a cryptographic
key). To prevent misuse, bearer assertions need to be protected
from disclosure in storage and in transport. A secure
communication channel is required between all entities to avoid
leaking the assertion to unauthorized parties.
The delegation in my use case does not belong to bearer assertion,
because it does not need to be protected from disclosure.
2. Holder-of-Key Assertions: To access the associated resources, the
entity presenting the assertion must demonstrate possession of
additional cryptographic material. The token service thereby
binds a key identifier to the assertion and the client has to
demonstrate to the relying party that it knows the key
corresponding to that identifier when presenting the assertion.
This mechanism provides additional security properties.
The delegation in my use case does not belong to holder-of-key
assertion,
because the client does not have to demonstrate to the relying party
that it knows the key.
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
