RE: Following up on XML Security

First, congratulations to Joseph for being listed as on of Technology
Review's top 100 technology innovators.


> 2. There's the question of tokens and kerberos support. I 
> don't understand 
> this quite yet (e.g., in 1.2 why is the UsernameToken above 
> the Signature, 
> but a reference to it is in the KeyInfo. Why not locate it in 
> the KeyInfo?) 
> I'm not sure where this should be addressed.

I suspect there that the rationale had more to do with not changing other
people's specifications without including them in the discussion.

I think that we need to achieve two things here, 1) make WS security headers
support Kerberos, 2) make XML Signature and XML Encryption support Kerberos.
Addressing 2 also solves 1. which is why that approach is to be preferred.


> 3. You mentioned a Kerberos KeyInfo. That sounds reasonable 
> but one of the 
> things I don't understand, per above, is how this is 
> different than the 
> token? Could it be tiny in a short spec? Also, do we imagine every  
> algorithm and key structure needs to be standardized by the W3C?

At this stage the deployed base of Kerberos is considerable, it is easily
the most widely adopted symmetric key distribution standard.


> 4. You state, "The Security and SecureConversation issues 
> have already been 
> addressed in XKMS insofar as they relate to problems that any 
> secure web 
> service must address." Which parts of the XKMS spec, 
> specifically, do you 
> mean? Can they be seperated into a different namespace/spec 
> for easy re-use 
> or handing off to a WS-Security WG?

The answer to the separation question is yes. In fact this has been
anticipated in the current spec.

The signature layer provides equivalent functionality to ws-security.
However it is performed at the application level instead of at the SOAP
header level. This has a number of side effects, the most serious being that
the signature has to be enveloped instead of detached which means that a
much more complex XML Signature implementation.

The mechanisms used to prevent replay attacks etc. are very general and can
be separated off into a spearate specification. In fact I would suggest that
we do this within the XKMS group as a prelude to whatever
ws-SecureConversation type work gets done somewhere.


>> Given that the GXA/Whatever work in those areas is going to delay XKMS
>> until it is complete the WG might as well begin addressing the issue.

>I'm not aware of this depenendency. In what way must XKMS wait for it? The 
>idea is to put out modular specs that can be of service quickly without too

>many depenencies.

The problem is that adoption of XKMS 2.0 is likely to be slow if there is a
general expectation that it will be imminently replaced by a GXA aligned
version, particularly since XKMS 1.1 is in production.

If we modularlize the XKMS specification so that there components that
overlap with GXA are in a separate document we then achieve the functional
separation you suggest, people can write XKMS code and be confident that the
only thing they need to do when GXA is formalized is to switch out the
ws-Security / SecureConversation module.

	Phill

Received on Monday, 3 June 2002 12:19:22 UTC