Comments on Change Notify

[Chad La Joie <lajoie@itumi.biz>]

So, I've taken time to review the comments in the archive and Phil's 
blog and here are my comments on the Change Notify protocl.

First, I disagree that this is a pull protocol.  The protocol requires 
the initial push for anything to take off.  I say this not to get in to 
a argument over semantics but because the "push then pull" model 
introduces the following set of issues that would go away if the 
protocol were just a push protocol.

   - It doubles the number of request/response pairs if the receiver of 
the push does ask the issuer for the changed data, which I would assume 
is the default expectation.  In addition, it increases the overall 
amount of data that flows over the network and needs to be processed.

   - If the goal is to make a change set, as opposed to just the current 
record state, available to the notify target then the notify issuer will 
have to keep track of that change set until the target retrieves it. 
That obviously puts a burden on the notify issuer.

   - It assumes that the issuer has the same information about the 
change when the target contacts the issuer as when the issuer became 
aware of the change.  This may not be true.  For example, one change 
defined in SPML is a password change.  At the instant a password change 
is occurring the change service will have the clear text password but 
that information is, in many cases, going to be stored in a hashed form 
once the operation completes.  If that is the case the notify issuer 
will not be able to provide the clear text password to the target when 
it is requested.

Given this, I personally think it makes much more sense to just admit 
that this is a push protocol and push the data in the first message. 
That would reduce the total number of request/response pairs, remove the 
need for the issuer to track change sets, and remove any possibility 
that the issuer had "lost" information between the notification and pull.

Second, I am concerned about the implied requirement for total ordering 
of the messages.  There is no documentation about what happens if, for 
example, an modify shows up before an add, or an add after a retire.  I 
think the best way to address this would be to make two changes:

   - Get rid of the NewSubject request and just use the ModifySubject. 
The issuer can't know whether this is really a new subject to the 
target.  If there is a desire to allow the issuer to provide a hint that 
it thinks this is a new record than add an attribute to the modify 
request that would signal this.  Whether the target wants to act on that 
information or not would be up to it.

   - Define an illegal state error (see next comment) that could be 
returned for cases where modifies showed up after a delete.  This way 
some one at the issuer could be warned that their change failed and take 
action (or ignore the warning).

Lastly, the protocol doesn't seem to address any error conditions. For 
example, how does the target tell the notifier that it will not accept a 
request?  The lack of this specificity seems like it would really hurt 
interoperability.

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered