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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


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.

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:rexb@starbourne.com] 
Sent: Thursday, May 20, 2004 9:25 PM
To: Art Botterell; Rex Brooks; Kon Wilms; emergency@lists.oasis-open.org
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: rexb@starbourne.com
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.


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