Dick Hardt wrote: >> It would be nice to see a clear definition of an OP in order to >> determine the exact differences between such an entity and an IdP, but, >> in the absence of such, some questions: >> >> Dick Hardt wrote: >>> Thanks David! ;-) >>> >>> Patrick, as you point out, Identity Provider is a well understood >>> term in SAML and WS-*. Here is the definition from SAML 2.0 [1] >>> >>> Identity Provider: A kind of service provider that creates, >>> maintains, and manages >>> identity information for principals and provides principal >>> authentication to other service providers within a federation, such >>> as with web browser profiles. >>> >>> Per the definition, Identity Provider implies a federation or trust >>> relationship between the IdP and RP. >> >> And I guess there is no similar concept in OpenID? Like perhaps an RP >> adds a particular (I hate to use the word) "trusted" IdP to a whitelist >> of IdPs from whom it accepts assertions? Or vice-versa? > > Is it technically possible?
OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. > Yes. Just like it is technically possible > for SAML to be user-centric. :-) > >> >> Admittedly, such "federations" might not be as linked to static business >> agreements perhaps as in a typical SAML deployment, but it seems they >> would be necessary unless you base "trust" on public key-based >> mechanisms, or decide that you'll accept assertions from >> "no-password.com" (to quote from a discussion on [EMAIL PROTECTED]) >> and anyone else. > > I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. > >> I suspect the latter case will be unlikely, if OpenID >> is to be successful. > > And I do not. And that is the big driver why it should be OP instead of > IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some IdP (and vice-versa). Whitelists and blacklists seem like a scalable and dynamic way of doing that, and would seem to be a reasonable way of minimizing the presence of rogue IdPs. Don't take my word for it though - look at the discussion on [EMAIL PROTECTED] > > >> >>> Additionally, IdPs often provide >>> other assertions about the user. >> >> This is sometimes called "attribute exchange". In OpenID, is it then not >> possible for an OP to exchange attributes related to a particular OpenID >> with an RP? There seems to be an "attribute exchange" specification >> (http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it >> says (for example, in section 2) "Fetch retrieves attribute information >> from an Identity Provider, while store saves or updates attribute >> information on the Identity Provider.". > > When I talk about assertions, I mean third party claims, not self > asserted data. > The OP is not verifying the accuracy of any of the attributes in > attribute exchange. A claim by my IdP/OP /might/ be a claim by a third-party, no? And if the IdP/OP makes such a claim on my behalf (and is not under my direct control), won't it at least want to verify that the subject of the claim is also the user whose identifier it asserted in OpenID Authentication? > >> >>> >>> In OpenID Authentication, there is no trust relationship requirement >>> between the IdP and RP., and the only thing the IdP asserts is a >>> binding between the user and an identifier (OpenID URL or i-name). >> >> And on what basis does the OP "assert" this binding to an RP? Doesn't >> the OP typically "authenticate" that binding, or does it simply take the >> users identifier on blind faith, and assert away? > > The OP authenticates the user (how the OP authenticates the user is out > of scope of the spec). OK - so the user probably maintains an "account" with the OP, very much like a user would with an IdP? Unless the user runs her own OP. > > >> >>> >>> As people familiar with SAML / WS-* review the OpenID Authentication >>> specification, there has been some confusion on exactly what the IdP >>> does in OpenID. To make it clear that an IdP in OpenID is not the >>> same as typical deployments in SAML, we decided to call it the OpenID >>> Provider, which is more precise, and reduces ambiguity. >> >> I guess until we see this precise definition, we won't be able to see >> the precise differences. > > How about: > > An OpenID Provider acts on behalf of the user in responding to > OpenID Authentication requests from a Relying Party. > > What more do we need in the spec then that? What about: "An OpenID Identity Provider acts on behalf of the user in responding to OpenID Authentication requests from a Relying Party."? I guess you might want to add something about such an entity typically authenticating the binding between an OpenID and some subject/principal/user. - John _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
