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

Minutes from 23 January 2008 Voice Conference on Access Control

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 23 Jan 2008 16:48:41 -0500
Message-Id: <0B156FFD-ACB8-4CF5-B1B6-E25A2E0798D7@nokia.com>
To: public-appformats@w3.org

All - The minutes from the WAF WG's 23 January VoiceConf on Access  
Control are available at the following and copied below:


WG Members - if you have any comments, corrections, etc., please send  
them to the public-appformats mail list before January 30; otherwise  
the minutes will be considered approved.

Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

          Web Application Formats Working Group Teleconference
                               23 Jan 2008


       [2] http://lists.w3.org/Archives/Public/public-appformats/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2008/01/23-waf-irc


           Art, Anne, Dave, Jonas, Thomas




      * [4]Topics
          1. [5]Review Agenda
          2. [6]Requirements
          3. [7]ISSUE #20 - location of the PEP
          4. [8]Requirements
          5. [9]Requirement #1
          6. [10]Fixed URI
          7. [11]Schedules
      * [12]Summary of Action Items

    <trackbot-ng> Date: 23 January 2008

    <ArtB> Meeting: WAF WG Voice Conference

    <anne> i don't have better equipment than last time so i'll prolly
    have to be muted all the time...

    <scribe> Agenda:

      [13] http://lists.w3.org/Archives/Public/public-appformats/ 

    <scribe> Scribe: Art

    <scribe> ScribeNick: ArtB

Review Agenda

    <sicking> I am, but muted

    <tlr> I'm muted, folks, so can't be me if the noise is still there

    <Art> AB: propose adding the P3P suggestion raised by Mark to the

    <anne> it's no longer here

    <tlr> oh

    <Art> AB: is that OK?

    <anne> because you're muted :)

    <tlr> I hear it quite well

    <tlr> *argh*

    <Art> AB: it would be the last part of the meeting ~10 mins or so

    <anne> (there is some other noise to though)

    <Art> AB: any objections

    <Art> JS: OK with me

    <Art> [Chair notes noise probs has caused most people to mute ...]


    <Art> AB: thanks for submitting the input of requirements Jonas

    <Art> AB: since then we've comments from Art, Jon, Thomas, probably
    others regarding those reqs

    <tlr_> sorry...

    <Art> AB: open the floor to any major reqs related issues people
    want to discuss

    <Art> DO: want to raise the server-side versus client-side PEP

    <Art> ... my related e-mail gave my position

    <Art> ... don't think we have consensus on this

    <Art> ... within the WG

    <Art> ... but I haven't seen Thomas' latest e-mail

    <Art> ... there has been lots of discussion

    <Art> ... some people in the WG feel strongly about it

    <Art> ... I don't think we should close this issue

    <Art> ... likely to be a formal objection

    <Art> ... think we need to try to get to consensus

    <Art> ... I've been dismayed by some of the comments

    <Art> ... For example "take it to another WG"

    <Art> TR: may make sense to talk about the reqs in the context of
    the Issues

