So to circle back to the original question/intent of this thread: the assertion framework spec doesn't intended to constrain who/what can issue the assertion. It does discuss some considerations for common (in the authors' view anyway but I stand somewhat corrected by Nat) issuers and that discussion might have been read as limiting who can issue.
Do folks think it reads as though it does constrain who/what can issue as assertion for the flow? After rereading parts of it myself, I do think there's some room for improvement in some of the text. But I don't know how important it really is. A question for the chairs or others more versed in the workings of the IETF - is this document even in a place where changes can be made? The Shepherd Write-Up for the document was recently sent to the IESG Secretary and I'm honestly not sure what the protocol is for making changes at this point. On Thu, Dec 6, 2012 at 12:50 AM, Nat Sakimura <[email protected]> wrote: > Here, I think it is better to differentiate the entity and function/role. > > Authorization Server in OAuth is "kind of" entity. > Its function actually is split into two, or in most cases three. > > 1. Authentication Endpoint > 2. Authorization Endpoint > 3. Token Endpoint > > Now, "Assertion Verifier" is a function/role. It is performed by 3. Token > Endpoint. > It check the validity, and issues access tokens (which in turn can be > another assertion by the way.) > > Authorization Endpoint is another function. It can be located anywhere. In > your case, it is located in what you call as Resource Owner (Browser > plug-in?) In my Self-Issued IdP case, it is issued by the App in the phone > which is called by the custom schema. > > This is the reason why I constantly grumble that it is better to speak in > terms of functions rather than entities. > Functions may reside in any entity, and if we talk only in terms of the > entities, the combination will explode. > > Nat > > On Thu, Dec 6, 2012 at 9:46 AM, <[email protected]> wrote: > >> >> As I understand, RO=issuer does not mean RO=AS. >> RO as an issuer generates assertion (if the assertion is similar to >> delegation statement in my use cases), >> AS as an assertion verifier receives the assertion and check its validity. >> >> >> >> [email protected] 写于 2012-12-06 01:35:10: >> >> >> > Just checking that I understand: If the RO == the issuer, then the >> > RO == the AS, right? Just as in Nat's example, the user (or at least >> > the device presenting a user agent to them) == the IdP? Colocating >> > the RO and AS functions shouldn't be precluded, but I would be >> > awfully confused if there were an RO/issuer in the picture and >> > *also* an AS that *doesn't* issue assertions. >> >> > >> > Eve >> > >> > On 5 Dec 2012, at 9:13 AM, Nat Sakimura <[email protected]> wrote: >> > >> > 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]> >> 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]> wrote: >> > >> > >> > >> > Chuck Mortimore <[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]> wrote: >> > > >> > > >> > > Obviously, it is not so clear from the language there. >> > > >> > > >> > > Chuck Mortimore <[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]> <zhou. >> > [email protected] >> > > > > wrote: >> > > > >> > > > >> > > > +1. >> > > > And why it was not looked at that time? >> > > > >> > > > [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]> >> の >> > > > > メッセ�`ジ: >> > > > >> > > > > >> > > > > could be Resource owner? >> > > > > >> > > > >> > > > > >> > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <[email protected]> >> >> > > > > 发件人: [email protected] >> > > > > 2012-12-03 16:49 >> > > > > >> > > > > 收件人 >> > > > > >> > > > > "ext Nat Sakimura" <[email protected]>, "Brian Campbell" < >> > > > > [email protected]>, "oauth" <[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] [mailto:[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 maybe >> 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 >> > > > > [email protected] >> > > > > https://www.ietf.org/mailman/listinfo/oauth >> > > > >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > OAuth mailing list >> > > > > [email protected] >> > > > > https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ >> > > > > OAuth mailing list >> > > > > [email protected] >> > > > > https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > [email protected] >> > > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > 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 >> > >> >> > >> > >> >> > >> > -- >> > Nat Sakimura (=nat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > Eve Maler http://www.xmlgrrl.com/blog >> > +1 425 345 6756 http://www.twitter.com/xmlgrrl >> >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > 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 > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
