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


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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

Subject: Comment: Proposed Charter for OASIS Web Services Federation (WSFED)TC

1. The charter should indicate that the final deliverables
will include a conformance program. In our view, this is a
major omission as it is difficult to achieve product-level
interoperability without a formal conformance program.

If interoperability between independently implemented products
is a goal of this effort, then we propose that the
section titled "Deliverables" include a document or section
titled conformance requirements for WS-Federation. 

2. The charter includes material that essentially duplicates
the functionality found in the OASIS SAML 2.0 specification. 
The charter should clarify why the authors felt this to be necessary
and whether the final specification would have any relationship to SAML 2.0. 

If the charter proponents view this work as a successor or improvement 
over SAML 2.0, then the conformance program should provide recommendations
on interoperation with existing SAML 2.0 implementations.

3. The charter includes a section titled "Authorization" and 
one titled "Privacy". The section on "Authorization" should 
reference OASIS XACML 2.0. The section on "Privacy" should reference 
W3C P3P 1.0. 

We strongly recommend that the specification be informed by these works
and avoid ad-hoc reinvention of existing work. These references
should also be included in the section titled "General Notes on Scope".

4. In addition to the central topic of federation, this specification also 
addresses additional topics such as attribute services, pseudonym services,
authorization, and privacy. 

The value of the specification would be enhanced
if the specification were structured in a layered way with core material
restricted to federation and the subsidiary topics incorporated via
profiles or bindings. 

This would also support the widest possible
use of the core specification when communities or vendors prefer 
alternative approaches to the subsidiary topics. 

We recommend that discussion of the use of a layered specification 
structure be added to "General Notes on Scope". 

5. Federation Metadata

 - Will the specification describe how federation metadata could be
published to a UDDI repository? UDDI is a well known and standard
registry mechanism.

6. Attribute Services

- In this section it is unclear what component is proposed to be 
standardized. Is it an API or some sort of documentation technique
or a metadata specification?

- It is suprising that the general problem of attribute access
is being discussed here in item 2. Is there an explicit
intention here to go beyond identity attributes or is this an error?
It seems to lie outside the "Scope of Work" statement.

- There are many existing standards that speak to privacy
and access control such as P3P 1.0 and XACML 2.0. It is surprising that
these standards aren't referenced under item 3.

7. Authorization 

- XACML 2.0 is a well regarded OASIS standard for Authorization. 
It is surprising that this section makes no reference to XACML but 
rather chooses to invent an ad-hoc authorization service architecture. 
We would recommend that XACML 2.0 be referenced here and that the 
authorization service appropriately profile XACML 2.0. 

8. Authentication Types

- The SAML 2.0 specification includes a systematic and extensible mechanism
for describing authentication types - the SAML 2.0 Authentication Context
specification. We would recommend that this section reference the SAML 2.0
authentication context specification. Further, this specification 
be referenced in the section titled "General Notes on Scope".

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