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

Tue Nov 7 18:26:11 UTC 2006

Why are the Liberty people so keen to keep the term IdP in OpenID? :-)

We are changing the name because people were confusing what role IdP  
played in OpenID. They presumed it was the same role as in federation  
where trust was required.

-- Dick

On 7-Nov-06, at 8:15 AM, Eve L. Maler wrote:

> 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.
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>