Hi Brian, This is sort of my feeling on the STS as well (theoretical). Are there any real-life examples of obtaining a JWT assertion from an STS that can be used for the assertion flow? And if so then how is it obtained? It cannot be an id_token because that is audience restricted to the client. I guess it could be an access_token with a scope of assertion? But I’ve not seen any discussion of that. I’ve been interested in this flow for a while but the only examples I’m aware of are self-issued JWTs. I’d be very interested in knowing real life of examples of clients obtaining a JWT assertion from an STS to use as a grant, and the method they use to do that.
tx adam From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Wednesday, December 05, 2012 8:05 AM To: zhou.suj...@zte.com.cn Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? I say that it's only theoretical because I don't believe there are any actual deployments supporting, or planning on supporting, RO as an assertion issuer. On Tue, Dec 4, 2012 at 5:39 PM, <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> wrote: Why RO as an issuer is only theoretical today? Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> 2012-12-04 23:41 收件人 Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>> 抄送 zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>, "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> 主题 Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? The intent was definitely not to constrain who/what could be the issuer. But also try to provide some guidance around the common cases that are actually being deployed now, which are the client self-issued and STS variants. Resource owner as an issuer is an interesting case but seems mostly theoretical at this point. I feel like mentioning the resource owner there in §5.1 would cause more confusion than anything else. I'd prefer to just strike the whole sentence in question and maybe add some additional text to §3 that clarifies that the issuer can really be any entity, if folks think a change is needed here? On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>> wrote: 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 include an OAuth client, resource owner, an independent third party." So, the clause becomes: 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. Example of issuers include an OAuth client, resource owner, an independent third party. Nat Nat On Tue, Dec 4, 2012 at 11:40 AM, <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> wrote: Chuck Mortimore <cmortim...@salesforce.com<mailto:cmortim...@salesforce.com>> 写于 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 service is the assertion issuer" in assertion document. while you said "token service know who created the assertion" I wonder if the following text is acceptable: 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 assertions are self-issued) or any other entity, e.g., a third party token service, resource owner. 6.3. Client Acting on Behalf of a User The Issuer of the assertion MUST identify the entity that issued the assertion as recognized by the Authorization Server. If the assertion is self-issued, the Issuer SHOULD be the "client_id". If the assertion was issued by a Security Token Service (STS), the Issuer SHOULD identify the STS as recognized by the Authorization Server.If the assertion was issued by the resource owner, the Issuer SHOULD identify the resource owner as recognized by the Authorization Server. > > -cmort > > On Dec 3, 2012, at 6:23 PM, > <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> wrote: > > > Obviously, it is not so clear from the language there. > > > Chuck Mortimore <cmortim...@salesforce.com<mailto:cmortim...@salesforce.com>> > 写于 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, > > <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> > > <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<mailto: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:58 AM, Nat Sakimura wrote: > > > 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 > > clearlydefining. > > > I had similar experience in other fora. > > > > > > Nat > > > > > > Sent from iPad > > > > > > 2012/12/03 0:52、"zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>" > > > <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> の > > > メッセ�`ジ: > > > > > > > > could be Resource owner? > > > > > > > > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" > > > <hannes.tschofe...@nsn.com<mailto:hannes.tschofe...@nsn.com>> > > > 发件人: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> > > > 2012-12-03 16:49 > > > > > > 收件人 > > > > > > "ext Nat Sakimura" <sakim...@gmail.com<mailto:sakim...@gmail.com>>, > > > "Brian Campbell" < > > > bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>, "oauth" > > > <oauth@ietf.org<mailto:oauth@ietf.org>> > > > > > > 抄送 > > > > > > 主题 > > > > > > 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 > > > Hannes > > > > > > > > > From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> > > > [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf > > > Of > > > ext Nat Sakimura > > > Sent: Monday, December 03, 2012 10:35 AM > > > To: Brian Campbell; oauth > > > Subject: [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 assertions are self-issued) or a third party > > > token service. > > > > > > I was wondering why it has to be either the client or a third party > > > token service. > > > Conceptually, it could be any token service (functionality) > > residingin any of > > > > > > the stakeholders (Resource Owner, OAuth Client, Authorization Server, or > > > a third party). > > > > > > > > > I would appreciate if you could clarify why is the case. > > > > > > > > > Best, > > > > > > -- > > > Nat Sakimura (=nat) > > > Chairman, OpenID Foundation > > > http://nat.sakimura.org/ > > > @_nat_en > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
