It is not OAuth, but Austrian eID system is an example of RO as an assertion issuer pattern. They have their own SAML IdP on their PC (at least a few years ago) and combined with the qualified certs in the user's smart card and another file, creates a SAML assertion with sectoral identifier and supply it to other systems.
Nat On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell <bcampb...@pingidentity.com>wrote: > 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> wrote: > >> >> Why RO as an issuer is only theoretical today? >> >> >> *Brian Campbell <bcampb...@pingidentity.com>* >> >> 2012-12-04 23:41 >> 收件人 >> Nat Sakimura <sakim...@gmail.com> >> 抄送 >> zhou.suj...@zte.com.cn, "oauth@ietf.org" <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*<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*<zhou.suj...@zte.com.cn>> >> wrote: >> >> >> >> Chuck Mortimore <*cmortim...@salesforce.com* <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*<zhou.suj...@zte.com.cn>> >> wrote: >> > >> > >> > Obviously, it is not so clear from the language there. >> > >> > >> > Chuck Mortimore <*cmortim...@salesforce.com*<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*<zhou.suj...@zte.com.cn>> >> <*zhou.suj...@zte.com.cn* <zhou.suj...@zte.com.cn> >> > > > wrote: >> > > >> > > >> > > +1. >> > > And why it was not looked at that time? >> > > >> > > *oauth-boun...@ietf.org* <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* <zhou.suj...@zte.com.cn>" >> <*zhou.suj...@zte.com.cn* <zhou.suj...@zte.com.cn>> の >> > > > メッセ�`ジ: >> > > >> > > > >> > > > could be Resource owner? >> > > > >> > > >> > > > >> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" >> > > > <*hannes.tschofe...@nsn.com*<hannes.tschofe...@nsn.com>> >> >> > > > 发件人: *oauth-boun...@ietf.org* <oauth-boun...@ietf.org> >> > > > 2012-12-03 16:49 >> > > > >> > > > 收件人 >> > > > >> > > > "ext Nat Sakimura" <*sakim...@gmail.com* <sakim...@gmail.com>>, >> "Brian Campbell" < >> > > > *bcampb...@pingidentity.com* <bcampb...@pingidentity.com>>, >> "oauth" <*oauth@ietf.org* <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* <oauth-boun...@ietf.org> [mailto:* >> oauth-boun...@ietf.org* <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/* <http://nat.sakimura.org/> >> > > > @_nat_en >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > *OAuth@ietf.org* <OAuth@ietf.org> >> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > *OAuth@ietf.org* <OAuth@ietf.org> >> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > *OAuth@ietf.org* <OAuth@ietf.org> >> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> > > _______________________________________________ >> > > OAuth mailing list >> > > *OAuth@ietf.org* <OAuth@ietf.org> >> > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list* >> **OAuth@ietf.org* <OAuth@ietf.org>* >> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation* >> **http://nat.sakimura.org/* <http://nat.sakimura.org/> >> @_nat_en >> >> >> _______________________________________________ >> OAuth mailing list* >> **OAuth@ietf.org* <OAuth@ietf.org>* >> **https://www.ietf.org/mailman/listinfo/oauth*<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 https://www.ietf.org/mailman/listinfo/oauth
