"Editors" Conference Call

[Dick Hardt]

On 1-Nov-06, at 11:33 AM, John Kemp wrote:

> Hi Dick,

Hi John!

>
> 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?  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 security at openid.net)
> and anyone else.

I have not had a chance to wade into that discussion.

> 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.


>
>> 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.

>
>>
>> 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).


>
>>
>> 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?


>
> From what I can tell so far, it seems to me that the differences  
> between
> an OP and an IdP are not significant.

See above wrt. "trust".

-- Dick