Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?

From: [email-masked]
Date: Mon, 3 Dec 2012 17:01:57 +0800

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 <[email-masked]> 
> 2012-12-03 14:44
> 
> 收件人
> 
> [email-masked]
> 
> 抄送
> 
> "[email-masked] WG" <[email-masked]>
> 
> 主题
> 
> 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, <[email-masked]> 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

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2012 10:17:38 -0300

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, [email-masked] 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, 
> > @_nat_en _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Tue, 4 Dec 2012 13:52:30 +0800

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 <[email-masked]> 写于 2012-12-03 21:17:38:

> For example, resource owner delegates a client to generate signature
> on behalf of it, client generates a signature using the private key of 
itself,

---

From: [email-masked]
Date: Tue, 4 Dec 2012 13:58:55 +0800

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. 

itself,