Re: Spec udpated

Hi Phill,

While I think that this is a reasonable feature request, I
fear that its coming at the wrong time in the w3c process
for us since we're now on the cusp of having the spec
transition to PR and then hopefully REC.

If we added a new feature like this now, then I believe
we'd have to ask the implementers to code it up and test
it and we'd also have to generate new samples, and make
spec, test spec and test report changes to reflect the new
field etc. As I'm sure you can appreciate that amounts to
a good bit more than 3 new lines in the spec and one new
line in the schema. I guess it'd take a month or more at
best.

I should also point out that the schema changes noted in the
recent concall minutes were just adding minor status codes,
which I'm sure you agree *is* a different kind of change.
Basically adding a new element to an enum, and involving no
structural change, as opposed to the structural change
proposed here. Those changes were also directly motivated by
difficulties encountered during interop, rather than new
feature requests. (Actually, the proposed change here might
also trickle over into requiring yet another new status code
like "NoCounterPartySupport" - yet another reason for being
conservative at this stage, given the argument about interop
that generated the recent minor status code additions:-)

I'd also note that there're probably other ways to handle
this that wouldn't require schema changes, e.g. both parties
could be identified in the Identifier along the (syntactically
to-be-corrected:-) lines of:

"mailto:a.n.other@example.org#mailto:counter.party@example.org"

where the second parameter of the identifier contains the
counterparty. Since the syntax and semantics of the Identifier
field is determined by the Application (at least as I
understand it), this would be fine so long as you make "email"
and "controlled counterparty email" (or whatever) be different
applications in the UseKeyWith field.

I'd also imagine that in most contexts the xkms responder's
concept of the authenticated identity of the requester will
be the same as, or can be mapped to, the counterparty. So,
turning on some form of requester authentication can acheive
the same goal, if you code up your responder that way.

If you agree with the above, (or don't have the energy to
argue:-), then maybe the best thing to do for now would be to
make this request the first entry on an "errata/change requests"
list, which we could link from the xkms wg page. Would that be
ok with you?

Having said all that, if the implementers who've taken part in
the interop exercise do want to include this then they need to
speak up right now (before/during tomorrow's con call) and say
that they do want to do that additional work.

Silence from that group on this issue will be interpreted (by
this co-chair at least :-) as equivalent to "nice idea, but
I'm afraid its too late in the process".

Regards,
Stephen.


Hallam-Baker, Phillip wrote:

> If we are going to change the schema I would like to suggest a small 
> change to add an extra optional attribute to UseKeyWith to allow a 
> second identifier to be specified.
>  
> The use for this is to allow for situations where the key to be used 
> with a subject changes according to the identity of the other party to 
> the conversation. For example in Kerberos and symmetric keyed protocols 
> this always occurs.
>  
> I had thought that since XKMS was limited to public key interactions 
> that this would not be required. However I now think that there is an 
> important set of use cases where it is useful to specify the 
> counterparty. For example in an enterprise messaging environment the set 
> of security keys to be used for internal communications might be 
> different from the set of keys for external parties.
>  
> So I would like to suggest adding a new attribute 'Counterparty' defined 
> as follows:
>  
> The <UseKeyWith> element contains the following attributes:
> 
>     *Application* *    [Required]*
>         A URI that specifies the application protocol with which the key
>         may be used 
>     *Identifier* *    [Required]*
>         Specifies the subject to which the key corresponds within the
>         specified application protocol. 
>     *Counterparty **[Object]*
>         May be used to specify a party with which the subject is in
>         communication with specified application protocol. 
> 
>      
>       <!-- UseKeyWith -->
>        <element name="UseKeyWith" type="xkms:UseKeyWithType"/>
>        <complexType name="UseKeyWithType">
>           <attribute name="Application" type="anyURI" use="required"/>
>           <attribute name="Identifier" type="string" use="required"/>
>           <attribute name="Counterparty" type="string" use="optional"/>
>        </complexType>
>        <!-- /UseKeyWith -->
> 
>     -----Original Message-----
>     *From:* www-xkms-request@w3.org [mailto:www-xkms-request@w3.org] *On
>     Behalf Of *Shivaram Mysore
>     *Sent:* Friday, March 18, 2005 6:36 PM
>     *To:* XKMS WG
>     *Subject:* Spec udpated
> 
>     Folks,
>      
>     I have updated the spec [1] and the corresponding Schema (Thanks to
>     Tommy).  The following are the changes.  There needs a little bit
>     more work on certain items.  I would appreciate if folks take a look
>     at this and suggest text.
>      
>     Jose, please update the xkms.xsd file attached to the website [2]
> 
>        1. Schema update: Added |ResultMinorEnum| codes
>           |ProofOfPossessionRequired|, |TimeInstantNotSupported| and
>           |TimeInstantOutOfRange|. Rationale: Issues 332-tl3
>           <http://www.w3.org/2001/XKMS/Drafts/cr-issues/issues.html#332-tl3>
>           and 332-tl4
>           <http://www.w3.org/2001/XKMS/Drafts/cr-issues/issues.html#332-tl4>
> 
>        2. Schema Update: Added |ResultMinorEnum| code
>           |OptionalElementNotSupported| . Rationale: Issue 333-jk
>           <http://www.w3.org/2001/XKMS/Drafts/cr-issues/issues.html#333-jk>
>        3. Editorial:Para[70] - added "("+" indicates concatenation)" as
>           clarification
>        4. Issue 332-tl1: Updated Section 7.1.7 para[303] to include Type
>           and MimeType information for |EncryptedData| element. *Should
>           I still include that "XKMS responders may ignore this type
>           attribute?"*
>        5. Issue 332-tl3: Updated para [311], [315] and [122]. Added
>           codes to the schema
>        6. Issue 332-tl4: Updated para [213] [122] - added text to
>           TimeInstant element, corresponding result codes to schema
>        7. Issue 332-tl5: Added sentence "XKMS Responders do not have to
>           support both of these optional elements in a request message."
>           to para [291]
>        8. Issue 332-tl6: - Updated para [112a], [128a] and [132] by
>           adding that |<RespondWith>|element cannot be present in these
>           request elements.
>        9. Issue 333-jk: Added Para [352a]
>       10. Issue 334-jk: Added Para [277a] -*I believe this needs a
>           little bit more work* 
> 
>      
>     [1]
>     http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html
>     [2] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/Schemas/
>      
>     /Shivaram
> 
> 
>     --
>     Secure Web Services, PKI, Software Architecture, Java,
>     Product Strategy and Management Consultant:
>     http://www.geocities.com/shivarammysore/
>     <http://www.geocities.com/shivarammysore/>

Received on Monday, 21 March 2005 12:00:48 UTC