All - The minutes from the WAF WG's 16 January VoiceConf on Access
Control are available at the following and copied below:
<http://www.w3.org/2008/01/16-waf-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-appformats mail list before January 23; otherwise
the minutes will be considered approved.
Regards, Art Barstow
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WAF WG Voice Conf on Access Control Spec
16 Jan 2008
[2]Agenda
[2] http://lists.w3.org/Archives/Member/member-appformats/
2008Jan/0018.html
See also: [3]IRC log
[3] http://www.w3.org/2008/01/16-waf-irc
Attendees
Present
Art, Anne, Thomas, Jonas, Doug, Mike, David
Regrets
Arve, Caludio
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Confidentiality of Minutes
2. [6]Requirements and Use Cases
3. [7]Requirements in David's document
4. [8]JSONRequest
5. [9]Access Control Re-write Proposal
* [10]Summary of Action Items
_________________________________________________________
Date: 16 January 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Confidentiality of Minutes
AB: propose minutes be made availible to the public immediately
JS: OK with me
AB: any objections?
<tlr> +1 to public right away
[none heard]
RESOLUTION: minutes will be public immediately
AB: what about approval procedure
<dorchard> I like having minutes being made public immediately and
giving a week for somebody to object before final approval
DS: could be approved immediately
TR: could do the approval at the beginning of the next meeting
AB: propose a 1-week approval period and if no objections the
minutes will be approved
... any objections?
[none]
RESOLUTION: after the minutes are sent to the public mail list
participants will have 1-week to raise objections; otherwise mins
will be considered approved
Requirements and Use Cases
<dorchard> Agenda item added at 10 minutes prior to end of call:
Intro to Access Control rewrite proposal
AB: any comments on the plan for requirements and UCs?
AvK: what is the idea regarding the doc e.g. WG Note?
JS: I think a Note is a good idea
... we need to set a deadline for completing the reqs
DO: seems right to me [Note]
... support doing this as a note
... some WGs have gone down the REC path but its significant
overhead
DS: we could use a wiki as an intermediate step
AB: propose we create a WG Note
... any objections?
[none]
RESOLUTION: we shall create a WG Note for the UCs, Reqs, etc.
AB: what about a wiki?
JS: is one readily available for us to use?
... and what does DO prefer?
DO: I'm indifferent; can use a wiki or the file I've started
<MikeSmith> [MikeSmith needs to drop off for another call. may be
back..]
DO: small set of Editors does help with continuity
... can be hard with wikis
... but does help when lots of people are contributing
AB: who plans to contribute?
JS: I still plan to submit my input; can do it as an email or add to
the wiki
DO: make an executive decision Art
AB: my preference is a wiki
... any objections to doing so?
[None]
<anne> i disagree
<anne> for some reason i can't talk
<anne> my suggestion would be to add it in an appendix to the main
specification
DO: until we get a wiki set up can we continue as we started?
AB: can our member-only wiki be made Public, at least for this part?
TR: should be relatively easy to set up but it is painful to add
list of writers
... let's take this offline
DS: agree
AB: good point; I agree
<tlr> DO: have serious concerns if wiki can't be public
<sicking> sorry anne, you were causing echo
AB: let's drop this process-related discussion
<anne> sicking, yeah, this isn't working
<anne> apparently my objections on IRC are also ignored
<tlr> anne, please point out what objections you are referring to.
AB: Anne, we did not make a decision on the wiki
Requirements in David's document
AB: regarding 3.2, Hixie and Jonas both proposed we delete this
requirement
<anne> [11]http://www.w3.org/2008/01/16-waf-irc.html#T20-22-05
[11] http://www.w3.org/2008/01/16-waf-irc.html#T20-22-05
AB: any objections to deleting 3.2?
[None]
AB: how do we handle the existing reqs and new reqs?
DO: people should make proposals for edits and new requirements
... I am reluctant to add things without some general support
... If a few people agree then we can add them
JS: agree we need it to be lightweight process
AB: I think the priority is to document the requirements for the
existing model
JS: not clear what are the VB requirements
AB: I have an action to chase that down
JS: I ask because it could mean we could drop the XML PI if we no
longer had their requirement for such support
AB: not sure how to make sure people submit comments
JS: could set a deadline
DS: what about the plans for FF implementation of the AC spec
<dorchard> DO: We could set a deadline of a few weeks if there are
few comments over the next week or so.
<Hixie> <?access-control?> is really important to me for XBL2, fwiw
<Hixie> and i think it's critical that we allow people to make data
available cross-site without playing with server configuration
<Hixie> i assure you that not all servers give you low-level access,
e.g. many google services would never let you add an http header
JS: some people are arguing we need to make a decision now; if the
spec then has major changes we will have to withdraw the impl
DS: it's relevant to understand Mozilla's timeframe
... DO, do you think we need major re-design?
DO: I think there are some still important open issues
... e.g. is the PI support needed, etc.
... think we need to nail down the requirements
DS: some people believe the spec is solid and that time is critical
... and that we need to move forward quickly
... My concerns: 1) it's gravely flawed and will be released anyway;
2) it doesn't cause any probs but was held back because of debate
... Need to get it into the hands of developers
DO: I think we need to be careful about a vendor putting constraints
on the work just becuase they have done an implementation
<tlr> anne, does Opera have any specific plans?
DO: think we still need to prioritize the reqs and UCs
<tlr> that was just a side question on irc
<anne> tlr, we don't talk about future products
<Hixie> the only way we can make sure that implementations don't
constrain the spec is to not delay the spec
<Hixie> the more we delay, the more likely it is that
implementations will constrain it
DS: think a key diff here is that this functionality has been needed
for at least a couple of years
... I don't think it's good [for the Web] to delay the spec
... Everyday developers have been asking for this functionality
<tlr> anne, you are unmuted if art acks you
DO: I agree with DS' last point; I don't think we want a bunch of
different hacks addressing this same issue
<tlr> and you can unmute yourself with "ack anne"
JS: I did think the spec was stable that's why I started my
implemenation
<tlr> art: we early on tried to keep the use cases constrained; now
getting bashed for not extending them
JS: in the current context, 1-2 months is a really long time
... in another mont or so it will be too late for me to make changes
or even to retract
DS: so if we are in LC by the end of Feb would that work with
Mozilla's timeframe would we be OK?
JS: mid-Feb would be much better
<dorchard> This seems very risky to me from an impl perspective.
JS: but I think we just need to adjust some details
... I realize this is an unstable spec and the WG is free to make
any changes it needs
AB: I'm OK with establishing a deadline for the requirements work
<tlr> +1 to deadline on requirements work
AB: like one week to review the existing set of reqs Dave captured
<Hixie> isn't it about a year after the deadline for the
requirements work?
<Hixie> i mean, sure, it's sad that the requirements weren't
captured formally, but shouldn't it be too late to change them now?
AB: what about giving two weeks for reqs work
JS: I think we need to document the implicit requirements
<tlr> sorry, syntax is *not* minor changes
AvK: the spec really hasn't changed in over one year
<tlr> please!
AvK: by this I mean the spec as Hixie had written it; the AC has
been updated to reflect Hixie's version
TR: there have been changes to the syntax and semantics
... think it would be more effective to get agreement on the reqs
<Hixie> what happens if we don't get agreement on the reqs?
TR: that is documenting the implicit requirements
<dorchard> DO: The document of Feb 15th 2007 does not have the
authorization request, support for different methods.
JS: I agree with TR
DO: I also agree with TR
<dorchard> DO: so I think that the document has changed a lot int he
past year.
<anne> shepazu, I wasn't replying to you
AB: so what can we do in the next two weeks?
DO: we can try to get closure in 2 weeks
JS: we should aim to be done in two weeks
AB: get a sense of who is willing to really help document the
implicit requirements?
<tlr> art: want to get a sense who is willing to help document
implicit reqs
AB: Anne?
<tlr> anne: sure
AvK: sure
... have already started
AB: Jonas?
JS: yes
AB: Thomas?
TLR: yes
<tlr> you can use it against us later :)
AB: David?
DO: yes
... including Editorial work
<tlr> apologies
AB: Hixie - can you contribute to documenting the implicit
requirements?
<dorchard> DO: I just wanted to mention that reading consensus of
the WG could be hard
<tlr> tr: is hixie going to contribute xbl2 reqs?
<tlr> js: I can probably cover that
<Hixie> i think documenting requirements at this stage is an
extremely bad idea
<Hixie> since it can only lead to one thing, and that's people
disagreeing with the requirements
<Hixie> which can itself only lead to further delays
<Hixie> this should have been in CR last year
<anne> (and that already happened, see JonF on public-appformats)
<Hixie> unless there are specific technical complaints, i think we
should publish LC right now
<Hixie> and that anything else is pandering to committee-driven
design
AB: everyone please contribute to the implicit requirements
discussions ASAP and let's try to be "done" in two weeks.
JSONRequest
<anne> /dev/null ?
AB: we talked about JSONRequest last week but with no resolution
... for example is it in scope or not
... Would like to know if there is consensus on JSONRequest.
... Should it be reflected in our first LC document?
TR: it has a completely different security model than XHR
<dorchard> Hixie, I don't think that a commitee doing design is a
bad thing. That's why we have committees.
TR: I don't think it is a fit for this spec
... Recommend we keep it out.
JS: I agree with TR.
<anne> JSONRequest doesn't meet the implicit requirements. Why are
we discussing this again?
JS: I think it adds complexity and overhead.
... I intend to submit a requirement that rules out JSONRequest
DO: can there be negative requirements?
<anne> JSONRequest doesn't do cookies/authentication, it doesn't do
other formats than JSON, etc.
DS: interesting
<Hixie> dorchard: i fundamentally disagree with that position and
would put HTML, CSS, XForms, XHTML, and a broad range of other specs
as evidence supporting my opinion.
DO: is absence of a requirement good enough or do we need negative
requirements
JS: I think JSONRequest is out of scope
DO: I am a bystander on this one
<tlr> js: (a) do we want to adapt the JSONRequest security model;
(b) do we want to use access-control for JSONRequest
<sicking> JS: I think there are two separate questions when it comes
to JSONRequest
<sicking> JS: 1. Should access-control use the JSONRequest security
model
TR: wrt JSON, the client tells the server (by way of content type)
that it is sending a request
<sicking> JS: 2. Should we expact access-control such that
JSONRequest can use the access-control security model
TR: the server says the req will fail when the service cannot deal
with JSON
<dorchard> Hixie, this is the W3C which has committees. They get to
decide things. That's why organizations pay to join.
<anne> AvK: (1) no (2) don't need JSONRequest
<sicking> JS: for 1 I feel that that would complicate the use of
access-control too much since it would require that everything be
put in a standardized JSONRequest envelope. It should be trivial to
construct requirements that makes this obviously not work
TR: the one requirement we should document is: whether or not we
expect cross-site requests to carry "ambient" auth information
<sicking> JS: for 2 I think that is out of scope for this version of
the spec
<tlr> use case level: do we want to be able to deal with
access-protected resources?
<anne> yes
AB: propose that JSONRequest is not in scope
<Hixie> dorchard: sure, and it is imperative that the editor take
into account all feedback
<Hixie> dorchard: and if you have requirements that met, you should
convey them to the editor
<Hixie> dorchard: who i am sure will take them into account and deal
with them (especially if they don't contradict other people's
requirements)
<dorchard> Hixie, but then you say when I give feedback and offer an
alternative, that I'm "messing with the editors work"
JS: that's not quite right
<Hixie> dorchard: however, that's a far cry from committee-driven
design
<Hixie> dorchard: i'm talking about normative requirements here, not
how the spec is written, which is basically irrelevant at the end of
the day
<sicking> JS: I think we should say that supporting JSONRequest is
out of scope. I.e. we do not need to expand access-control such that
JSONRequest is able to use it in this version of the ac spec
DO: I would add a non-requirement section
<tlr> +1
DO: add supporting JSONRequest to that section
AB: propose we add a non-requirements section and add JSONRequest to
that section and that we close ISSUE #18.
... any objections?
[None]
RESOULTION: we add a non-requirements section and add JSONRequest to
that section and that we close ISSUE #18
Access Control Re-write Proposal
<dorchard>
[12]http://dev.w3.org/2006/waf/access-control/Overview-Declarative-2
0080116.html
[12] http://dev.w3.org/2006/waf/access-control/Overview-
Declarative-20080116.html
DO: Stuart Williams and I found the current prose a little confusing
... we re-wrote it in pseudo-code
... this approach is top-down
... made a few other changes too (e.g. BNF)
... Processing Model: added Stuart's overview input
... The new algorithms are leveraged from the XACML spec
... Access Item also redone in pseudo-code
... We think the current style is diff to read and we think this is
simpler to understand.
... We want frank comments even if not flattering
... If only part is adopted that's good too
... If nothing is adopted that's OK too
... There may be some holes/mistakes
... But think about the overall style and think about:
... 1. Is it easier to understand
<anne> My personal view it that it's way harder to read and
understand.
DO: 2. Is it easier to implement?
TR: agree with doing it top-down
... I disagree with pseudo-code
<anne> And pseudo-code definitely can't replace the current
normative text.
TR: the XACML is based on several operators and different states and
some of those states do not apply (and adds more complexity)
... need to keep it simple
JS: I don't really care which style we use
... just don't want to ever regress
<tlr> no disagreement with that, either
JS: need a full replacement before we change anything
DO: you don't want new text to be lower quality than existing text
... don't want to spend more effort on this if there isn't good
support
AB: what about a meeting next week?
DO: think it would be good
DS: only if there has been substantial progress
TR: my schedule is free so far
<sicking> can you hear me?
<tlr> no
<tlr> we don't hear you
<sicking> i'll type here
<sicking> JS: I agree with DS
<sicking> ... would rather not spend time unless we have useful
things to discuss regarding reqs
AB: I think there is critical mass for a call next week
<anne> I agree with Jonas and Doug
AB: there is an action for everyone to submit comments on David and
Sturart's proposal before next week's meeting.
<sicking> JS: thanks guys
<anne> I feel that a lot what we discussed could've been done over
e-mail
AB: meeting adjorend
Summary of Action Items
[End of minutes]
