Note: Relying Parties SHOULD accept and verify assertions about Identifiers for which they have not requested authentication.
Note: I'm interpreting the above as designed to enable both the OP returning a URI different than that requested, as well as the 'OP initiated' flow I'm discussing here.
In this flow, the user starts at the IDP/OP and requests to be sent to a particular RP (along with an 'assertion' as to their log-in status) rather than starting at the RP. (this was the only flow supported by SAML 1.1, it's interesting to see OpenID & SAML converging from different directions.)
How would this flow work in OpenID? Specifically, how would the OP know where to send the user's browser? In the default OpenID RP-initiated flow, the RP indicates to the OP this address with the openid.return_to parameter.
Value: (optional) URL to which the OP SHOULD return the User-Agent with the response indicating the status of the request.
In the case where there is no request coming from the RP from which the return address could be extracted, where should the OP send the User-Agent?
In SAML's IDP-initiated flow, the SAML IDP can obtain the 'AssertionConsumerService' endpoint URL from the RP's metadata.
OpenID has XRDS for metadata, but AFAIK, the model presumes that the user provides their OpenID to a RP - this identifier used to retrieve the list of services and endpoints from the XRDS doc. Could an OpenID user's XRDS document also list the RP endpoints to which unsolicited responses would be sent? Would a user need to remember their RP URIs so that the OP could ask them "Where do you want to go today?
In the same vein, how would an association be established between RP and OP - given that the OpenID 2.0 association mechanism presumes that the RP initiate the DH sequence?
Could it be that, for this OP-Initiated sequence to work, the RP and the OP must necessarily have previously shared endpoints and keys/trust information? Would this 'scale'?
Tags:
No comments:
Post a Comment