IdP vs OP (WAS: RE: "Editors" Conference Call)

[Eve L. Maler]

Delurking for the first time on this list: :-)

Drummond and I are on the same page about many things, but John is 
right that SAML is agnostic as to the strength/significance of the 
service being provided and so the two cases are much more similar 
than different.  On balance I prefer "identity provider" because 
it's intuitive in an English sense, it's used in several technology 
contexts (not just SAML and OpenID), and it avoids a terminological 
"branding" that would otherwise seem to suggest a conceptual 
divergence that doesn't -- to my mind -- exist.

(By the way, there's another term SAML defines that seems to fit the 
bill of what Drummond is going for here: "authentication authority". 
  This is not quite synonymous with "identity provider" in 
SAML-land, but it's close -- much the way that "relying party" and 
"service provider" are often close to the same thing.  I'm not 
seriously advocating using it -- just noting that the same software 
component in an actual deployment can be seen in various lights and 
have multiple names (roles!).)

FWIW,

	Eve

John Kemp wrote:
> Hi Drummond,
> 
> Drummond Reed wrote:
>> So why, indeed, is there so much interest in OpenID? I believe it's because
>> of the trust model. To the best of my knowledge, it is radically different
>> than the trust model assumed by the majority of use cases which led to SAML
>> and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID supports
>> "promiscuous federation" -- RPs and OPs that don't know anything at all
>> about each other. 
> 
> At http://www.openidp.org you'll find a promiscuous SAML IdP.
> 
> While I agree with you that OpenID has been focused on this use-case,
> with an eye to the use-cases satisfied by SAML, I'd say that SAML has
> been developed with federated use-cases, but also with an eye to
> promiscuity.
> 
> But to put it another way, the trust model used with SAML is
> out-of-scope for development of the SSO protocol itself.
> 
> Just like it is for OpenID.
> 
>> And it doesn't stop there. OpenID also supports OPs that
>> ***have zero control over the user's OpenID identifier***. The OP simply
>> provides a service for authenticating that a user has control of the OpenID
>> identifier about which the OP is being queried.
> 
> And how does one authenticate that the user has control over an
> identifier? Is it not by having the OpenID IdP having some secret shared
> with the user - maybe a password, say?
> 
> A SAML IdP also authenticates that an identifier (issued by the IdP in
> the SAML case) is bound to a particular user.
> 
>> This is a big deal. In fact, the closer you get to it, the bigger it is.
>>
>> As a result, even though an OP seems to fit the SAML definition of an IdP --
>> and many technical folks will be very comfortable treating the two as
>> synonymous -- getting the semantics right to stress who really is in control
>> of the identity ***right down to the identifier*** is very important.
>>
> 
> I don't think we need to worry about fitting the SAML glossary
> definition of an IdP, but rather we should focus on making an OpenID
> glossary definition that makes sense for what OpenID is doing.
> 
>> Whatsmore, I don't think this should or will "drive SAML and OpenID further
>> apart". In factit could actually help pave the path to convergence: an OP
>> can be defined as being a SAML IdP that provides identifier authentication
>> services using the OpenID protocol, which may end out (3.0?) becoming a very
>> specific set of SAML capabilities.
> 
> As noted earlier, I think a SAML IdP also provides "identifier
> authentication". I don't worry so much about convergence of these
> technologies (although that would be nice ;), but more about giving a
> converged message to users, developers, and purchasers of these
> technologies.
> 
> Regards,
> 
> - John
> 
>> =Drummond 
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
>> Of Recordon, David
>> Sent: Monday, November 06, 2006 11:46 AM
>> To: Dick Hardt; John Kemp; Patrick Harding
>> Cc: specs at openid.net
>> Subject: IdP vs OP (WAS: RE: "Editors" Conference Call)
>>
>> I see both sides of this discussion.  I think John is correct that the
>> role of an OP really is not that different than that of SAML's IdP.  The
>> difference comes down to the trust model.  I certainly think reputation
>> networks will exist which rate OPs, RPs, users, etc and will ultimately
>> be needed for a technologies with "promiscuous trust models" to thrive
>> in a large scale.
>>
>> I guess reading more of this is making me question if renaming IdP
>> really is the best thing to do in OpenID.  I think if anything we all,
>> as a larger community, should be working to bring OpenID and SAML closer
>> together versus driving them further apart.
>>
>> --David
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
>> Behalf Of Dick Hardt
>> Sent: Wednesday, November 01, 2006 2:20 PM
>> To: John Kemp
>> Cc: specs at openid.net
>> Subject: Re: "Editors" Conference Call
>>
>>
>> On 1-Nov-06, at 12:28 PM, John Kemp wrote:
>>> 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.
>> Technically possible, yes for the RP to decide on an IdP/OP.
>> Currently, there is no verified RP identity, so the IdP/OP cannot make
>> that decision.
>>
>>>> I have not had a chance to wade into that discussion.
>>> I'd highly recommend it when you get the chance.
>> in my queue :)
>>
>>>>> 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 security at .
>> I don't think there should be an OP reputation. I will wade into the
>> security@ list to discuss.
>>
>>
>>>> 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?
>> If the OP is making a separate claim about you, then it is not being an
>> OP at that time.
>> Perhaps I am missing your point here though.
>>
>>>>>> 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.
>> The OP has a mechanism to determine which user it is interacting with.
>> If the user is running her own OP, then there is still an  
>> authentication process of some kind such as access to the machine.
>>
>> -- Dick
-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.