On 12-Oct-06, at 5:44 PM, Gabe Wachob wrote: > *If* we are going to open up the terminology discussion, for me the > terms > "authenticating party" (formerly the "IDP") and "accepting > party" (formerly > the "relying party") seem more descriptive. The authenticating > party issues > authentication assertions in the form of special HTTP request/ > responses with > the other party, who then accepts these assertions and decides > whether or > not they are good enough to let a user do something.
The accepting party ALWAYS accepts valid assertions from an IdP. ie. there is no choice in deciding if the user is a given identifier. The RP can decide if they want to let that identifier have access to any resources. I would propose that the term "Homesite" be used when prompting the user to type in their IdP. I think the term "Identity Provider" is overloaded and not user friendly. The industry understands the term IdP from Liberty / SAML protocols. The role of an IdP in OpenID is quite different then it is in a Federation model. In the Federation model, there is an explicit trust relationship between the IdP and the RP. This is not the case in OpenID. In OpenID, the IdP is really an agent for the user, it is NOT making claims about the user, it is allowing the user to easily prove they are a particular entity. This is a subtle, but important difference. The OpenID IdP is NOT making any claims about the user. The URL presented to the RP has no meaning except for the RP to know it was the same user it saw before, and to link the user to other claiims / data. I think it would benefit the spec to use a different name then IdP if for no other reason then to clarify this difference between how OpenID and Federation work. I would propose Identity Agent, as it is acting on behalf of the user, and covers both a hosted and client implementation. my $0.02 -- Dick _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs