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

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

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

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.Good

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Actually, "The issuer may be either an OAuth client (when assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. " is not really clean. OAuth client is just another example of an issuer. So, perhaps the sentence could be: "Example of issuers i

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Chuck Mortimore 写于 2012-12-04 10:26:50: > Please feel free to suggest better language. > > Issuer simply allows the token service to know who created the > assertion, so it can look them up and see if they're trusted. > Effectively the same as an Issuer in SAML. a conflict : "The token servic

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Please feel free to suggest better language. Issuer simply allows the token service to know who created the assertion, so it can look them up and see if they're trusted. Effectively the same as an Issuer in SAML. -cmort On Dec 3, 2012, at 6:23 PM, mailto:zhou.suj...@zte.com.cn>> wrote:

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Obviously, it is not so clear from the language there. Chuck Mortimore 写于 2012-12-04 10:17:12: > There's no reason why it can't be resource owner today. > > On Dec 3, 2012, at 6:06 PM, > wrote: > > > +1. > And why it was not looked at that time? > > oauth-boun...@ietf.org 写于 2012-12-0

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

There's no reason why it can't be resource owner today. On Dec 3, 2012, at 6:06 PM, mailto:zhou.suj...@zte.com.cn>> mailto:zhou.suj...@zte.com.cn>> wrote: +1. And why it was not looked at that time? oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: > Actually, I

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Actually - strike that. Authorization server is covered by the language as well. In short, Issuer is simply the entity that minted the assertion. The intent is to allow the token service to lookup metadata about the issuer used to establish trust ( their Public Key for instance ) On Dec 3

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

It's simply the entity that created the assertion. Third party token service was meant to encapsulate pretty much all of your stakeholders below. The only one it doesn't really cover is Authorization Server. On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote: Hi Brian, The assertion frame

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

+1. And why it was not looked at that time? oauth-boun...@ietf.org 写于 2012-12-04 01:30:55: > Actually, I think it is a good time to start looking at the resourse > owner issuing assertions@ (Interestingly enough, Hui-Lan had brought > this up a couple of years ago.) > > Igor > > On 12/3/2012 3

[OAUTH-WG] OAuth WG Virtual Interim Meetings, 11 January 2013 & 21 January 2013

The OAuth Working Group will hold virtual interim meetings as follows: * 11th January 2013, 1pm EST * 21st January 2013, 1pm EST Agenda and dial-in information will be posted on the OAuth mailing list (http://www.ietf.org/mail-archive/web/oauth/current/maillist.html) prior to the meetings.

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Actually, I think it is a good time to start looking at the resourse owner issuing assertions@ (Interestingly enough, Hui-Lan had brought this up a couple of years ago.) Igor On 12/3/2012 3:58 AM, Nat Sakimura wrote: > I suppose, yes. I was reading it like that all the time. > Whether it is or no

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dyn-reg-02.txt

Comments: Introduction, first sentence is awkward. Change from In some use-case scenarios, it is desirable or necessary to allow OAuth clients to obtain authorization from an OAuth authorization server without the two parties having previously interacted. To In some scenarios, it

Re: [OAUTH-WG] Review of Token Revocation draft

An early draft of the revocation spec had this token type field, for this purpose. From an early conversation on the list with Torsten, we decided that most of the time it didn't matter, as different classes of token would be recognizable as different by the AS. In some implementations (like ou

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt

Thanks, likely a copy-paste error. -- Justin On 12/03/2012 09:26 AM, Anganes, Amanda L wrote: A couple of nits: in section 2.3 you have all of the responses labeled as "requests" "Following is a non-normative example request (with line wraps for display purposes only):" I think those shou

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt

A couple of nits: in section 2.3 you have all of the responses labeled as "requests" "Following is a non-normative example request (with line wraps for display purposes only):" I think those should be labeled as example responses. -- Amanda Anganes Info Sys Engineer, G061 The MITRE Corporat

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

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 clien

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

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 signat

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

I suppose, yes. I was reading it like that all the time. Whether it is or not, if it is still ok, it might be better to clarify it. Word like "third party" tends to be a bit of problem without clearly defining. I had similar experience in other fora. Nat Sent from iPad 2012/12/03 0:52、"zhou.suj.

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

could be Resource owner? "Tschofenig, Hannes (NSN - FI/Espoo)" 发件人: oauth-boun...@ietf.org 2012-12-03 16:49 收件人 "ext Nat Sakimura" , "Brian Campbell" , "oauth" 抄送 主题 Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? H

Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Hi Nat, The current text essentially says that the assertion can either be created by the client (in which case it is self-signed) or it can be created by some other entity (which is then called the third party token service). So, this third party could be the authorization server. Ciao H

[OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?

Hi Brian, The assertion framework defines the Issuer as: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. The issuer may be either an OAuth client (when asserti

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

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 behal