Re: [security-services] Comments on Change Notify

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

Okay, before I go further, I guess I should check an assumption.  I felt 
like this protocol was attempting to provide a means of pushing subject 
information from an authority to a service in order to keep the service 
up to date.  Is that correct?

On 11/19/10 8:58 PM, Phillip Hunt wrote:
> See below.
>
> Phil
>
> Sent from my phone.
>
> On 2010-11-19, at 15:39, Chad La Joie<lajoie@itumi.biz>  wrote:
>
>> 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.
>
> To understand how we got here you need to look at the earlier drafts and the feedback in particular from Scott.
>
> I would be more than happy with a single step protocol but the issue of state remains to be solved. Because state is not known the push before pull seemed to be the best compromise.
>
> Note that yes we modified it so that partners can nego push followed by push as well.
>>
>> 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.
>
> That would significantly reduce information and create a wordy modify request. The idea is to keep all notifications light weight. The issues u speak of can still be handled in spml following the notify.
>
> What may be more useful is more errr signaling. Eg entry already exists. But I suspect in federated environs partners may not be willing to provide detailed errors.
>>
>>   - 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).
>>
> See above.
>
> Error responses are minimized. The idea behind a notify step is to reduce need for signalling, which federated entities prefer not to exchange anyway.
>
> Also note that most actual error occurs in the action protocol. So the errors you speak of are spml errors occurring in the second step.
>
> If however partners use saml for second step the pull after push won't have issues with an erroneous "newsubject" since the target is controller the saml attribute request.
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

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