Re: [security-services] Comments on Change Notify

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

So, Phil and I had a nice call yesterday and I just wanted to send the 
results.

I think I agree with the general form of the protocol.  I believe there 
needs to be some:
- Clear, expository, non-normative text added to the introduction to 
better make the case for the protocol
- Clear text added to the description of the new/modify/retire messages 
to indicates that the new/modify/retire'ed "state" of the subject is 
just the issuer hinting what it thinks the current state is.  It does 
not reflect anything about the expected state at the target.

One question that Phil asked me is whether I thought the document should 
go forward to a committee draft or stay at a working draft until some 
more details get worked out.  My opinion is that as long as it is 
possible to make substantive/behavioral changes to the protocol while 
the document is in committee draft mode then it is fine to move forward. 
  If that is not possible then it should stay as a working draft until 
some more items can ironed out.

I also told Phil that I'd take on a few action items:
- provide any editorial comments that I can with an eye towards cleaning 
up some of the led to me drawing some incorrect conclusion about the 
protocol
- review the document with an eye towards how this protocol might 
operate in an environment with a large number issuers and targets and 
seemingly dynamic relationships (a.k.a. the education and research 
federation environment).
- offer a couple of additional uses cases, from the aforementioned E&R 
environment, that can be included in the document in order to help 
elucidate some possible usage and flows of the protocol

It'll probably take me a month or so to get all of those items done.

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