W3C home > Mailing lists > Public > www-xkms@w3.org > January 2002

RE: requirements review/plan

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>
RE: requirements review/planFor some reason this didn't go thru :o(

  -----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


      Comments embedded.

    -----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


            Some minor points.

    1)      2.1 ... Every client must support *at least* one of *these*

    [MJ] I don't understand which item you're referring to.


        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*


    2)      Add : 13. The specification shall explicitly state the
    requirements (of elements), if any, for cases like encryption.

    [MJ] I don't understand what you mean by "visibility requirements". Can
you elaborate?


        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.


    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

    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?


        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 ..."



Received on Wednesday, 23 January 2002 16:26:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:17 UTC