Brian Campbell <bcampb...@pingidentity.com> 写于 2012-12-07 07:03:38:
> 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. Or we can start a new draft extending and clarifying the assertion document, more use cases could be implemented by assertion may be included, and other things... > > > > > On Thu, Dec 6, 2012 at 12:50 AM, Nat Sakimura <sakim...@gmail.com> 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, <zhou.suj...@zte.com.cn> 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. > > > > oauth-boun...@ietf.org 写于 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 <sakim...@gmail.com> 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 <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> 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> wrote: > > > > > > > > Chuck Mortimore <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> wrote: > > > > > > > > > Obviously, it is not so clear from the language there. > > > > > > > > > Chuck Mortimore <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 > > > > > wrote: > > > > > > > > > > > > +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: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> の > > > > > メッセージ: > > > > > > > > > > > > > > could be Resource owner? > > > > > > > > > > > > > > > > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com> > > > > > 发件人: oauth-boun...@ietf.org > > > > > 2012-12-03 16:49 > > > > > > > > > > 收件人 > > > > > > > > > > "ext Nat Sakimura" <sakim...@gmail.com>, "Brian Campbell" < > > > > > bcampb...@pingidentity.com>, "oauth" <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] > > 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 > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > 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 > > 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 > > > > > > Eve Maler http://www.xmlgrrl.com/blog > > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > _______________________________________________ > > OAuth mailing list > > 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 > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
