W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

[waf] Minutes from 16 January 2008 Voice Conference on Access Control

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 16 Jan 2008 18:14:57 -0500
Message-Id: <213B17B2-B67E-4D5F-A6D9-D7C3499AB228@nokia.com>
To: public-appformats@w3.org

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]
Received on Wednesday, 16 January 2008 23:16:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC