- From: Krishna Sankar <ksankar@cisco.com>
- Date: Wed, 23 Jan 2002 13:25:48 -0800
- To: "Krishna Sankar" <ksankar@cisco.com>, "Mike Just" <Mike.Just@entrust.com>
- Cc: "Frederick Hirsch \(E-mail\)" <hirsch@zolera.com>, <www-xkms@w3.org>
- Message-ID: <NABBJDOPDKGCDCNBNEDOMECHGLAA.ksankar@cisco.com>
RE: requirements review/planFor some reason this didn't go thru :o( cheers -----Original Message----- From: Krishna Sankar [mailto:ksankar@cisco.com] Sent: Wednesday, January 23, 2002 7:20 AM To: Mike Just Cc: Frederick Hirsch (E-mail); 'www-xkms@w3.org' Subject: RE: requirements review/plan Hi, Comments embedded. cheers -----Original Message----- From: Mike Just [mailto:Mike.Just@entrust.com] Sent: Wednesday, January 23, 2002 6:51 AM To: 'Krishna Sankar' Cc: Frederick Hirsch (E-mail); 'www-xkms@w3.org' Subject: RE: requirements review/plan Hi Krishna, Can you please clarify some of your comments below? -----Original Message----- From: Krishna Sankar [mailto:ksankar@cisco.com] Sent: Friday, January 18, 2002 12:43 AM To: www-xkms@w3.org Subject: RE: requirements review/plan Hi, Some minor points. 1) 2.1 ... Every client must support *at least* one of *these* mechanisms. --- [MJ] I don't understand which item you're referring to. --- <KS> 2.2.1 (Security) says "Every client must support one of the mechanisms". I assume we mean "at least" and not "at most". If so let us be clear by saying "Every client must support *at least* one of *these* mechanisms". </KS> 2) Add : 13. The specification shall explicitly state the visibility requirements (of elements), if any, for cases like encryption. --- [MJ] I don't understand what you mean by "visibility requirements". Can you elaborate? --- <KS> This comes from the possibility that messages could be encrypted. Either we can say that we deal with stuff after the messages are unencrypted (which could be implied) or iterate a set of elements which should not be encrypted so that we could make some sense of the message we receive. </KS> 3) It would be better to define "assertion" in the context of this requirement set. For example 3.3. talks about assertions, while 2.7 says some assertions are out of scope. It would be precise if we could add a requirement in Section 3.1 The specification shall define ... assertion, ... assertion, ... --- [MJ] I see the reference to "Assertion" in 3.3.3, but am not sure what you mean by "2.7". Are you looking at the latest version at http://www.w3.org/2001/XKMS/Drafts/xkms-req.html? Having said this, there was also some confusion regarding the concept of an "assertion" at the December F2F. I think we actually tried to remove most references to Assertions. Do you have specific requirements text that you can suggest we add? <KS> I was talking about 2.4.7 and (as you pointed out) 3.3.3. But other sections like 2.2.7(XTAML Assertion), 2.3.2, 2.3.10 (Public Key Assertion), 3.2.12, 3.3 mentions assertion as well. So the question is, do we deal with assertion ? If so, do they have the same meaning as SAML ? Of course SAML does not define Public Key assertion, XTAML assertion et al). One possible idea is to remove the notion of assertion from XKMS. Or another way is to say (I will wordsmith this if we take this route) "Assertion is ..... XKMS shall define XTAML Assertion, public key assertion,.....SAML Authentication and authorization assertions are out of scope ..." </KS> --- Cheers Mike
Received on Wednesday, 23 January 2002 16:26:26 UTC