Re: OpenID Attribute Exchange Protocol questions
On 6-Jul-07, at 3:54 AM, James Henstridge wrote: Not entirely; the OP MUST NOT honor check_authentication requests for shared associations (this would allow a type of attack). Okay. In that case it sounds like it would be best practice to generate a private association handle for each unsolicited response since there is no guarantee that the RP has kept hold of its association handle, so may not be able to verify the update if a pre-existing handle is used. The OPs knows the expiration time for each handle, so if they link them with the update URLs they can determine their validity. But most of the time the updates will probably happen at much longer intervals than association expiry time, so using private association would be required. Would that be appropriate to include in the spec or some best practices document? I see this as a pure OpenID (core) issue and don't feel the need to touch it in the AX spec. I don't think it's implied anywhere (or a good design) to keep state between the original request and subsequent updates. So the RP cannot infer the 'removed' statement just because an update did not contain an attribute that was part of the original exchange. The update message is a fetch response, so I think it should be interpreted as such by the RP: the user has a new phone number. Then the RP can decide what it wants to do with the new value, as if it had requested the same attributes again. Thank you for the clarification. It seems that an OP will get the most consistent results if it always sends all attributes in an update then, so it doesn't need to track whether intermediate updates failed (or track exactly which attributes were changed). Sending all of the originally requested attributes would also require the OP to keep an original request data structure for each Fetch Request with an update_url in it, with the possibility of conflicting / overlapping requests. A cleaner way would be to attach a list of update URLs to each attribute in the user's profile, and when that attribute's value changes to post an update to the RP (after prompting the user etc.). To indicate that the user has deleted an attribute, the count=0 mechanism can be used: An openid.ax.count.alias with a value of 0 together with its corresponding openid.ax.type.alias field MAY be included to explicitly state that no values are provided for an attribute. It might be worth demonstrating this in the example from section 5.2 then. Currently it reads: openid.ax.type.gender=http://example.com/schema/gender ... openid.ax.value.gender= If this is a case where the user has not given their gender it should perhaps use openid.ax.count.gender=0 instead. You are right - thanks for catching this one as well! Previous drafts required that empty values are sent if the user did not send a meaningful value (which led to confusions and were clarified with the count param). Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 10-Jul-07, at 1:47 AM, James Henstridge wrote: On 10/07/07, Johnny Bufu [EMAIL PROTECTED] wrote: On 6-Jul-07, at 3:54 AM, James Henstridge wrote: Would that be appropriate to include in the spec or some best practices document? I see this as a pure OpenID (core) issue and don't feel the need to touch it in the AX spec. That would be appropriate if the OpenID authentication spec covered the idea of unsolicited OpenID responses. Given that it does not cover unsolicited responses and the AX spec uses them, it would seem sensible for the AX spec to describe in detail how they are meant to work. The appropriate place would be in the core spec so that other extensions would work the same way. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 10-Jul-07, at 1:47 AM, James Henstridge wrote: I don't think it's implied anywhere (or a good design) to keep state between the original request and subsequent updates. So the RP cannot infer the 'removed' statement just because an update did not contain an attribute that was part of the original exchange. The update message is a fetch response, so I think it should be interpreted as such by the RP: the user has a new phone number. Then the RP can decide what it wants to do with the new value, as if it had requested the same attributes again. Thank you for the clarification. It seems that an OP will get the most consistent results if it always sends all attributes in an update then, so it doesn't need to track whether intermediate updates failed (or track exactly which attributes were changed). Sending all of the originally requested attributes would also require the OP to keep an original request data structure for each Fetch Request with an update_url in it, with the possibility of conflicting / overlapping requests. A cleaner way would be to attach a list of update URLs to each attribute in the user's profile, and when that attribute's value changes to post an update to the RP (after prompting the user etc.). The issue I was thinking of was how to handle a lost update. In cases where two attributes are related (like two components of a postal address), I'd want to make sure the RP has matching versions of those attributes. An update could be lost due to temporary network failures, or possibly if the RP could not verify the update (e.g. if an association handle is used that the RP does not have). If the OP does not successfully send the update, I would hope that a *good* OP implmentation would try again until it was successful. I imagined that an OP would retain the state of an original request and update URL. Good point brought up about subsequent requests. A mechanism for indicating that request B replaces request A is needed so that the RP does not get an update for each request that has ever been made. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
[replying to myself] On 10/07/07, James Henstridge [EMAIL PROTECTED] wrote: The only real constraint the authentication spec places on the RP is that it maintain the association for the duration of an OpenID authentication request. With unsolicited response though, there is no prior request that tells us the RP is holding a particular association _right now_. I just realised another difference when working with unsolicited responses. With a normal OpenID authentication request the RP picks an association handle, so we know the RP believes it is valid. However, the OP can use a private association handle in the response if it considers the handle from the request to be invalid. So the OpenID authentication spec does not seem to require either the RP or OP to store an association for longer than ~ one request. In contrast, if a previously established association is used in an unsolicited response there doesn't seem to be any way the RP can tell the OP that it has lost the handle. Given that there doesn't seem to be any way to recover from this situation, it seems like private associations are the only sane option for unsolicited responses. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote: Given that there doesn't seem to be any way to recover from this situation, it seems like private associations are the only sane option for unsolicited responses. An update message would require direct verification and not use an association. Associations are set by the RP, and in this case, the OP is initiating the conversation. I might be missing something, but I don't see how you can reliably use an association. That was the conclusion that I came to. I was replying to Johnny's statement that the OP knows the expiry time of the association handles it stores so could use a previously negotiated handle in the unsolicited response. I think it would be good to include a statement to this effect in the specification so that implementers don't have to work this out for themselves (and maybe get it wrong). James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 10-Jul-07, at 8:43 AM, James Henstridge wrote: On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote: Given that there doesn't seem to be any way to recover from this situation, it seems like private associations are the only sane option for unsolicited responses. An update message would require direct verification and not use an association. Associations are set by the RP, and in this case, the OP is initiating the conversation. I might be missing something, but I don't see how you can reliably use an association. That was the conclusion that I came to. I was replying to Johnny's statement that the OP knows the expiry time of the association handles it stores so could use a previously negotiated handle in the unsolicited response. I think it would be good to include a statement to this effect in the specification so that implementers don't have to work this out for themselves (and maybe get it wrong). Looks like it's already in the spec, in section 10, Responding to Authentication Requests: If no association handle is specified, the OP SHOULD create a private association for signing the response. The OP MUST store this association and MUST respond to later requests to check the signature of the response via Direct Verification. http://openid.net/specs/openid- authentication-2_0-11.html#responding_to_authentication Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange Protocol questions
On 10-Jul-07, at 10:52 AM, Johnny Bufu wrote: On 10-Jul-07, at 8:43 AM, James Henstridge wrote: On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote: Given that there doesn't seem to be any way to recover from this situation, it seems like private associations are the only sane option for unsolicited responses. An update message would require direct verification and not use an association. Associations are set by the RP, and in this case, the OP is initiating the conversation. I might be missing something, but I don't see how you can reliably use an association. That was the conclusion that I came to. I was replying to Johnny's statement that the OP knows the expiry time of the association handles it stores so could use a previously negotiated handle in the unsolicited response. I think it would be good to include a statement to this effect in the specification so that implementers don't have to work this out for themselves (and maybe get it wrong). Looks like it's already in the spec, in section 10, Responding to Authentication Requests: If no association handle is specified, the OP SHOULD create a private association for signing the response. The OP MUST store this association and MUST respond to later requests to check the signature of the response via Direct Verification. http://openid.net/specs/openid- authentication-2_0-11.html#responding_to_authentication That does not explain why no association handle was specified. I think adding language to explain that an OP may initiate a conversation and the message would be verified by Direct Verification as no association is available. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
