Notify Message Structure (was: Blog post on Change Notify / comments on Aug 24 meeting)

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

Just thinking about the basic structure a bit further.

We have 2 approaches.

1. Current approach (tunnel approach).  A single message type "ChangeNotifyRequest" that contains one or more sub-operations
2. SubjectQueryAbstractType approach.  Each operation has its own first level message (e.g. like AttributeQuery)

If we go with the AttributeQuery type of construction, would we be limiting to one operation per message?

The trade off here is a single multi-purpose message type that can contain multiple operations (even bulk). Or a multiple message types, each simpler, that potentially contain only one operation per message.

The feedback I have received so far is to have a message that can contain multiple operations. That way notification messages might not have to occur as frequently.  For a VERY large IDP of millions of users, change notifications could be restricted to every n seconds.  The trade off is many messages every second or, one bigger message every n seconds.

The current approach actually allows both parties to choose frequency. I think approach 2, might be a bit noisier.  

As a compromise, we could allow multiple identifiers in a single add / change / retire message?

Phil
phil.hunt@oracle.com




On 2010-09-01, at 1:15 PM, Scott Cantor wrote:

>> Hmmm. I was kind of following the way ManageNameIDRequest was set up. Is
>> this not the preferred way?
> 
> That wasn't a terribly well thought out message, and it mostly just got
> copied from Liberty.
> 
>> I am open to using "NewPrincipal"/"ChangePrincipal"/"RetirePrincipal".
> How
>> do others feel?
> 
> I don't specifically object to using Subject, I simply noted that I don't
> think you want the saml:Subject element in there. The "standard" way to
> identify a principal in SAML is a BaseID/NameID/EncryptedID choice triple.
> You'll see that in various places.
> 
> -- Scott
> 
>