OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Groups - SAML2 Change Notify Request/Response Protocol (saml2-notify-protocol-v1-wd04.zip) uploaded


Chad,

Good question. Yes, we have covered this quite a bit. But at this point it is probably worth reminding ourselves how we got here.  :-)

ChangeNotify simply sends notifications of changes. It does not pass data or perform work per se.  It sill requires a payload (or action) protocol (e.g. SPML) to transfer actual changes. By introducing a "notification" step in federated scenarios, it helps brings context to entity changes that might not otherwise be fully known or is firewalled between endpoints. E.g. one party wants to notify another of a new subject but doesn't actually know if the subject already exists. 

One of the other things that having 2-steps does is that a protocol that only has read operations is now be able to transfer changes. E.g. A "NewSubject" notification can be followed by a SAML Attribute Request to facilitate an "add" operation indirectly.

In federated scenarios there are firewalling issues where status of entities are not guaranteed between endpoints (unlike in an enterprise). As such, SPML becomes fragile except in well controlled scenarios. ChangeNotify introduces a 2-step process which begins with a notification step which can then be fulfilled by either SAML or SPML (or any other protocol) as the "payload" protocol. ChangeNotify creates some flexibility to solve the issue of a request to "add" failing because the entity previously exists at a service provider because the Target can decide instead to perform a SAML Attribute Request to merge the data.  Or, it can accept to continue with the SPML request. Because the target knows what is coming, it is able to set up its internal workflows to correctly process the intent of the message as appropriate to its own internal requirements.

If you look at the archive, you'll note that we started in drafts 1 and 2, with a more simplistic idea of just adding add/modify/delete operations to SAML. We began to realize the entity state problem would cause complex error issues for which SAML endpoints would not likely want to disclose detailed error.  E.g. on an add operation, a SAML IDP would likely not be willing to disclose if an entity already exists or not so it would just respond with a generic failure at best -- this would cause problems for the requestor as it couldn't figure out what happened. In the end, this is why we moved to the 2-step process in the current proposal.  The other nice feature was that it allowed for multi-protocol solutions where a notification could be sent and then transferred using SPML.

Phil
phil.hunt@oracle.com




On 2010-11-16, at 9:44 AM, Chad La Joie wrote:

> Hey Phil, Thinh,
> 
> I just joined the TC so I apologize if this has been covered before (don't know yet how to find the TC list archives).
> 
> Is there any concern about, what seems to me, the overlap of functionality between the Change Notify protocol and SPML?
> 
> On 11/16/10 12:00 PM, Phil Hunt wrote:
>> This is a reminder of the document reference for Change Notify Protocol.
>> If there are no questions, Thinh and I are recommending moving forward
>> to a vote for CD status.
>> 
>> Regards,
>> 
>> Phil
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>> 
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> *From: *thinh.nguyenphu@nsn.com <mailto:thinh.nguyenphu@nsn.com>
>>> *Date: *October 28, 2010 12:44:42 PM PDT
>>> *To: *security-services@lists.oasis-open.org
>>> <mailto:security-services@lists.oasis-open.org>
>>> *Subject: **[security-services] Groups - SAML2 Change Notify
>>> Request/Response Protocol (saml2-notify-protocol-v1-wd04.zip) uploaded*
>>> 
>>> Hello,
>>> 
>>> This is updated version 4 which it includes a completed profile and change
>>> the ActionProtocol element to attribute data.
>>> 
>>> Regards
>>> Thinh
>>> 
>>> -- Mr. Thinh Nguyenphu
>>> 
>>> The document named SAML2 Change Notify Request/Response Protocol
>>> (saml2-notify-protocol-v1-wd04.zip) has been submitted by Mr. Thinh
>>> Nguyenphu to the OASIS Security Services (SAML) TC document repository.
>>> 
>>> Document Description:
>>> SAML2 Change Notify Request/Response Protocol
>>> 
>>> View Document Details:
>>> http://www.oasis-open.org/committees/document.php?document_id=40036
>>> 
>>> Download Document:
>>> http://www.oasis-open.org/committees/download.php/40036/saml2-notify-protocol-v1-wd04.zip
>>> 
>>> 
>>> PLEASE NOTE: If the above links do not work for you, your email
>>> application
>>> may be breaking the link into two pieces. You may be able to copy and
>>> paste
>>> the entire link address into the address field of your web browser.
>>> 
>>> -OASIS Open Administration
>> 
> 
> -- 
> 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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]