>>We won't be duplicating work if our reasons for not specifying this
>>was to allow time for these other specs to "bake" to the point where
>>we can recommend them in general practice terms and perhaps specify
>>them for particular application areas, such as using XACML for access
>>control, SAML for general security and WSS for more specific web
>>services security, along with the emerging federated certification
>>authority for authentication of user identity. Then we have choices
>>to make with regard to PKI and XML signature that we can recommend
>>for electronic signing needs.
>>These specs have gotten to the point where these choices need to be
>>made and a lot more experience gathered.
Rex,
You've captured much of my own perspective regarding the practical
implementation of these Identity and Authority technologies in relation to
CAP. The bottom line is that we cannot implement CAP without addressing the
implementation realities faced on the front line. Dealing with these issues
directly in the context of the implementation guide will help associate CAP
more readily in terms of solutions. There is a difference between a
"protocol" and a solution. Providing examples of end-to-end implementation
solutions is invaluable to the community of potential implementers who face
the realities of architecture, technology and policy constraints in the
context of their respective organizations. Implementation is where the
rubber meets the road and invariably will assist with creating the momentum
needed to drive uptake. As you so aptly used the phrase "these choices need
to be made and a lot more experience gathered". As implementers we are all
facing similar if not related challenges.
Kwasi
-----Original Message-----
From: Rex Brooks [mailto:]
Sent: Thursday, May 20, 2004 9:25 PM
To: Art Botterell; Rex Brooks; Kon Wilms;
Subject: RE: [emergency] Identity and Authority ( was RE: CAP
Visualization...)
We won't be duplicating work if our reasons for not specifying this
was to allow time for these other specs to "bake" to the point where
we can recommend them in general practice terms and perhaps specify
them for particular application areas, such as using XACML for access
control, SAML for general security and WSS for more specific web
services security, along with the emerging federated certification
authority for authentication of user identity. Then we have choices
to make with regard to PKI and XML signature that we can recommend
for electronic signing needs.
These specs have gotten to the point where these choices need to be
made and a lot more experience gathered. I am hoping to have a
presentation from WSRP on security that I can refer our group to
review next week. Would've been sooner, but the guy who put in the
lion's share of the work was ill at the start of March during the
last F2F for that TC, and we are only now getting to it. The good
news is that it will be updated, hopefully, and there is a good
chance that the tech notes for UDDI and ebXML Registry for WSRP will
be ready soon, too.
While those are all issues that are somewhat particularized to WSRP,
it is a large enough subset of web services to be valuable, although
it would be expected for me to say that because I have worked on it
from its inception. However, I suspect that the Portal model is very
likely to be the one that shakes out as the dominant model for
integrating corporate IT web use that survives the next winnowing.
Ciao,
Rex
At 4:46 PM -0700 5/20/04, Art Botterell wrote:
>At 4:30 PM -0700 5/20/04, Rex Brooks wrote:
>>We chose not to make these decisions in the spec, but ought we
>>provide the reason why and suggest some best practices for various
>>levels of trust and security in the implementation/implementor's
>>guide?
>
>My question would be whether we might be duplicating work being done
>in other TCs and other organizations? Most of these issues are
>universal in web services applications of all sorts and
>telecommunications in general.
>
>- Art
>
>
>To unsubscribe from this mailing list (and be removed from the
>roster of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgr
oup.php.
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email:
Tel: 510-849-2309
Fax: By Request
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgro
up.php.
