[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] minutes for SSTC telecon/focus 2002-02-26
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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC