WebID Community Group Teleconference -- 23 Nov 2012

<bblfish> http://www.w3.org/2001/12/zakim-irc-bot.html

<scor> this conference will webid

<bblfish> start meeting

<scor> sandro: here to help with Zakim?

<scor> what conference is this?

<bblfish> http://www.w3.org/2005/06/tracker/irc

<bblfish> start meeting

<bblfish> trackbot, status

<scor> trackbot, start meeting

<trackbot> Date: 23 November 2012

trackbot, start telecon

<trackbot> Meeting: WebID Community Group Teleconference

<trackbot> Date: 23 November 2012

<bblfish> How many people are here for RWW?

<bblfish> http://lists.w3.org/Archives/Public/public-webid/2012Nov/0203.html

<scribe> scribe: Andrei Sambra

<scribe> scribenick: deiu

<bergi> i would like to talk about access control

Access Control

<bblfish> http://www.w3.org/wiki/WebAccessControl

bergi: can we talk about what was discussed at TPAC about ACL?
... triple access control should be discussed

<domel> I totally agree with bergi

bergi: defining triples for grouping resources and defining filters for RDF data

<bblfish> The ldp group are putting togfether use cases http://www.w3.org/2012/ldp/wiki/AccessControl

bblfish: bergi wants access control on triples

bergi: not really, for resources in general
... universal access control

<bergi> http://www.w3.org/community/rww/wiki/Scope

bergi: AC is about resources/triples

bblfish: the basic AC is for resources
... for items which have URIs

Please use the queue system when you want to talk: q+ / q-

scribe: "who can access a resource? / read / write"
... it's orthogonal to the filtering of resources

bergi: yes, that's the first topic, but I also want access control for linked data, i.e. protecting even the links to resources

bblfish: is there something missing in WAC now?
... you can create a group in WAC

<domel> bblfish: WAC do not have roles, my and bergi proposal do this

<bblfish> [acl:accessTo <classofresources>; acl:mode acl:Read; acl:agentClass foaf:Agent].

bblfish: in WAC, there in an AgentClass, and an accessTo

<domel> http://en.wikipedia.org/wiki/Role-based_access_control

domel: bergi and I are working on a new proposal which is a RBAC ontology, valid for the above link

<bblfish> data.fm

bblfish: because we have WAC from W3C, we should see how well it fits with your proposal
... we need use cases at this point, to identify where WAC or RBAC fits better
... or maybe improve both vocabularies
... a role is another set of agents (a group basically)

bergi: it's not just RBAC which is missing from WAC; my focus is filtering at the triple level

<domel> You can find many items that are not in the WAC, i.e. temporal values

bblfish: you can create a class with all the resources that speak about a person, and then use it for access control

bergi: if you already have existing data, it would be nice to reuse this data for AC (?)

<bblfish> accessToClass

bblfish: you can probably use OWL DL for that

bergi: I have an example that I will send to the mailing list

welcome back bblfish

Bergi, you were saying?

bergi: for AC, you can start simple with AC for resources, then use a "follow your nose" system to apply it to the triple level

bblfish, domel is on the queue

<PhilA2> .me this is me Phil Archer

PhilA2: the POWDER project is used a data compression mechanism for ongoing work
... POWDER allows us to make statements about groups and resources
... it allows to group URIs together

<bblfish_> rdf:aboutEach?

<PhilA2> SemaGrow is the project using POWDER

<PhilA2> http://www.w3.org/TR/powder-formal/#regexSemantics

bblfish: there is a group working on semantics for agricultural data
... they use POWDER

PhilA2: I am writing a paper on how people design URIs for linked data; people spend a lot of time working on URIs
... humans can look at a URI and tell that it is _about_ something: a person, a postal address, etc.

bblfish: this can be very useful for access control
... it makes a lot of sense for AC in LD profile space
... in LDP, you need to do a GET on a resource to obtain the AC rules for it

PhilA2: we designed it so that you can define any group, no matter how complex it is
... you can use inclusion/exclusion for the rules

bblfish: why is it XML based?

<PhilA2> domel: http://users.iit.demokritos.gr/~konstant/dload/Pubs/ijmso.pdf

#based WebID Def

<scor> deiu: do we have any conclusion about ACL?

<scor> about what we discussed in the before

<scor> ... we need a resolution

PROPOSAL: how many people present here are interested in working on ACL?

<bblfish> +1

<domel> +1

<bergi> +1

<bblfish> Q: What should the meeting times be?

WebID Hash based

http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash

<scor> bblfish: the wiki content has improved, better place to put the arguments than on the list

<scor> bblfish: Nathan did a good job summarizing the situation

<scor> bblfish: pity Kingsley isn't here

<scor> bblfish: Kingsley's arguments are: you can't look inside a URI. his arguments don't convince me that much

Very interesting to read at this point: http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/Requirements

<scor> ... for one POWDER exists and you can semantics on it

<bblfish> Jurgen: By defining a WebID to be a hash-based we put a lot of semantics into a single character where the most important parts are that an entity is described in a standardized way. Two identical => descriptions <= of a real world entity are treated differently if webid.toString().indexOf("#") is -1 or > 0. That what's interesting for the verifier is not the uri-string, but the description of an entity. In other words a verifier must judge the

<bblfish> graph not (only) by the triples it contains, but also by a certain character in the subject's uri.

<scor> ... Juergen is worried that we're looking inside the URI (same as Kingsley's point)

<scor> ... the URI should be opaque

<scor> ... we're trying to name a type of URI for a purpose. we're not saying everything on the Web should be a WebID

<bblfish> Exercise POWDER class of WebIDs for fun

<scor> ... we could create a POWDER class for WebIDs

<scor> ... the reason we are looking at these classes is to simplify the spec

<scor> ... and to make it work well with RWW systems

<scor> ... HTTP is essential for RWW and for verification mechanism. we rely on the HTTP dereferencing for the verification

<scor> ... URIs are opaque at the logical layer.

<scor> deiu: want to point to the link earlier re requirements

<scor> deiu: first we need to identify our requirements. otherwise we'll introduce more questions

<scor> ... newcomers will make their own use cases

<scor> ... so we know where the boundaries and avoid us to go outside these boundaries

This is the page: http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/Requirements

<bblfish> Larry Massinter

<scor> bblfish: Larry from TAG said you cannot resolve ht14 at the level of the TAG. has to be driven by requirements

<webr3> "if I working group wishes to promote one side or another, let them. There is no reason to imagine the TAG would make more progress in the next 10 years than it has in the last, on this (so-called) issue." ~ Larry Masinter

<scor> ... if we don't have requirements, we have no way of knowing when we're finished with our work

