RE: [security-services] Notify Message Structure (was: Blog post on Change Notify / comments on Aug 24 meeting)

["Nguyenphu, Thinh (NSN - US/Irving)" <thinh.nguyenphu@nsn.com>]

Hi,

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

It make sense to bundle multiple IDs into a single operation request.

Thinh

> -----Original Message-----
> From: ext Phil Hunt [mailto:phil.hunt@oracle.com] 
> Sent: Wednesday, September 01, 2010 4:11 PM
> To: OASIS SSTC
> Subject: [security-services] Notify Message Structure (was: 
> Blog post on Change Notify / comments on Aug 24 meeting)
> 
> 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
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
oups.php 
> 
>