[security-services] minutes for SSTC telecon/focus 2002-02-26

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Below are minutes for both official telecon and informal focus group.  I
apologize in advance for no doubt horrifically mangling the subtle XML
issues in the focus discussion.  Also, I didn't get the attendee list,
which I hope Joe can provide at some point.

 - RL "Bob"

---

SSTC conf call, 2002-02-26, 12:00 ET
regular meeting

quorum reached, session starts

item:  attestation of use
  Joe:  Sun attests to 7 items, others requested to follow suit
    Sun attestation will be sent to list
  Hal:  was there a template for this?  (looks)
        yes, there was a msg sent to list on Feb-12
  Joe:  reminder that attestation is not about product ship,
        but is about "real use", not "functional testing"
        any assistance needed?
  Irving:  how can use be "real" without shipping?
  Joe:  point is that it's not unit test, but whole-system use
  Phill:  we have stuff deployed on S2ML
  Joe:  S2ML doesn't apply, interim draft doesn't apply
        attestation has to be to most current draft
  Prateek:  Netegrity toolkit has been updated to schema-27, OK?
  Joe:  sure, but it's not just schema, also binding, errors, ...
  Joe:  are we splitting too fine?
  Hal:  inter-vendor interop won't be tested by internal deployment
  Phill:  can't ship until finalized, catch-22
  BobM:  problem is that we're trying to attest to use at same time as
         we're changing the spec; we really need to attest after it's
         frozen
  Irving:  all product companies can do is ship, right?
  BobM:  you could find out from customers whether they're using it
  Joe:  actually shipping product would presumably mean full testing,
        and is more than what we're asking for, so we're seeking
        reasonable level less than that.  So, internal pilot
        applications are that?  We need to have consensus on this.
        Karl B wants to say, in good faith:  this is ready.  But, we
        don't have to decide on this today.
  Prateek:  there's a difference between "implementable" and "proven
          in deployment"
  Joe:  so, we can think on this for next time

Hal:  should I produce new issues list?
  Joe:  all comments are treated equally as last-call at this point
  Jeff:  let's wait until last-call finishes and produce new list

(regular meeting adjourns, about 12:30 ET)

(Focus meeting begins)

agenda:  discuss Irving's issues

issue:  AuthorityKind and RespondWith
  (from message of Feb-25)
  propose that these elements be QNames rather than URIs ?
  only problem is that inside attributes these are in the context of
  the overall document namespace and its prefixes?  So some XML
  processors might get confused.  So, have to document this.
  Motivation is extensibility, and semantic clarity.
Prateek:  why again?
Irving:  extensibility, and consistency with other elements,
  eg AuthorityBinding
Hal:  note from Scott that xsi:type creates this problem already
  Irving:  since contents of xsi:type is QName
  Hal: so we have this problem, have to document it anyway
Prateek:  but AuthorityBinding and this are different
Irving:  only a little bit different
Simon:  AuthorityBinding is indirection mechanism
  but not an advertisement of service
Prateek:  if it's that loose, let's get rid of it
Irving:  increased discomfort with "the three queries"
  don't query-type and RespondWith do the same thing?
  doesn't RespondWith=authentication make it an Authentication query?
Prateek:  AuthorityBinding and RespondWith are separate, right?
Irving:  thought they were the same, but now see they're different
  is AuthorityKind saying "what I'll accept" or "what I'll respond
    with" ?  need to clarify
Hal:  clearly means "what I'll produce"
Irving:  problem is with extensions and determining who does what
  how does adding a new Statement type affect query type, authoritykind
  type, authoritybinding type, etc
  want text-literal mapping between semantically-equivalent types
  between Query, Statement, RespondWith, AuthorityKind
Hal:  I'm a strong proponent of keeping clear distinction,
  having clear semantics for the different queries/statements
Irving:  problem is that enumerations in XML aren't extensible
  so wherever we have enumerations we have extensibility problem
Jeff:  Irving, please get all this reasoning out on the list,
  keep process in mind
Prateek:  so this is looking for clever XML way to do extensible
  enumeration of constants?
Irving:  more than that, but maybe appropriate naming would be enough
Irving:  OK, this has to stew on the list some more


issue:  Actions and Action elements
Irving:  many qualifier+name elements
  but Action is different, for the reason that it would be common to
  talk about many actions from same namespace at once
  Is that common enough to make this different?
  Why is action not just a URI, rather than two things?
Phill:  it was, at one point
  yes, we can achieve compression commonly by this means
  actions from different namespaces on same resource will be unusual
Irving:  if matching is string match on namespace+name, why separate?
Phill:  intent was to avoid any private syntax, make all XML syntax
  also to support easier compression
Irving:  OK, if it's two-part, let's make it like other two-part
  things
Prateek:  so, just about cleaner syntax?  OK, then
Irving:  OK, proposal is message of Feb-25
Eve:  sometimes want another container with repeatable element
Irving:  if we want that we'd have to add another level
Simon:  Action is tied to resource, don't need "power"ful expression
Phill:  is it worth changing spec for this?  might get more
  consistency with policy mechanisms
Irving:  we'll discuss it more on the list, either withdraw or vote
  on it next week


issue:  NameIdentifier clarification needed
Irving:  email discussion indicates clarification obviously needed
  two issues:  syntax labelling, and one-part/two-part
Hal:  so, let's say how to deal with common syntaxes
  and give examples of possible locally-defined uses
Irving:  Prateek eloquently defended two-part in his message today,
  any complaints?
  we understand that SecurityDomain is not mandated to be
  globally unique
BobM:  and this sets limits on "interoperability" since if I think
  SecurityDomain is globally-unique and you don't, we can't talk,
  but that just means agreements have to be made out of band, so OK
Irving:  so proposal is to add additional "NameSyntax" attribute, in
  addition to current SecurityDomain, to NameIdentifier element
Prateek:  so we should enumerate syntaxes, which ones to do?
BobM:  sent list from RFC 2459 SubjectAltName in message today
RobP:  can this be referred to directly by URI?
BobM:  probably not, they're not OIDs
Prateek:  OK, I'll write up proposal on this and send to list

(call ends, 15:00 ET)