See also: IRC log
<melvster> morning all! :)
<scribe> scribenick: betehess
<bblfish> spec http://webid.info/spec
<bblfish> bertails sees this as strongly related to LDP
<bblfish> me +1 it is, though not completely dependent on it.
<bblfish> bertails: ldp also would find it very useful to have webid
<bblfish> ... explains LDP is about putting data in documents, modify data, etc ... in a RESTful way
<bblfish> ... where RDF was about data, ldp is about modifying over the web
<bblfish> ... ldp is interested in access control - it's in their charter
<bblfish> ... these resources need protection since people need to change resources
<bblfish> melvster introduces the RWW Community group
<bblfish> the web vision was initially a Read and Write space.
<bblfish> melvster webid is orthogonal to ldp. All systems for global communication uses global ids.
<bblfish> ... the explain in simple terms what WebID is
<bblfish> ... the goal of pki should be to simplify the message
<bblfish> ... the RWW group has 60 people, and is incubating specs, ...
<bblfish> ... ldp should be a best practice for what the RWW should be
<bblfish> ... it will be a recommendation
<bblfish> timbl : concerned that the ldp and rww might diverge
<bblfish> melvster: we're very much into dog fooding and trying out new things
<bblfish> betehess: many people speak about linked data, but not many good definitions of it.
<bblfish> ... so the important thing of ldp is that it will give a formal definition of linked data.
<bblfish> ... the dependency between webid and ldp is therefore conceptual at that level
<bblfish> ... but there is also a practical use of WebID
<bblfish> ... certificates work everywhere
timbl: you have plenty of authentication systems out there
timbl: at the end, we need to ask
them to produce http uris
... that's the fundamental thing
<bblfish> A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent as the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document.
timbl: let's imagine an arbitrary
... how would go allow someone to press a webid button, and at the end, the LDP system works
... I'd see webid as a module of LDP
... just like any other auth system
... we should have a common interface layer that would be interoperable with RWW
betehess: for me, webid (without certificates) would be this common layer
<bblfish> so the question is whether WebID is about the tie to get a WebID or if it should be the thing that abstracts all other identification systems
melvster: identication and authentication are two different things
<AnnBassetti> melvster: cannot have authentication unless you have identification first
melvster: the idea of URIs is universal and cover both worlds
<bblfish> melvster was also saying that identity is seperate
melvster: browserid relies on email
timbl: the email is used to
... you could expose that in an http uri
bblfish: I'm against webid being
the thing binding everything together
... WebID is about tying a URL to a public key
... eg. WebID over TLS
... or webid over browserid
timbl: so we should speak about
... so webid would be an endpoint
bblfish: any of the _global_ identity you get, you can bind them to other identities
timbl: the designissues you're
talking about just say that authz and authn are different
... this discussion is partly about branding
... you can go to people, say that you have LDP systems, and tell them that you need something URL-based to do authentication
melvster: webid and
webid-protocol are not the same
... no you get 3 parts at the and
<bblfish> melvster: identification, authentication, authorization
melvster: I thought we have two
definitions, that's why I'm not comfortable with tying the
definition with public keys
... would be just fine for the protocol part
<Zakim> betehess, you wanted to ask if RDF or LDP is part of the definition
<bblfish> bethesse has a good story for ldp: it needs a URL identifier
bblfish: I agree: identity, authn and authz are not the same
<AnnBassetti> TimBL drew diagram: circles on left representing "Auth1" "Auth2" "OpenID" "Auth3" "WebID" .. each with lines going toward area that is the web as whole
[looks like henry is tying all this stuff to RDF on the whiteboard]
<AnnBassetti> ... where, the web includes "Apps", "RWW ReadWriteWeb)", "Storage", and "All"
<AnnBassetti> oh .. what I said is "All" is really "ACL"
timbl: if you're building apps,
you can write rules
... what alex is saying is about prooving
betehess: for the record, I
didn't want LDP to be working specifically on webid or webacls,
just to focus on protocol itself
... still the use-case must be considered
<deiu> Link for the auth diagram: http://www.w3.org/wiki/File:Auth-diagram-tpac.jpg
melvster: in the rww group, we're
looking closely at LDP, but not only that
... we may have to incubate some ideas ourselves
deiu: re: the diagram and linking multiple protocols
<bblfish> access control on LDP will be Friday morning http://www.w3.org/2012/ldp/wiki/F2F1
deiu: it's important
... you have multiple systems, but it's easier if it's only a link for the application
... sometimes, apps don't trust enough some authn systems (for some reasons)
... but webid here, already sends many informations about you
timbl: the software architecture
is a key thing
... we also need people to be able to create identities easily, for the open market
deiu: so is webid just another authn protocol? or the common layer?
timbl: yes, that's the
... definitely about branding
... take html5 for example
... it's the Open Web Platform, including JS and other stuff
betehess: for many people, webid == webid-over-tls
bblfish: I'll rename the spec to mention TLS explicitly in the title
melvster: browserid is mozilla's
identity in the browser
... it's email based, centralized
... the private key is kept by the identity provider
... it's the other way around
... they say it's federated
... but it starts at @@.com
... but you can opt-out by deploying your own service
trueg_: the idea is that each
email provider had their own system
... but nobody supports it so far
bblfish: we should look at what makes browserid and webid similar
<timbl> (Earlier: timbl: This should be a flexibility point in the architecture, that many systems can be used for authentication, and each end up providing to a RWW-LDP system what it needs, an HTTP RDF URI for an agent.
bblfish: this could help defining what webid is
trueg_: the question about
branding is important
... like when alex were mentionning the connection to LDP
... we need to stress that so that when we speak to people, we don't scare them away
... we should tell them simple things that we need
... "an agent/person on the Web is authentified by an HTTP URI"
... this is how we would bridge the gap with LDP
... this would help us defining WebACLs as well
... because at the end, this is what the Web is about
timbl: yes, in term of systems, this is what the systems return
was proposed earlier: an agent/person on the Web is authentified by an HTTP URI
during the break, timbl proposed the following: an agent/person on the Web is denoted by an HTTP URI
<bblfish> definition of a WebID
<webr3> "an agent/person on the Web is denoted by an HTTP URI", that HTTP URI is a "WebID", WebID being the name for a URI which identifies an agent.
<webr3> (FOAF+SSL -> WebID Protocol -> WebID Auth Protocol) != WebID
<bblfish> but the question is what if I create a URI a WebID for webr3 ?
<bblfish> would that be webr3's webid?
<webr3> then that is a WebID for me, a URI which identifies me, it may not be my con:preferred/canonical one, but it refers to me. It is "a webid" not "the webid"
<webr3> The one I mint for myself can be deemed authoratitive, due to dns & uri ownership, and backed up by sigs and even checking the social graph
<webr3> in webid protocol I may use "a" webid for msyelf, it's not the one true only identifier
webr3, FYI, we're quite thrilled by your definition, we're discussing about it
bblfish: how do I know if the http uri is not for a cat?
alex: you don't
<bblfish> or how do your know it's not a URI for a relation, or a type
<bblfish> betehess BrowserId has been renamed Persona
<webr3> 'http uri is not for *********', that's what linked data covers, as timbl discussed on www-tag recently, what a URI refers to is in it's usage within a conversation, linked data (via ownership from dns system, and with http uris so you can dereference) allows a URI "owner" to describe what a thing refers to, in a way that unambiguous enough for the general conversation, and within that community
people asking: does it really make sense to try to talk to the browserid people? or should we stick to LDP?
melvster: you only authenticate when you need to, that's another reason to dissociate with identification
bblfish: so far, they use a JSON
... they have pushed back on having an URL in there
deiu: maybe we're getting
side-tracked by other protocols
... it's basically linked-data
... if this is not about Linked Data, they could use whatever they want
<webr3> it's side tracking to webid-protocol, not to webid - and the people in this group are concerned with both.
<webr3> it doesn't matter who you speak to in which groups, what's important is looking at each protocol and finding a way to get a URI for the person out of it, even if by way of a 3rd party/delegated service - for (1) Identification. Auth* is of no concern to Identification. THis is for wider scope consideration in our apps though, and not specific to WebID-Protocol, which is one of many options for users.
deiu: if we don't want to waste, we should focus on LDP
melvster: this is about naming things, not convincing people to use LDP
deiu: we need to use some keyword: HTTP, URIs, etc.
alex: I agree we must focus on the LDP people
bblfish: this definition may be
... if w3c says that they are working on something universal, we'll be seen at too imperial
<bblfish> that's ok if a WebID URI denotes an Agent, then an e-mail address cannot be a WebID since it refers to an e-mail address
<bblfish> but note that if a WebID URI denotes an Agent, then an e-mail address cannot be a WebID since it refers to an mbox, an openid cannot be a WebID because OpenId refers to a document
<melvster> To say that the URI "mailto:email@example.com" identifies both an Internet mailbox and Nadia, the person, introduces a URI collision. However, we can use the URI to indirectly identify Nadia. Identifiers are commonly used in this way.
<timbl> A WebID is an HTTP LDP HTTP URI which denotes a person. There are protocols to get them from various ways, Openid-W for example from a OpenID page, BrowserID-W from an email dress using Moz's system, webfinger-W using webfinger, and WebID-TLS to to get it using across-linked cert.
timbl: it's not about removing the security from the system
bblfish: when are people interested about their identity? when they authenticate?
alex: no, I could refer to your webid without authenticating you
<abasset> most people, BTW, don't know anything about 'identity' in a computing sense .. they just want to do things they want to do
trueg_: just wanted to comment on
separation btw ldp and profile url
... with webr3' def, we only have the URL
... is there benefit for us?
... how much does it help?
... there should be dereferencable urls, and a profile, whether it's foaf or not
... it's been aroudn for a while
<timbl> In fact FOAF URI is not a good term for it really as FOAF is just one application
melvster: webid protocol is more
... used to be foaf-ssl
<webr3> adapted slightly: "A WebID is a LD (or derferencable) HTTP URI which denotes an agent. There are protocols to get them from various ways, Openid-W for example from a OpenID page, BrowserID-W from an email dress using Moz's system, webfinger-W using webfinger, and WebID-TLS to to get it using across-linked cert." (minus LDP, and agent rather than perosn)
melvster: but webid is a cool name
trueg_: don't dispute that, just saying that having just http uri may be too broad
webr3, people here are saying that you're getting too complicated :-)
<deiu> the important part of that definition is "A WebID is a LD (or derferencable) HTTP URI which denotes an agent."
trueg_: we should stick with http urls
<webr3> lol fair point - just needs a URI which points to some linked data about the agent referred to by the uri
<timbl> webr3, by "or derferencable" do you mean (a) i.e. dereferencable or (b) or any non-RDF dereferncebale URI
<webr3> auth protocols can be bootstrapped to get those uris (webfinger-w etc)
<webr3> timbl, dereferencable to "linked data"
<Zakim> timbl, you wanted to suggest that and to suggest "A WebID is an HTTP LDP HTTP URI which denotes a person. There are protocols to get them from various ways, Openid-W for example
timbl: we're talking about
... it's a LD URL
... or it may not support LDP
... it could writable
... or not
... but it's critical to be able to GET it
... and you need to get back an RDF model
... foaf is for social networking application
<webr3> timbl, clarification request - GET it diretly, or indirectly (via a 3rd party service)
timbl: so I like LD URI
... you GET an RDF model
... and we could say: TURTLE is mandatory
<melvster> [ "Today, 10 Downing Street announced a series of new economic measures." ]
<melvster> [ To say that the URI "mailto:firstname.lastname@example.org" identifies both an Internet mailbox and Nadia, the person, introduces a URI collision. However, we can use the URI to indirectly identify Nadia. Identifiers are commonly used in this way. ]
melvster: it's an example of indirect ident
timbl: that's why I use a
... "denote" for me is a function
... mailto designs a mailbox, not a person
alex: sooo, are we putting LD in the first definition?
bblfish: we already have "web" in webid, so yes
<webr3> 1- as I can't actualyl "say" it :|
webr3: we're focusing on LD
alex: please wait for a PROPOSAL definition
<timbl> A WebID is a LD HTTP URI which denotes an agent."
<timbl> A 4* LD URI
<webr3> Or broader: "A WebID is a 4* Linked Data URI which denotes an Agent" - every constraint we add cuts somebody out, but make implementaiton easier
<timbl> "A WebID is a HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE."
<timbl> is slightly more constrained than "A WebID is a 4* Linked Data URI which denotes an Agent"
<timbl> "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE.
<bblfish> I have a problem with tying to turtle in the definition of WebID
<webr3> +1 on "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE." it adds constraints which make it ideal, negating httpRange-14, and not forcing people to have 5000 different parsers
<bblfish> timbl is pushing back on beting too general with how things could work ( because I had suggested GRDDLing documents )
<Zakim> betehess, you wanted to introduce webr3's remark
<webr3> betehess, please add that a tight definition doesn't preclude bootstraping/grddl etc, people can and will still do that -but the end goal must be something interoperable using simple standards
<webr3> and ty
<timbl> "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE."
<bblfish> timbl also mentioned that specs should be little and prrecises with clear specs so that they can be implemented and so that we tests can be built for for them: so that we can have guarantees
PROPOSAL: "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE."
philipp: we develop
... this relies on 303
... so this definition could be an issue for us
timbl: you do conneg? what do you do if people accepts rdf and html?
philipp: we may have a special
case for webid
... which does not rely on redirects
RESOLUTION: "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE.
for this afternoon, we have to define "webid over tls" and "webacls"
(just temporary names)
<webr3> any possibility of doing "webid-no-tls" too?
<deiu> webr3, that's what we'll try to find out
webr3, the concensus is that we don't want to prevent other people to define that
hence "over tls" for now
<webr3> nice approach, don't do it but don't prevent it :)
<webr3> what time is webacls oine, roughly?
steve: part of the CG process,
you can get with a deliverable with a pretty well finalized
... you can go to a WG with that
... they may have to adjust the charter
... but you need to define what you want
... in many way, it's a fast-track to get into a WG
for the record: it's being proposed that this group will provide a set of specs to be brought to the LDP WG
<timbl> In a straw poll, the group agreed unanimously
<bblfish> nobody present opposed it
<timbl> that the group should proceed to make a Final Specification and charter or rechater WG work on it./
<shh> Tim got it right. It's about getting a Final Specification.
<webr3> is anybody from LDP group here, or nearby to get their opinion on it, espec Ivan
<kidehen> webr3: late to this, but a WebID is a verifiable URI that denotes an agent. Verifiability is a critical attribute. WebID Authentication Protocol is an example of a verification protocol. Then we have loose coupling of the Agent ID and the verification/authentication protocol
<webr3> kidehen, verifiable in different ways (crypto vs social graph inference)?
<kidehen> webr3: verifiable using a variety of protocols: WebID Authentication Protocol (crypto and entity relationship semantics based reasoning)
<kidehen> webr3: remember, we also have a variant of WebID that we call YouID. It users fingerprints where WebID currently uses the Public Key and WebID association. This is quite cut and paste friendly, for instance
<kidehen> webr3: over time, there may be other protocols, so we don't want to conflate the Agent ID and verification mechanisms. This is how we broaden the tent, in due course
<webr3> makes sense, wondering how important the verifiability of a webid is - is it always needed, only for some use cases, and who is doing the verification (same process for everybody?)
<webr3> agree re "over time,..."
<kidehen> webr3: there's a note and demo of this at: http://bit.ly/O4LNKf
<webr3> kidehen, any pointers to more info on youid? not quite grok'ing it
<kidehen> webr3: all it does is compare certificate fingerprints i.e., you local cert claims matched to the same thing in you're profile doc. All the user needs to do is associate their WebID with a fingerprint. As per the note which is a simple example of one profile doc that works with WebID or YouID/NetID. My comments emphasize this
<kidehen> webr3: what's most important at this juncture is loose coupling between the Agent ID and the verification protocol
<webr3> okay I follow now, and agree re loose coupling, always important
<kidehen> webr3: conflation ultimately gets us into unnecessary trouble
<webr3> ty kidehen
<deiu> based on this morning proposal, we just realized that facebook has 1 billion WebIDs
<deiu> Proof: rapper -g -o turtle https://graph.facebook.com/andreisambra
<deiu> https://graph.facebook.com/100004074420423# is a valid WebID now
<deiu> scribe: deiu
bblfish: we have to test the existing implementations which currently use TLS
<webr3> I've got a little js function somewhere which normalises facebook profile uris to their graph hash uri somewhere
bblfish: which means adding tests that validate implementations according to the existing spec
bblfish: the tests should apply
to applications as well as to agents/people
... the schema contains different tests cases for the authentication protocol (over TLS)
... grayed boxes are cases which went too deep/far
... the W3C recommends that all specs should have a validator
<kidehen> deiu: Facebook has had Personal URIs (Linked Data principles compliant). These URIs are verifiable using their proprietary protocols. This exemplifies my point about loose coupling, in a nutshell. Also read: http://bit.ly/NzfyF0 -- an old post about Facebook Linked Data.
bblfish: all implementations should pass the validator tests
kidehen, my previous comment on facebook was related to this morning's talk
<kidehen> deiu: we have to separate WebID and RWW testsuites. If we don't we will stall, as we have for some years now.
kidehen, do you have access to this morning's logs?
<kidehen> deiu: RWW-0 should be the interop/test suite for RWW which is loosely coupled. WebID can have its own which has been in WIP for a while now
<kidehen> deiu: I am reading from the bottom up, so I'll rewind to the top soon
<webr3> seperate WebID, WebID Protocol, and RWW tests (webid != a verifiable webid != verifiable webid w/ webid-tls)
thanks webr3 :)
<kidehen> deiu: A WebID is a hash HTTP URI which denotes an Agent agreement you mean? If so, I don't agree with that. It's pragmatic for sure, but very susceptible to the problems that conflation will ultimately unleash
kidehen, PROPOSAL: "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE."
<kidehen> deiu: you can't tell someone that has a hashless de-referencable that it isn't a WebID, that's not the way to do it
<kidehen> deiu: you get a profile document bearing Turtle content, but that's an option
the idea was to decouple the identity part of WebID from the authentication part
<kidehen> deiu: we don't need to break Web Architecture to make this thing work
<kidehen> deiu: yes, +1 for the decoupling
and we're not, we're just separating the URIs which identify people/agents, from the other URIs
<kidehen> deiu: but there's a problem with mandating hash URIs that resolve to profile documents with turtle content. Even though that's mighty pragmatic and by far the easiest route.
the goal is to bring WebID (the identity part) closer to the LDP work
<kidehen> deiu: a URI denotes things. That's it. A Linked Data URI denotes things in such a way that the denotation is linked (via indirection) to description (descriptor) document
<trueg> kidehen: TURTLE is basically a place-holder for what is decided in LDP
<kidehen> deiu: WebID is already based on Linked Data principles.
<bblfish> kingsley the discussion is on the logs
<bblfish> the restrictions were argued by TimBl because they make things simple
<kidehen> trueg: Turtle is but one format for document content. It's my personally preferred format as I am sure you know, but that doesn't mean its the sole option. We shouldn't loose track of the fact that formats are negotiable.
<trueg> kidehen: I think the idea is to make it the default which should be supported.
<kidehen> bblfish: I know that hash URIs and Turtle are simple and mega pragmatic. You can make them a preference or default. But don't make them part of the definition of a WebID. That's not the way to go
<trueg> kidehen: others can be supported and requested of course
<melvster> kidehen: we had a proposal this morning based on recommendations from alex timbl and webr3 ... it unanimously passed from the people mentioned here
PROPOSAL: "A WebID is a hash HTTP URI which denotes an Agent. You can GET an RDF model as TURTLE."
<kidehen> bblfish: trueg: make the language loose don't force stuff on people. I make all my demos in Turtle, but I also make sure folks understand its a preference
<melvster> the wording was: '"A WebID is a hash HTTP URI which denoes an Agent. You can GET an RDF model as TURTLE."'
<bblfish> there is a CAN there
You _can_ get it in turtle
!= you _MUST_ get it in turtle
<trueg> the wording can be improved for sure
<kidehen> deiu: you don't GET an RDF model as Turtle. You GET document comprised of Turtle content which is constrained by the RDF model
<bblfish> we'll get back to the wording on this in more detail when alex and nathan are back
<kidehen> deiu: Turtle is the definition is suboptimal for something that's inherently loosely coupled based on the principles of the Web itself
<trueg> kidehen: the poing is that that resource needs to support turtle but may support any other format
coming back to the test suit
<kidehen> trueg: that's fine, but that isn't what's being presented based on current wording as pasted by deiu
<trueg> kidehen: we will fix that later then
kidehen, the proposal I've pasted comes from this morning
<kidehen> trueg: okay, don't have document content formats within the definition of a WebID. The tweak re. Linked Data is that the URI resolves to a profile document where the content is an RDF model graph with very specific entity relationship semantics
<kidehen> trueg: deiu: when we conflate syntax and semantics we end up in the same place we've been for years. This is always about a denotation mechanism, content structure, and entity relationship semantics. None of this is format (syntax or notation) specific.
<kidehen> betehess: I am in the U.S. just getting my morning sorted out.. Also, my points aren't news. They are all over the place, so I don't see why we are heading back to old problems re. definitions.
deiu: we should have a service similar to the W3C one where new applications can be tested
melvster argues that we need to decide exactly what we should test against
<kidehen> betehess: ah! I didn't assume this was an actual meeting, so apologies if it is. I though this was a chat following the meeting etc.. As I said, I am behind due to time diff etc.
kidehen, we're at TPAC, meeting f2f (sorry for not answering all the time btw)
<kidehen> deiu: no problem
<kidehen> deiu: will pick up whenever the meeting is over
bblfish: HTTP error codes should at least be returned to the users/applications
<kidehen> betehess: I didn't take it that way :-) It's fine. I am also re-syncing after Sandy etc..
bblfish: a turtle request on a
resource that returns a 401 Unauthorized should also try to add
details on the reason why it is unauthorized
... how should the 401 describe the reason why it happened
... example: could not get the profile / the profile is in the wrong format / no public key found / certificate out of date / etc.
<melvster> kidehen: yes we have discussed this before, but got to a new consensus this morning .... we are discussing test suites now
<kidehen> melvster: okay, we discuss later. It needs some tweaking :-0
SimpsonTP, yes please come
<melvster> SimpsonTP: we are on the ground floor near the reception ... i think the room is called Terreaux 0
trueg askes what happens when users fail to authenticate using WebID
<SimpsonTP> okay i'll sneak out of the AC meeting at coffee break
a 401 page is displayed by default in case the server sends a 401 response
scribe: this page can be replaced by a different page with additional authentication options
bblfish argues that all implementations should return HTTP codes corresponding to the outcome of the authentication process
<bblfish> so the idea is to have one special resource on other webid implementation that only authenticates users that have a valid webid certificate
<bblfish> that returns a 401 if not authenticated
<bblfish> we can call WebID Authentication Resource
<bblfish> W3C WebID Validator Agents
these agents will use the tests described in the above diagram to test WebID-enabled applications
<bblfish> so part of the test should be that you change the key and log in again
<bblfish> one test is: public key missing in WebID profile
<trueg> change key test with delay to give servers time to update caches
<bblfish> one test is: SAN not derferenceable
also the list described at 14:39
bblfish argues about representing the state of an authenticated user, using turtle
<bblfish> question: what do we return in case of success?
scribe: "how do we express (using
turtle) that a user has been authenticated?"
... EARL can be used to represent error instances
<trueg> one success possibility is to simply return the entire profile
<bblfish> Proposal: I proposal to wirte a simple validtor for a WebId Test resource
<bblfish> of course
this was an easy one :)
<bblfish> And will list all services that pass the Verificiation service on webid.info as valid webid services
betehess, we're still trying to find a definition
<betehess> will be back shortly
<betehess> s/will be back shortly//
<trueg> betehess: it is a random resource that WebID implementations expose to all verified WebIDs. It can be used by the WebID verification service to test parts of the implementattion.
<bblfish> WebID Test Resource is a resource • that only returns a HTTP 200 code if the person has a .... to complicated definition
<bblfish> WebID Test Resource is a resource that returns a 401 with an to-be-determined error message in Turtle if the agent was not authenticated using WebID and returns a 200 with a to-be-determined success message if the agent succcssfully authenticated
<bblfish> Proposal: WebID Test Resource is a resource that returns a 401 with an to-be-determined error message in Turtle if the agent was not authenticated using WebID and returns a 200 with a to-be-determined success message if the agent succcssfully authenticated
<bblfish> And not other access control restrictions exist on the server.
<bblfish> move on to another topic
same for us
<bblfish> Alexandrer speaks about WebBox solving melvins a problem
<rblin> The paper : http://users.ecs.soton.ac.uk/mvk/webbox-pim.pdf
<bblfish> they are from southampton university
<bblfish> alexbertails coined the term webbo
<bblfish> Romain Blin presented his LifeShare network that uses rdflib.js
<bblfish> Now Bart van Leeuwen http://www.linkedin.com/in/bartvanleeuwen76
<bblfish> is showing firefighting and RDF
<bblfish> Bart is a firefighter in Amsterdam
<bblfish> bart does not have a lot of time to make decisions ( 4minutes to get to fire location )
<bblfish> bumpy roads
<bblfish> and you can't wait in front of the burniong house reading your ipad
<bblfish> a lot of data silos
<bblfish> very small info they got in the old version
<bblfish> a small tweet of information is all they have
<bblfish> not enough
<bblfish> so they re-wroed to the arc2 triple store and now to arqxequi?
<bblfish> showing the new screen ( looks like google maps)
<bblfish> they developed this in 3 months, used by 40 firefighters in holland
<bblfish> Now they use a Jena Store XUL Runner, and Identity manager
<bblfish> they would like to have webid so that the firedpartment can ask questions in that time that businesses would not want to give out to everyone
<bblfish> here is a map of Amsterdam, with the Ann Frank institute. It uses info from different sources. They know it's a museum, and people live there
<bblfish> so they were able to publish where they are going
<bblfish> they would also like to show where it is going, but they would like the information to be published but only visible to some people. So WebID could be useful here too.
<bblfish> Alex Bertails: asking for the use cases for WebID in Bart's talk to see how Access control rules fit in
<bblfish> Bart: GMS this info goes into the incident manager
GMS is the central dispatch system which initiates the incident
<bblfish> Incident Manager uses SPARQL as Rules
they use SPARQL rules to manage incidents
Agents can be registered with the Incident Manager
<bblfish> an agent is registered with a SPARQL query
the same agent pulls info from external sources (the building on fire) and updates the incident data
<bblfish> so most of the data is public they are using
incident data can be a list of chemicals that are found in the house that is on fire
<bblfish> But the firegighters would like to be access confidential information
<bblfish> and they like WebID because it is easy to use
<bblfish> and does not require complex certification procedures
<bblfish> all telemetry in the fireftrucks should be linked data
<bblfish> they had a huge chemical fire in the netherlands, which created a huge environmental disaster
<bblfish> had they had real telemetry they could have worked out how to deal with it much better.
<bblfish> is used in smoke detectors
<betehess> bblfish discussing the advantages of having a special DN in the certificates
<betehess> doing that, the server could ask for only "valid" webid certificates
<betehess> bblfish: this would prevent the user to provide non-valid certificates
<betehess> ... helps selection
<betehess> deiu: I argued on ML we should to avoid the elements that could be usefull for companies
<betehess> ... because they are part of the pop-up windows
<betehess> ... it's vital for some companies
<betehess> ... and they could want to use some of them for themselves
<betehess> ... so I'd advise to avoid those
<betehess> ... I'm pasting the link to this email listing all these elements
<betehess> bblfish: there is service trying to assess the quality of the TLS endpoints
<betehess> ... they verify the protocol
<betehess> ... I will send an email with a link (can't remember right now)
<betehess> ... anyway, we don't want to use "w3c" here
<betehess> [some discussion happening on cn and dn in certificates]
<betehess> [now checking what works in browsers]
<betehess> looks like OU, O, ST, and C are not vital
<betehess> could be an issue to mess with the CNs for "issued by" and "issued for"
<betehess> bblfish: I want to focus on the CN of the issuer
<betehess> ... as the people would only want to tweak their "issued for" CN
<betehess> deiu: we may have a tracability issue
<betehess> all: the UI sucks, especially on Linux, looks better on Windows
<betehess> s| https://localhost:8443/srv/certgen||
<webr3> re earlier proposal "WebID Test Resource is a resource that returns a 401.." Please refine this to be an HTTP GET request with the appropriate Accept headers, and without any conditional headers (If-*).
<webr3> general note: I'm very wary about needing to do anything that involves anything in certificates other than specifying a SAN, the things your discussing may be neat, but they'd make me want to cry if mentioned anywhere in the web spec itself
<SimpsonTP> webr3, I think I'm with you on that one
<betehess> betehess: maybe the requirement on the CN could be a SHOULD and not a MUST
<betehess> bblfish: this could work
<betehess> deiu: what about DC (Domain Component)
<betehess> ... as we don't use the chain of trust
<betehess> SimpsonTP: in active directory, they already use that
<betehess> bblfish: you can't use wildcards, you need to use a specific string
<betehess> betehess: can we use any attribute, like LDAP?
<betehess> deiu: that was my question
<betehess> SimpsonTP: if this is possible, I'd be ok with that, but I would strongly be opposed to using commonly used fileds
<betehess> ... it all comes up to support in browsers
<webr3> reading http://en.wikipedia.org/wiki/X.509#Architectural_weaknesses especially "Implementation Issues" section ( DNs lack canonicalization and i18n etc)
<webr3> request: can somebody point me to why we'd want a special DN in the certs, I've missed a thread somewhere
<betehess> webr3: because we want the user to be asked for valid webid certificates
<SimpsonTP> webr3, to limit the options of certs shown to the user in the browser
<betehess> one way to do it is to restrict on some fields
<webr3> ahh is this the CN=WebID,O=empty-set-char thread?
<betehess> hence the discussion on what fields, and what values
<betehess> webr3, yes
<webr3> I'd want that outside of certs to be honest, if FB issue me a cert with the hope I'll use it everywhere, I want to tell my browser to only use it on FB (And maybe one or two other sites) - that can't be in the cert, as it's subject to change over time, and for each person's preference
<betehess> we're trying to re-assess the issue
<betehess> do people have that many certificates to choose from?
<betehess> Ben Laurie said "I don't want to use webid because of the case there would be too many certificates"
<webr3> could well do
<betehess> trueg: it's a non issue
<webr3> mini proposal: consider using issuerAltName
<betehess> ... it's an theoritical issue
<betehess> looks like people are pushing for just resolving this as being a non-issue
<betehess> (all but bblfish so far)
<webr3> +1 to non issue for what it's worth, interesting non critical work, but non issue. If the issuer wants to limit usage of the certificate, then issuerAltNAme could be used and point ot LD which ahs more details ont he issuer, and the suggested cert usage
<betehess> betehess: I'm proposing bblfish to try the extension fields in all browsers to make his case, at least on the technical level
+1 for that
<betehess> ... in the meantime, the group is still asking henry to declare this is a non-issue
<betehess> ... and go back to ben laurie with the decision of this group
<betehess> trueg: also, this is even a bigger problem because of UI issues
<betehess> PROPOSAL: approve for the above
<betehess> more explicitly: we make this a non-issue
<webr3> +1 to non-issue
<webr3> This will never happen because no CA will ever let itself be under the
<webr3> hierarchy of a pseudo-CA like we're discussing. It would also make the
<webr3> normal PKI verification completely void.
<webr3> re: /O=FOAF+SSL/CN=TDB - from Bruno back in 2010 when discussed
<webr3> seeAlso: http://markmail.org/message/qeslafjpozshnpni
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/TLD/TLS/ Succeeded: s/bblfish:/timbl:/ Succeeded: s/ReadWriteWeb)", "Storage", and "All"// FAILED: s/"ALL"/"ACL"/ Succeeded: s/brisge/bridge/ Succeeded: s/e-mail address/mbox/ Succeeded: s/+1// Succeeded: s/working/wording/ FAILED: s/will be back shortly// Succeeded: s/the server/that resource/ Succeeded: s/not/no/ Succeeded: s/a // Succeeded: s/small/little/ FAILED: s| https://localhost:8443/srv/certgen|| FAILED: s|172.19.2.24|| FAILED: s|https://172.19.2.24:8443/srv/certgen|| Succeeded: s|your|you're| FAILED: s/fileds/fields/ Found ScribeNick: betehess Found Scribe: deiu Inferring ScribeNick: deiu ScribeNicks: betehess, deiu Present: Alexandre Bertails Melvin Carvalho bblfish Andrei Sambra Jonathan Dray Philipp Frischmuth gregory barry Steeve Holbrook TimBL Ann Bassetti Got date from IRC log name: 30 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/30-webid-minutes.html People with action items:[End of scribe.perl diagnostic output]