Greetings, I have several questions regarding particular wordings in the OpenID 2.0 final specification and how it comes to affect real world RP implementations, and I was hoping this community might be the best to answer them.
First, with regards to section 8.2.1 for the response parameter expires_in for stateful associations, it is stated that: "The Relying Party MUST NOT use the association after this time has passed." It is obvious this intends that the RP will not send checkid_setup requests after this expiration has passed and that any concerns regarding clockskew are addressed by the OP sending assertions signed with a private handle. What is not immediately clear is if this also asserts that the RP must not accept assertions signed with this shared handle after expiration. Many RP libraries seem to assume this; as a result, there are situations where signed assertions are sent by the OP using the shared association, but the association is no longer known by the RP because it has been discarded. We commonly see this when there are clock skews between cluster members of the RP or OP, or when a large number of authentication events are being processed at the time boundary of expiration of the shared association handle. If it was intended that the association handle should be kept at an interval decided by the RP, should that be spelled out in the specification or best practices document? Secondarily, in section 11.4.2.2 regarding the parameter "invalidate_handle" that is sent as part of a positive assertion, it is stated: "Description: If present in a verification response with "is_valid" set to "true", the Relying Party SHOULD remove the corresponding association from its store and SHOULD NOT send further authentication requests with this handle. " Again, this is a similar concern as the first question. If it is meant that this assocation should no longer be used for checking the validity of incoming signed assertions, then it causes issues in a real-world working environment because it presumes an absolute ordering of events that does not exist. It seems that certain OPs (namely DotNetOpenAuth) attempt to compensate for this by using a private association when it is known that a shared association is near expiration. This seems like a fairly reasonable approach, however, I was unsure if it was the intent to require OPs to perform this type of determination or merely an oversight in the specification. In short: Should OPs be on the hook to avoid this specific issue, or should RPs?
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
