[OpenID] Correlating Identifiers

[Peter Williams]

Yes, you are  right - and its consistent with the model.

discovery = test of authority of OP to speak for namespace (a pretty classical control). Additionally, its also a locator service, based on http1.1 proxying controls.

On receiving an unsolicited response - or a response that we TREAT as an unsolicited response (becuase its response.claimed id != request.identity), then we do (i) ore discovery as an RP or (ii) abandon (if particularly when an RP doesn't support unsolicited responses).

if this is the second round of discovery by an RP for a given run, then formally we are JUST testing for authority. if the second round does not positively confirm the authority of th OP to speak for the namespace, then the RP SHOULD simply treat the discovery result as if it were a  first round discovery ...and thus openid auth starts again.

Is that the concept (stripped of spec language)?

-----

As I said once before (~12 months ago, when I LAST half-understood things), this of course allows for "redirects" between OP, perhaps better described as OP proxying/chaining. Thus, an RP can find itself "walking" an authority tree, rather like ENUM. As the walking process depends on the http redirect resolution (which is obviously influenced by any HTTP proxy used by the UA), a users own XRDS can be controlling this OP-proxying.




________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Manger, James H [James.H.Manger at team.telstra.com]
Sent: Thursday, November 06, 2008 2:39 PM
To: OpenID List
Subject: Re: [OpenID] Correlating Identifiers

Peter Williams asked
> Dont OpenID state machine rules require an RP to reject a identity claim
> from the OP that fails to match the requested identity?
>
> Isnt the ONLY exception to that when the RP/user has invoked the
> directed-identity flow ?


No and No.

If the identity in the OP response does not match the identity in the request (which came from earlier discovery) the RP should perform discovery again. If the second discovery (this time on the identity in the OP response) matches then OpenID authentication has succeeded.

OpenID 2.0 §11.2 "Verifying Discovered Information" says:
[http://openid.net/specs/openid-authentication-2_0.html#verify_disco]

  "If the Claimed Identifier is included in the assertion, it MUST have been
  discovered (Discovery) by the Relying Party and the information in the
  assertion MUST be present in the discovered information. The Claimed
  Identifier MUST NOT be an OP Identifier."

  "If the Claimed Identifier was not previously discovered by the Relying
  Party (the "openid.identity" in the request was
  "http://specs.openid.net/auth/2.0/identifier_select" or a different
  Identifier, or if the OP is sending an unsolicited positive assertion),
  the Relying Party MUST perform discovery on the Claimed Identifier in the
  response to make sure that the OP is authorized to make assertions about
  the Claimed Identifier."

The important phrase is "or a different Identifier" -- indicating that the RP must perform discovery after receiving a response, not just for directed identity, but also whenever the requested id does not match the response.


James Manger

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general