Hi Dick, 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? 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 [EMAIL PROTECTED]) and anyone else. I suspect the latter case will be unlikely, if OpenID is to be successful. > 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.". > > 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? > > 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. >From what I can tell so far, it seems to me that the differences between an OP and an IdP are not significant. - John > > -- Dick > > [1] http://www.oasis-open.org/committees/download.php/11886/saml- > glossary-2.0-os.pdf > > On 30-Oct-06, at 10:27 PM, Recordon, David wrote: > >> I'll let Dick explain since it was his proposal and I didn't really >> care about if we changed the name or not. ;) >> >> --David >> >> From: Patrick Harding [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 30, 2006 7:47 PM >> To: Recordon, David; specs@openid.net >> Subject: RE: "Editors" Conference Call >> >> Dave, >> Can you please clarify how an OpenID Provider is 'very' different >> from the role of Identity Provider as defined in SAML or WS-*. >> Thanks >> - Patrick >> >>> Rename "Identity Provider" to "OpenID Provider" (IdP -> OP) to add >> clarity to the term since IdP has a very different meaning in the SAML >> and WS-* worlds >> >> >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] on behalf of Recordon, David >> Sent: Mon 10/30/2006 7:51 PM >> To: specs@openid.net >> Subject: "Editors" Conference Call >> >> This morning Dick, Josh, and I got on Skype for 2.5 hours to try and >> hash through all the remaining proposals. Unfortunately Brad couldn't >> join us, though I did talk to him about some of this stuff as well >> beforehand. >> >> - Authentication Age will be developed as an extension due to >> questions >> around what is the best way for it to work, what features does it >> need, >> etc >> >> - The field "setup_url" will be removed from a checkid_immediate >> response, rather the RP should fallback to a checkid_setup request to >> complete the transaction. It has been found that in the, albeit few, >> implementations of checkid_immediate this is the behavior for the >> setup_url anyway. >> >> - Support bare requests by having the field "openid.return_to" as >> optional in checkid_* requests. There is a worry of user's not >> knowing >> when they'll be redirected back and when they won't, though that will >> only be worked out by allowing this functionality. >> >> - Clarify that the openid.realm parameter should be used to uniquely >> identifier relying parties >> >> - There are some places where it could be clear in step-by-step >> instructions of what an IdP needs to do in various parts of the >> protocol, like is done in section 12 for rp's. Sxip will provide >> pointers to where this clarity can be added. >> >> - Rename "Identity Provider" to "OpenID Provider" (IdP -> OP) to add >> clarity to the term since IdP has a very different meaning in the SAML >> and WS-* worlds >> >> - The spec won't speak to what a RP should do if it has an identifier >> like "[EMAIL PROTECTED]", worried about setting a confusing >> precedent of >> allowing this form of identifier for discovery. Users are used to >> entering, "example.com" in their URL bar to goto the site, so entering >> the same to login doesn't seem like to far of a stretch. All of >> OpenID >> has a user education challenge and this doesn't seem very different. >> >> - Spec will say in essence, "RP's SHOULD give the text field a user >> enters their OpenID Identifier a name attribute with a value of >> 'openid_identifier', though if a RP wishes to support rich clients it >> MUST do so". >> >> - Dick will be writing a separate document discussing how RPs can >> advertise services, logos, etc >> >> - There cannot be parameters with the same name, make sure spec says >> this, we think it does. >> >> - Josh will be updating his delegation proposal patch to specify two >> identifiers for all transactions. This will create a consistent >> paradigm when dealing with delegation or when not. >> >> Goal is to have all of these changes made by end of day Wednesday. I >> doubt I've added enough detail in all places, so feel free to ask for >> clarifications or wait to comment on the next draft. >> >> --David >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
