FW: Remaining issues

 
Attached is an updated draft. This time the info should be right! [I gotta
get round to automating this stuff, at least we avoided the SAML problem of
keeping a spec and schema in sync]. I don't know what I can do if it does
not arrive for everyone.
 
 
Re Issue 306 / Shivram's schema issue.
 
The issue was wrt the schema for Compound result.
 
The schema was fixed in the text but I forgot to copy across the copy of the
schema to the 'export directory'. I should write a script to automate this I
guess.
 
 
 
This is the list of remaining issues that I think we need to discuss:
 
 
303 Denis Pinkas: 8. 

The two overviews from sections 1.5 and 1.6 do not provide a clear 
picture of the functions that are supported. They should be both revised.> A

text is proposed as an annex at the end of these comments.

Resolution - Editorial - some text to be merged

303 Denis Pinkas: 20. 

The text under [177] mentions the <UseKeyWith> element which specifie>s a 
subject identifier and application identifier that determine a use of the> 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds
wit>hin 
the specified application protocol. A protocol can support a sender and a> 
receiver. It is unclear whether the Identifier corresponds to the sender >or

the receiver. It seems that the notion is by itself insufficient and shou>ld

be extended to make such difference.

Noted, the issue is not one of 'sender' and receiver but instead 'self' and
'other'. It is possible to imagine that a client might have need to ask
which key it should itself use for a particular protocol.

Denis Pinkas 303  - 21.  

 The text under [180] mentions S/MIME as a protocol. Why is CMS
(Cryptographic Message Syntax) not considered as a protocol as well ?

In general it is advantageous to avoid proliferation of identifiers. CMS was
considered a component of a protocol rather than a protocol in its own
right.

Resolution - Discuss 

304 Carlisle Adams: 4

Section 6.1.1: Example: Registration of Client-Generated Key Pair. In the
element, there is no key identifier. How is the service supposed to know
which key to use to verify this binding? Is it supposed to be implied from
the elements in ? If so (or if there's some other way that the service is
supposed to figure this out), shouldn't this be specified somewhere so that
implementers know what to build? 

Chopra - 11     

OriginalRequestId (RequestAbstractType), RespondID (PendingRequest) ,
RequestId (ResultType) should be of type "xsd:NCName" as they are referring
to "xsd:ID" type elements in other XML docs.