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] SAML enhancement proposal from NSN

Title: SAML enhancement proposal from NSN
I have significant concerns about the Attribute Management Protocol proposal.
SAML has avoided any kind of update protocol for good reasons. I am not ready to say I oppose ANY such scheme, but there are a number of matters that need to be considered.
1. The proposal appears to duplicate functionality defined in other standards or open proposals, including
SPML http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=provision
and CARML. http://www.openliberty.org/wiki/index.php/ProjectAris
It may well be that this proposal provides necessary functionality missing from any other specification or that there are reasons why doing it in SAML is superior to any other approach, but this needs to be documented explicitly.
2. The semantics of updates in a distributed environment are always complex and requirements and level of required support must be made explicit.
Off the top of my head:
What are the semantics of the update? Exactly what fields in the assertion are deemed to be being updated?  Can a new Subject be added or only attributes be updated? Can the issuer be changed? Validity Interval? other Conditions? Can Attribute be added or only existing ones changed?
What are the error semantics? How are partial errors handled and signaled?
What are the transaction semantics? Is the update atomic?
When is the update expected to be visible? How does it interact with replication? What about conflicting updates?
Is modify the only required action? What about Create? Delete?
3. Authorization is likely to be complex, involving not only fine grained access control and forms of delegation. (Nothing XACML can't handle of course.)
Authentication of the SP and likely the User is going to be a lot more critical.
Is control to the attribute/action level required?
At a minimun, this scheme will make the IPD threat model a lot more complex.
I am sure there are other issues as well, but I wanted to mention my concerns prior to the call today.
-----Original Message-----
From: Nguyenphu, Thinh (NSN - US/Irving) [mailto:thinh.nguyenphu@nsn.com]
Sent: Tuesday, September 15, 2009 1:42 PM
Cc: Guenther, Christian 1. (NSN - DE/Munich); Abendroth, Joerg (NSN - DE/Munich)
Subject: [security-services] SAML enhancement proposal from NSN


My name is Thinh Nguyenphu from Nokia Siemens Networks.  My colleague and I are summiting two new contributions, which its propose new enhancement to SAML.

Enclosed contributions are SAML Attribute Management Protocol, and SAML Name Identifier Protocol.

<<SAML Name Identifier Protocol.ppt>> <<SAML Attribute Mgt Protocol.ppt>>
I kindly request to be included in next TC SS agenda, September 22.

Best Regards,

Thinh Nguyenphu
Mobile: +1 817-313-5189

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