Blog post on Change Notify / comments on Aug 24 meeting

[Phil Hunt <phil.hunt@oracle.com>]

All,

In efforts to get more input on the ChangeNotify proposal, I have written a blog post describing Change Notify and how it converts traditional state based "push" provisioning operations into stateless "pull" operations.
http://independentidentity.blogspot.com/2010/08/pulling-for-change.html

I have received some interest in pursuing a lightweight notification standard that can run outside of SAML as well. While there are some pros/cons to this, 
my feeling is that having a full SAML based implementation is important. My feeling is that there will still be partners that feel the need to keep all traffic secured using the SAML core specs and thus a full SAML "native" solution is important.

My thought is to gauge interest at the next west coast IIW. Thoughts?

As for yesterday's TC call, my apologies for arriving just as the call ended. I agree with Thinh. We need to review section 2.7.2.  Can the normal web sso profile handle the requirement mentioned in the front-channel example? For me there are 2 issues:
1. Initial negotiation of identifiers - per the NSN requirements
2. Triggering a specific set of attributes to be transferred the first time a user federates. Example, the IDP believes this to be potentially the first time the user has accessed the relying party and is indicating a potential "new user". There are cases where the attribute flow for first time federation is different than normal SSO attribute flow. [btw. the fact that the attribute flow changes during initial sign on isn't necessarily an optimal approach in my opinion, I just note that the use case has been arising]

Phil
phil.hunt@oracle.com