<scor> bblfish: I want to do a proposal (we'll do it often)

<bblfish> PROPOSAL: http/https is a MUST ( whether hash is or not )

<webr3> +1

<scor> +1

<bblfish> +1

<bergi> +1

<domel> +1

<melvster> +1

<scor> RESOLVED: http/https is a MUST ( whether hash is or not )

<scor> bblfish: people have a URL, but don't know where to put the data yet

<bblfish> 303 would work with hash urls too

<melvster> i have to drop off the cal now, too, thanks all

<webr3> hr14 wasn't about #hash, it was about slash URIs only, and finding a way to make them work for those who had already minted - #hash is default, 303 is a work around that lets http say "well this isn't an http resource, this other document might tell you what it is

Please contribute to http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash

<bblfish> scor: said "Given the current spec, hash URIs come with a restriction on basic 303 redirects, that means that when people change the location of their WebID profile (be it hash or hashless), they cannot rely on redirect to keep their existing WebID, and will have to regenerate a certificate for all their browsers and all their devices."

<domel> \me has to go now, bye

<bblfish> question: we have to ask but my view is that redirects are still alowed with the hash

<bblfish> but my view is that it does

<webr3> there is a more important point here, that the TAG may give other guidance which allows slash URIs to be deref'd without a 303

<webr3> can I make a proposal, for somebody to dictate to the group (pre issue)

<scor> webr3: yes, that's in line with the email I sent them

<scor> it'd be good if some group like TAG can give some guidance

<webr3> PROPOSE: we write the WebID 1.0 specification as if it says MUST use a http(s) #fragment URI, then remove the "MUST be a #fragment" from the normative definition, so that slash/303's are not excluded, but are not catered for specifically.

<scor> webr3: when is "then"

<scor> pre LC/REC or post REC?

<bblfish> https://www.w3.org/2005/Incubator/webid/track/issues/70

<webr3> pre LC, infact never put it in, just assume it's always a #frag URI thoughout the spec - afaict the onyl issues anybody has about 303, is having them (a) excluded, or (b) catered for in the spec making it more complex

<scor> webr3: well, the examples are all #frag

<scor> never does it say or mention to use 303s

<webr3> it doesn't have to make the spec longer

<webr3> .. just don't exclude them

<scor> webr3: my proposal for not mandating hash URIs is there: http://dvcs.w3.org/hg/WebID/raw-file/generic-http-uri-definition/spec/identity-respec.html

<webr3> write spec for frags, ignore 303 exists, don't mention psoitive or negative

<scor> the proposal spec above has a note discouraging 303s, it's the only mention of 303s

<webr3> scor: I read your proposal, found it a bit more complex

<scor> webr3: ok, would love to get your more detailed feedback, on what part is more complex

<webr3> scor: will do

<webr3> Alexandre and Kingsley will never agree

<webr3> we need compromise here, so cater for both, focus on #frag, ignore 303 - should I don't mind, it means nothing in this context for consumers, it means a lot for publishers

<bblfish> I am happy with SHOULD, version of 2

<bblfish> scor__: can live with should

<webr3> does anybody -1 "SHOULD be a #hash URI"?

<bblfish> nobody seems to be against version 2 of http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash#2._MUST_be_HTTP_uri_and_SHOULD_be_an_HTTP.28s.29_hash_.28.23.29_URI

<webr3> kingsley again on ML, and I'm not keen (re SHOULD)

<webr3> *kingsley against on ML, and I'm not keen (re SHOULD)

<bblfish> Hurgen said by skype: please take my -1 on one or the other sort of uri (hash or non-hash) as granted :)

<bblfish> please take my +1 on the "SHOULD be http..." question (as i said, i know of use cases, where i don't dereference the webID but get the graph via sparql)

<bblfish> please take my +0.5 on "MUST be http" (i can live with that)

<bblfish> But that was before I talked to him

<bblfish> so I don't know where he stands now

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/Requirements

<webr3> everybody +1s a MUST be an HTTP(S) URI - some -1 "MUST be a #frag", so consensus is "MUST be an HTTP(S) URI", it may also be "SHOULD be a #frag".. need to ask Kinglsey and Alexandre

<bblfish> it looks like SHOUOD fits all of the Alexandre's requirements

<bblfish> :-)

<webr3> lol no..

<webr3> Kingsley didn't like SHOULD be a 303, as it seemed to undermine perfectly valid 303 URIs as being "lesser" (and likewise products which create them)

<webr3> SHOULD be a #frag even..

<webr3> typo /s/303#frag

<bblfish> I am sure openlink can create #urls too

<bblfish> and I I think it would be interesting to consider #urls that redirect with 303 :-)_

<scor> "you cannot make the difference between a WebID and a Web Profile without an HTTP GET "

<scor> from http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/Requirements

<webr3> that's invalid..

<scor> "When you don't require a hash URI for a WebID : you cannot make the difference between a WebID and a Web Profile without an HTTP GET "

<scor> from Alexandre and Andrei

<webr3> document#frag can 301 to foo#frag, so you can't says <document> is the profile

<bblfish> I am not that conviced by that argument

<bblfish> I think that is Andrei

<webr3> claiming

<webr3> no. not at all

<webr3> yes true..

<webr3> given any <uri#foo> <uri> may 301, or 404, or..

<webr3> so <uri> can't mean "profile" you don't know until you GET it.. you don't know what any URI is until you have RDF about it

<webr3> so.. this is impossible -> "you cannot make the difference between a WebID and a Web Profile without an HTTP GET "

<scor> webr3: +1

<webr3> +1 to what bblfish just said, we want/need WebID spec to encourage more of what andrie has done

<webr3> +1 to 1 week

<bblfish> thanks

<bblfish> +1

<scor> trackbot, end meeting

- DRAFT -

WebID Community Group Teleconference

23 Nov 2012

Attendees

Contents

Access Control

#based WebID Def

WebID Hash based

Summary of Action Items

Scribe.perl diagnostic output