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

Drummond Reed drummond.reed at cordance.net
Tue Nov 7 19:52:53 UTC 2006


Eve,

Welcome, and thanks for "delurking" ;-)

I'm fascinated by your suggestion that the SAML vocabulary includes the term
"authentication authority". I'd vote for the OpenID Authentication 2.0
specification (and the community at large) to adopt that term in a heartbeat
because: 

a) I've many times thought that "authentication authority" was PRECISELY the
role that the IdP/OP played in OpenID Authentication.

b) I'm all for consistency with the SAML glossary because I know it was
intended to be specification-neutral and I'm a big supporter of harmonizing
vocabularies in a problem space (that's why we spent so long on the XRI
glossary in the identifier problem space -- see appendix C of
http://www.oasis-open.org/committees/download.php/15377). 

c) It allows us to step around all the semantic issues around whether an
OpenID IdP is really "providing an identity" or not (and also whether OpenID
is using classic "identity federation" or not.)

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Eve L. Maler
Sent: Tuesday, November 07, 2006 8:16 AM
To: specs at openid.net
Subject: Re: IdP vs OP (WAS: RE: "Editors" Conference Call)

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




More information about the specs mailing list