Re: Comments on the XML Encryption Requirements

[Reagle: I noticed that this reply of Ross didn't make it into the 
archives.]

Joseph Reagle writes:
 > Just to share some context and expectations, the XENC
 > specifications are now in PR. So while these comments on our last
 > call from 12 months ago are welcome, the threshold of
 > "entanglement" <smile/> is *extremely* high as Michael agreed to
 > [2]. (Not that I think any substantive change or entanglement
 > follows from your email!)
 >
 > [2] http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0041.html

12 months?  My goodness, we have been remiss.  I apologize both for
myself and on behalf of the Schema WG.

I hope you nevertheless find the comments useful.  I appreciate your
feedback.

I understand that comments at this late date are difficult to deal
with.  But it seems we have very little at issue -- you seem to agree
with and even anticipated most of our feedback.

The remainder of the comments are my own.  If you need a formal
response from Schema, I can take it back to them, but it doesn't seem
necessary.

 > http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-D
 >esign The design philosophy and requirements of this specification
 >   /+(including the limitations related to schema validation)+/ are
 >   addressed in the XML Encryption Requirements [EncReq].

There is a typo in that note: the 'i' is missing after the '('.

 > As Rich mentions, we still need a serialization, the trick is that
 > we would first need a non-ambigous and non-lossy serialization
 > format for Infoset.

Agreed.  This is definitely a tricky problem.

 > > A possible approach to resolving this problem, which Schema would
 > > encourage you to consider, is to specify not a specific element, but a
 > > complex type of encrypted data.  This would allow the schema author to
 > > specify element X and an encrypted form of X as alternatives.  So, the
 > > original schema might be rewritten thus:
 >
 > This is an interesting approach however this would require XML
 > Encryption applications to be schema processors. This might be the case
 > in future versions, but not the present one.

I don't think so.  One solution would be to have a required attribute
on the complex type that the encryption processor can recognize as a
signal to do it's work.  Or maybe I'm missing something.

- Roß

---
I hate women because they always know where things are.
					-- James Thurber

Received on Wednesday, 30 October 2002 16:55:28 UTC