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 <[email protected]>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, <[email protected]> wrote: > >> >> Why RO as an issuer is only theoretical today? >> >> >> *Brian Campbell <[email protected]>* >> >> 2012-12-04 23:41 >> 收件人 >> Nat Sakimura <[email protected]> >> 抄送 >> [email protected], "[email protected]" <[email protected]> >> 主题 >> 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 >> <*[email protected]*<[email protected]>> >> 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, >> <*[email protected]*<[email protected]>> >> wrote: >> >> >> >> Chuck Mortimore <*[email protected]* <[email protected]>> >> 写于 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, >> > <*[email protected]*<[email protected]>> >> wrote: >> > >> > >> > Obviously, it is not so clear from the language there. >> > >> > >> > Chuck Mortimore <*[email protected]*<[email protected]>> >> 写于 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, >> > > <*[email protected]*<[email protected]>> >> <*[email protected]* <[email protected]> >> > > > wrote: >> > > >> > > >> > > +1. >> > > And why it was not looked at that time? >> > > >> > > *[email protected]* <[email protected]> 写于 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、"*[email protected]* <[email protected]>" >> <*[email protected]* <[email protected]>> の >> > > > メッセ�`ジ: >> > > >> > > > >> > > > could be Resource owner? >> > > > >> > > >> > > > >> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" >> > > > <*[email protected]*<[email protected]>> >> >> > > > 发件人: *[email protected]* <[email protected]> >> > > > 2012-12-03 16:49 >> > > > >> > > > 收件人 >> > > > >> > > > "ext Nat Sakimura" <*[email protected]* <[email protected]>>, >> "Brian Campbell" < >> > > > *[email protected]* <[email protected]>>, >> "oauth" <*[email protected]* <[email protected]>> >> > > > >> > > > 抄送 >> > > > >> > > > 主题 >> > > > >> > > > 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: *[email protected]* <[email protected]> [mailto:* >> [email protected]* <[email protected]>] 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 >> > > > *[email protected]* <[email protected]> >> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > *[email protected]* <[email protected]> >> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > *[email protected]* <[email protected]> >> > > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> > > _______________________________________________ >> > > OAuth mailing list >> > > *[email protected]* <[email protected]> >> > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list* >> **[email protected]* <[email protected]>* >> **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* >> **[email protected]* <[email protected]>* >> **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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