ISSUE #20 - location of the PEP

    <Art> AvK: what is the counter-proposal?

    <Art> ... how do you not involve the client?

    <Art> ... I've raised these questions on the mail list but haven't
    gotten any response

    <Art> DO: I defer to Tyler and other security folks

    <sicking> anne, you are causing echo

    <Art> AB: I thought Anne's quest for an alternate proposal was to
    the whole community not just to Dave

    <Art> AvK: yes, that's correct

    <Art> TR: I think we should first look at the reqs

    <tlr> dave?

    <anne> whoa

    <tlr> anne?

    <tlr> dave?

    <tlr> want to rejoin?

    <Art> AvK: did anyone make a concrete proposal?

    <Art> TR: Mark and Tyler both made concrete proposals

    <Art> JS: we certainly put more of the enforcement in the client

    <Art> TR: one of Mark's proposals should be workable


      [14] http://www.w3.org/mid/B8F607CD-811A-44DF- 

    <Art> TR: but it doesn't work with legacy servers

    <Art> JS: I don't see any way of doing this and still meeting req #4

    <Art> TR: good point

    <Art> ... if you wanted to do enforcement on the server side would
    require a step where client asks the server if it understands the

    <Art> ... if the server does, then the details could be moved to the

    <Art> ... but have to be careful not to break existing services

    <Art> ... policy lang doesn't have to travel over the wire

    <Art> AvK: that makes GET requests more complicated

    <Art> ... have to know if server is capable of replying

    <Art> ... makes caching on the server harder

    <Art> JS: I think we need a concrete proposal

    <Art> ... including the attacks it addresses

    <Art> AvK: hard to comment on the other proposal when it isn't real

    <Art> TR: given DO dropped off I think we don't have critical mass
    to continue this discussion

    <Art> JS: I agree

    <Art> AB: would like to understand the requirements angle

    <Art> TR: would need some type of discovery mechanism

    <Art> ... need to understand the complexity of the server versus the

    <Art> ... i.e. where to put the complexity

    <Art> JS: I don't see it as client side PEP vs. server side PEP
    because there will need to be policy enforcement on both

    <Art> TR: I agree

    <Art> JS: we need 1) coutner proposal; 2) what are the problems to

    <Art> TR: I can create some counter proposals

    <Art> AB: that would be good

    <Art> TR: I can come up with 1 or 2 straw man proposals

    <Art> DO: what about the proposals that Tyler proposed

    <Art> TR: the question isn't where the PEP resides but how to split
    the complexity betweent the client and server. The client will not
    be eliminated from the decision, regardless of the architecture.

    <Art> ... The only way to eliminate the client completely is to mint
    a new HTTP method

    <Art> ... But that would create a huge deployment problem.

    <Art> ... There will always be some policy enforcement on the

    <Art> ... Can only entirely move the decision to the server if the
    client is certain the server can do 100% of the policy decision.

    <Art> [Scribe missed some details ...]

    <Art> JS: please send this to the mail list

    <Art> ACTION: Thomas submit proposal to the mail list regarding the
    policy decision split and complexity [recorded in

    <trackbot-ng> Created ACTION-154 - Submit proposal to the mail list
    regarding the policy decision split and complexity [on Thomas
    Roessler - due 2008-01-30].

    <Art> JS: we must understand the problems that will be solved by the
    other proposal

    <Art> TR: agree

    <Art> AB: agree

    <Art> ACTION: Jonas send a request for comments regarding the policy
    decision questions and issues [recorded in

    <trackbot-ng> Created ACTION-155 - Send a request for comments
    regarding the policy decision questions and issues [on Jonas Sicking
    - due 2008-01-30].


    <Art> AB: what do we want to discuss?

    <Art> AvK: prefer to discuss on the mail list

    <Art> JS: I agree

    <Art> DO: think we need to discuss requirements

    <Art> TR: would prefer requirement discussion on the phone

    <tlr> chair's call, I gues

    <Art> DO: think it's hard to follow some of the detailed discussions
    related to requirements

    <Art> AB: what is your plan Anne to address the comments on reqs?

    <Art> AvK: I will respond on the mail list

    <Art> AvK: I don't think we should delay the work to get everything

    <Art> DO: but we don't have agreement with what is documented

    <Art> AvK: if someone disagrees, they need to submit comments

    <Art> TR: we don't have agreements

    <Art> ... we need to go through the requirements and discuss them

Requirement #1

    <Art> AB: who is going to drive this?

    <Art> JS: I responded to Jon just now

    <Art> TR: I don't have much to add to beyond what I said on the mail

    <Art> ... may be able to merge 13 with #1.d

    <Art> JS: It would be good if comments included proposed changes

    <Art> AB: any other questions about TR's comments?

    <Art> AvK: I haven't read it yet

    <Art> JS: me neither

    <Art> AvK: could someone give me some ABNF help?

    <Art> DO: I can help.

    <Art> AvK: thanks!

    <Art> AvK: it would be good if there was a proposal for specific
    reqs before the call.

    <Art> AB: any issues with that?

    <Art> JS: no

    <Art> AB: sounds reasonable to me

    <Art> TR: Art should solicit input on specific reqs and add them to
    the agenda

    <Art> AB: I'm OK with that

    <Art> DO: one thing we can do is to pick a couple of issues that we
    want to get closure and give ~ 1 week notice.

    <Art> AB: good idea Dave

Fixed URI

    <Art> AB: Mark's comments about needing to look at P3P

    <Art> AB: what is the issue?

    <Art> AvK: I think we want per resource

    <Art> JS: not clear if P3P was being suggested as something we
    should use or something we should look at

    <Art> ... can put the policy file in a header

    <tlr_> P3P use case is slightly different. The policy is retrieved
    in a special safe zone.

    <Art> JS: I think Mark was talking about a mechanismm to associate a
    policy and a URI

    <tlr_> (don't remember the spec's precise name for that)

    <tlr_> +1 to JS actually

    <Art> AB: Mark suggested this should be added to the Issue List.

    <Art> ... What do you think?

    <Art> AvK: too vague to know if that is true

    <Art> JS: agree I'm not sure what he's looking for

    <Art> TR: think he is concerened about scalability (e.g. Akami)

    <Art> AvK: we need to ask for clarification

    <Art> ACTION: Anne seek clarification from Mark about the
    P3P-related issue [recorded in

    <trackbot-ng> Created ACTION-156 - Seek clarification from Mark
    about the P3P-related issue [on Anne van Kesteren - due 2008-01-30].

    <Art> AvK: I think we need a plan on how to move forward

    <Art> ... e.g. new questions all the time

    <Art> AB: I'm open to suggestions on how to move forward

    <Art> AvK: I think the design is good

    <Art> ... but there is a call for more rationale

    <Art> ... dont' want to keep discussing reqs but prefer to talk
    about technical issues

    <sicking> -q


    <dorchard> I remain convinced that the design is reflective of an
    implied set of requirements, of which there is not consensus.

    <Art> TR: regarding Voice Confs, I have this slot on the 30th

    <Art> ... will need to send regrets on the week of Feb 6

    <Art> ... OK on Feb 13

    <Art> ... but then it gets more difficult

    <Art> JS: I can reiterate we are running out of time

    <Art> ... I am nervous about getting this in FF3

    <Art> AB: I propose we plan to have a call next week

    <Art> TR: are we expecting to stick to this timeslot for the
    forseeable future?

    <Art> AvK: this time is good

    <Art> JS: me too

    <Art> AB: me too

    <Art> AB: meeting adjourned

    <Art> ScribeNick: Art

Summary of Action Items

    [NEW] ACTION: Anne seek clarification from Mark about the
    P3P-related issue [recorded in
    [NEW] ACTION: Jonas send a request for comments regarding the policy
    decision questions and issues [recorded in
    [NEW] ACTION: Thomas submit proposal to the mail list regarding the
    policy decision split and complexity [recorded in

    [End of minutes]
Received on Wednesday, 23 January 2008 21:49:14 UTC

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