W3C home > Mailing lists > Public > public-appformats@w3.org > March 2007

Re: Comments on Access Control (http://www.w3.org/TR/access-control/)

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 21 Mar 2007 17:35:31 -0400
Message-Id: <5CEA0C67-A379-4852-8803-EE8BD39980F7@nokia.com>
To: public-appformats@w3.org


On Mar 21, 2007, at 2:22 PM, ext Marc Silbey wrote:

> As promised I've included our comments and questions below on Access
> Control. The draft looks very good and the below comments are  
> minor. I'm
> looking forward to discussing these in further detail.

On March 21 the WAF WG discussed Marc's comments during a Voice  
Conference. Below are the minutes from that discussion.


Art Barstow

Attendees (ordered by first name): Anne van Kesteren, Art Barstow,  
Brad Porter, Cameron McCormack, John Hrvatin, Marc Silbey, Marcos  
Caceres, Matt Oshry, Thomas Roessler

Scribe: Cameron

Chair: Art


    AB: mark sent some comments to the public list today
    ... use these 45 minutes for those comments

    MS: i'm new to standards body work, so if we need more time to go
    through the comments, it's cool
    ... not surprsiing comments, just minor
    ... i don't know if we want to spend the time here on them? or maybe
    the editors can go through them and comment?

    AB: we could go through comment by comment, but have brad/anne had a

    <art> http://lists.w3.org/Archives/Public/public-appformats/ 

    AV: will brad still be an editor?

    BP: no matt will be

    AV: didn't seem controversial, except the one that said post was
    ... the most complicated one is 17, which proposed chnages to the
    algorithm. thomas had some comments too about how deny/accept works.
    ... other than that, it's not just for scripts. cross-site xslt or
    something could be a use, too.
    ... that would change comments 1 and 2
    ... i already made changes to the nonpublished draft. i don't know
    about changing "XML" into "resource", should check that.

    BP: maybe we can just go through the issues you see

    AV: yep
    ... thomas do you want to tell them?

    TR: the ones that jump out at me are that some people can argue post
    is as safe as get, and would be useful
    ... more discussion on how/when resources can be POSTed
    ... other is comment 11, where you propose a rewording " [...] allow
    and block list "
    ... those lists aren't in the spec now

    BP: block should be deny, sorry

    TR: that suggests allow/deny statements are on the same level
    ... but the current approach is as discussed at the F2F at the TP,
    process the allow rules, then the deny rules is scoped by the
    preceding rule
    ... [reads out some text from the draft]
    ... i'd oppose that change, since it amounts to a different

    AV: can you give a concrete example where it would differ?

    TR: the current approach you can say: allow from *.com except
    ... then another rule: allow from a.b.example.com except
    ... but that except www.example.com is scoped to the "allow from
    ... so the pairs can be treated in arbitrary order, and that maps
    back to the syntax considerations that you get in HTTP headers
    ... and when you combine the headers

    AV: since they're in pairs you can simple rename one to deny

    TR: i agree
    ... the proposal goes beyond that, as i read it
    ... it's not very clear to me, the current wording defines some
    ... the proposed rewording doesn't do that

    MS: we could remove that sentence there

    TR: let's have another look at what that says

    MS: should be what's in the spec today, but changing except to deny

    AV: i definitely got more comments about "except" being more
    annoying than "deny"

    TR: i can live with that, as long as the hierarchy is clear

    MS: remove the allow and block part

    AV: a resource that has the AC policy enabled, consists of a list,
    which has tuples, each tuple consists of two lists

    <matto> tuple

    AV: a tuple represents a set of AC rules, within the tuples you have
    an allow list and a set of deny domains
    ... when you request a resource, you go through all the tuples with
    the request domain, see if there's a positive match and no negative
    ... no i'm saying it wrong
    ... the deny clause only applies if there's a positive match first

    MS: that'd be secure by default, right?

    AV: that you can process the deny and allow rules in any order, is
    not correct
    ... only if the allow clause says it's ok will you check the deny

    TR: can we jump to the matching alg in sec 3 in the WD?
    ... the numbered item 3 is in the inner layer

    AV: hmm?

    TR: [reads text]

    AV: you run the subalgorithm for each AC rule

    TR: number 3 is part of that
    ... why is that neccessarily correct?

    AV: i agree we should redo the numbering, it's confusing

    <marcsil> * marcsil switch MS for BP starting with "maybe we can
    just go through the issues you see"

    TR: you can have 3 on either level actually, it doesn't matter

    MS: examples would be good, since it's complex

    AB: in order for this spec to get out of CR, we should have some
    exhaustive test cases too
    ... satisfied with that comment?

    TR: agreement about comment 11

    AB: did you have another comment to raise now?

    TR: i only see the comment half an hour ago

    AV: I do think the alg in 3 is wrong
    ... because step 2 should only be executed if step 1 was a match

    <tlr> ACTION: anne to fix step 2 in the matching algorithm to only
    apply if step 1 matched

    <trackbot> Created ACTION-74 - Fix step 2 in the matching algorithm
    to only apply if step 1 matched [on Anne van Kesteren - due

    AB: another level of indentation?

    AV: probably not, make another variable or something

    TR: i'd suggest go away from numbering it all. "if there is a match
    for an item from the allow rule set, then 1. ..."
    ... move it closer to pseudo code
    ... would marc mind going through the EBNF in comment 12?

    MS: i can try!
    ... i got this from one of the networking guys, who works with EBNF
    for a while
    ... adding the scheme/port specifier, that's so that it's explicit
    ... the first comment on the access item is just adding those

    AV: currently the port can't be a wildcard
    ... same for scheme

    MS: when we talked about this we got agreement, if you're going to
    trust the entire domain, you can probably trust all of the ports on
    ... it made sense to just be more flexible, to say trust the whole
    domain regardless of the port

    AV: not sure if it makes sense for scheme
    ... for http vs https it does
    ... but if you wanted to be secure you'd put in https

    MS: if you're trusting any site, you should trust any port on the
    ... similarly for scheme
    ... just be more flexible

    TR: another one: removal of examples that match your additions?

    MS: the example is about an error, no you shouldn't block these

    AV: hjow is the first one allowed?
    ... it's already conforming
    ... the first example in comment 14

    <tlr> " We're concerned that allowing "example.*" wildcarding maybe
    unnecessarily flexible and lead to mistakes by web developers"

    TR: the conforming/nonconforming examples are spread through
    ... you don't want example.*, but you want to keep overall

    MS: confused
    ... allowing example.*, it's not specific enough
    ... a web dev using that may be trying to mean something but
    unintentionally opens a hole
    ... the *.* is similar to that

    TR: *.* is similar to that, but you are permitting an * as an access

    MS: that makes sense, but if you're going to allow asterisks plain,
    then it's safe enough for anyone
    ... when getting more granular you get more flexible, but more

    AV: last part of the domain has to be a label?

    MS: i personally think so
    ... if we can find an example where that's not true, i'm ok in being
    convinced otherwise
    ... i might have a domain and lots of different schemes

    AV: you don't always own all of the top level stuff

    TR: there's an org that might add to them
    ... i'm inclined to agree with it
    ... broad wildcards are easier to understand, makes sense to me
    ... smoke it out further in last call

    AB: any other views?

    MS: might be helpful if there are other WGs to run this by
    ... maybe in LC, but would be good to get input from other folks

    AV: does the provided EBNF solve the issue?
    ... domain should be label?

    TR: no it should be domain...
    ... label has no dot in it

    AV: the last part has to be a label, and the last part is labels
    separated by dots
    ... the last part of the domain pattern has to be a label, the rest
    is wildcardlabel separated by dots
    ... i'm wondering if the EBNF is correct

    <tlr> [12]http://ietf.org/rfc/rfc1034

      [12] http://ietf.org/rfc/rfc1034

    <tlr> <domain> ::= <subdomain> | " "

    <tlr> <subdomain> ::= <label> | <subdomain> "." <label>

    <tlr> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

    TR: domain can be a sudomain or a space
    ... so i guess we should be using subdomain

    MS: trying to allow a star-style wildcard, again it should be

    TR: that's not the question here. the EBNF in the comment refers to
    domain from RFC1034, which expands to space or subdomain
    ... i believe you mean subdomain
    ... it's a label or a concat of a subdomain "." label, according to
    the ebnf in rfc1034
    ... i don't think you're aiming to allow a space character there?

    AV: i don't think subdomain is the right one

    TR: in your view which one is right?

    AV: a new one

    TR: back to reqs discussion

    <tlr> www.*.example.com

    TR: you want to allow such examples?

    AV: this was mainly about the top level domain not being empty or *

    MS: *.example.com should be ok

    TR: do you want to allow wildcard somewhere in the middle?
    ... i hear anne proposing that the pattern be able to match
    ... and the syntax that marc proposes would not allow that pattern,
    but only *.example.com
    ... wouldn't be able to have an additional prefix
    ... personally i don't really care either way, slight preference for
    whatever is simpler

    MS: what do you prefer anne?

    AV: you didn't want to allow toplevel domain to be wildcarded
    ... i thought that would be a required part
    ... your proposal only allows * before a certain domain?

    MS: you should be able to star subdomains
    ... are we agreeing?

    TR: no you're not

    AV: you should be able to say person.*.example.org
    ... the * in the current proposal only allows one level, it's not a
    complete wildcard
    ... only matches a single label, which should be clear from the
    matching alg

    MS: is the "person" a "www" or really a subdomain?
    ... when would you use that?


    CM: debian mirrors have that form

    MS: i'm ok with allowing that if there are actually scenarios using
    that form of domain

    TR: you now are agreeing, anne to propose new EBNF?
    ... marc, comment 13 is uncontentious, 14 follows on
    ... the question about 2.1 is well taken
    ... and anne needs to fix the bnf and the examples

    <tlr> ruleset ::= rule (LWS? "," LWS? rule)+

    TR: that's the current bnf
    ... that one is wrong

    <tlr> ruleset ::= 1# rule

    TR: we originally wrote it like that
    ... a mistake when transforming it to EBNF
    ... i agree on 15
    ... 16, that deny rules take precedence over any allow rules: this
    one would again ...

    AV: allow/deny rules are paired

    TR: 16 would lift that pairing, and i'd rather keep it

    MS: we should just clarify that
    ... it isn't that deny takes precedence over allow?

    TR: denies are scoped to one particular allow rule

    MS: the comment should clarify that overall, if there is a deny,
    then it takes precedence over an allow

    AV: by default, access is denied. then go through each tuple. for a
    given tuple, if allow rules say it's allowed, only then check the
    deny rules in that tuple. if those deny rules say it's denied,
    overall access is denied.

    MS: right

    AV: if the allow rules don't say allow, but the deny rules might
    still match, you just go on to the next tuple

    MS: "deny rules take precedence over their paried allow rule"?

    AB: make it more explicit

    AV: more examples

    MS: a summary at the top, to make it clear

    AB: time check, need to do 2 extra things
    ... we could continue this discussion next week?

    MS: just comment 17 left

    TR: i wouldn't object against getting 17 done today

    AB: we'll resume this discussion next week
    ... can do more discussion on public list too
Received on Wednesday, 21 March 2007 21:35:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC